Experience ~ Talent
I have had many titles during my career, and most of them have included the modifiers like “Junior” or “Senior”. I have also worked with many people with the same modifiers in their names. The modifiers tell me what their experience level is, but they don’t tell me if the developer is any good. One of the common recruitment questions I run into is “How do I tell if an applicant is any good?” and while there are many ways of finding out, past titles are not an accurate indicator to me. Even a modifier like “Lead” isn’t a great indicator, because it usually just means the applicant was the most senior at the company. So if title modifiers are not accurate, how do you tell if an applicant is any good?
Disclaimer: I’ve been part of a recruitment process many times during my career, but I’m not a recruiter by trade. I’m a developer, and a freelancer who often takes on Lead or Archtect roles and often experience being plopped into a team with little or no information about that team. I use most of what I’ve written here to assess my team mates in order to know how best to assist the team, who needs a little more attention, and what i should be looking for during reviews.
Let me start by saying the value of indicators is debatable, and nothing is ever 100%. Over the years I’ve collected some indicators I put my faith in, but the list is by no means exhaustive.
The buzzword counter
Buzzwords change with the times, and so does the hype around the technology. There was a time - not so long ago - where the word cloud would be worked into every tech conversation I was part of. It got to the point where, to the outside observer, it was 50/50 whether the conversation was about the weather or technology. For exactly that reason I still keep a buzzword tally as an indicator. You’re bound to talk about hyped technologies or frameworks during recruitment, but it shouldn’t be all buzzwords, there should be knowledge behind the words. Questions like “Can you give me some examples of how that could be implemented?” or “How do you compare X technology to Y?” should be posed and answered. It’s fine to be interested, it’s also fine not to have complete answers, but having some idea of the practicality of using it makes sense. If I’m recruiting a developer to work on a web platform, and machine-learning comes up, I’m interested in where the conversation is going. There are many possible uses and applications for the web, but if the applicant can’t come up with any it’s just a buzzword, and I add one to the counter.
Opinionated or Religious
I have a metric ton of opinions on development. Anything from the process, to recruitment, to code, languages, framework, culture… and it doesn’t stop there. I’ve been told I tend to utter them like facts, but most of them are opinions grounded in experience and knowledge. I am ready to change most, if not all, provided someone makes a good argument. I want the discussions and the debates. I believe this is what leads to better decisions, better code, and smarter developers.
Unfortunately, developers can get fairly religious about their code, and way of doing things. The difference between an opinion and a religious belief is the willingness to be wrong. It’s not easy to identify people who are willing to change their minds, but when asked why someone thinks something is good or bad, there should be arguments. Those arguments can be personal, but they should be recognized as being personal. Example: I prefer scripting languages over programming languages, but it’s a personal preference, more than it’s based on a strongly argued opinion.
Fundamentals are important. I used to do a lot of something called code Kata on the codewars site because I believe that having the fundamentals on my backbone improves my coding skill and speed. Not having to look up specific syntax, or solutions to common problems mean you also get an understanding of solving more complex problems. I’m not saying everyone needs to have done the same thing, but having some understanding of when to use and how to code - for example - a recursive function, is helpful.
Along the same lines, understanding design patterns is very helpful too. If you - for example - know what the difference is between a strategy and an observer pattern, or what a composite pattern is used for, you’re probably also someone who would care about the SOLID principles if you don’t already. You can be a good developer without this knowledge, but having it makes you even better.
Multi-talented or Unfocused
I have been a developer for almost 15 years, and during that time you accumulate knowledge of languages and frameworks. I’ve been a consultant for almost 9 years, and before that, I worked at a digital agency. All in all, that means I’ve worked with a multitude of languages and frameworks. And yet, I often see developer resumé’s with 3-5 years experience and many more languages and frameworks than I have on mine. It always gives me pause, and prompt’s the question “Is this guy multi-talented or just unfocused?”. Finding out means probing at as many of the items on the resumé as possible during an interview. “What project did you use this framework on?”, “What was the framework used for?” and “Why use this framework instead of an alternative?” are questions I’ll often ask. There are multi-talented people out there, don’t get me wrong, but an applicant with lots of technologies on their resumé always makes me take note.
Applying skill tests
Giving applicants tests is a contentious issue. I usually hear two arguments against: “Good applicants don’t like tests and won’t participate”, and “I can tell if a dev is any good without testing”. Both arguments have merit. Unfortunately, a lot of “good” developers don’t like being tested, and I for one don’t particularly enjoy it. It adds a lot of stress, and I can get jobs without tests easily so why bother. The second argument has merit too because with experience you can often tell when somebody I faking it. Online tests also tell you virtually nothing, because they usually focus on core language skills and the solving of problems that are as far from the coding problems they’ll face working for you, as New Zealand is from everything else in the world.
The two major problems with both arguments are they don’t let the applicant tell you anything, it’s all based on judgment. Skill tests can reveal a lot about an applicant, it’s just a matter of what kind of test, and testing for what you’re looking for. Having someone verbally explain how they would solve a problem tells you one set of things, and having them code the solution tells you another. Just make sure the test makes sense and lets the applicant show you their skills. Need an Azure DevOps guy, test for Azure DevOps, don’t give them a test of their core PowerShell skills
The IT recruitment problem
Recruitment in IT is fiercely competitive. There are simply not enough developers to fill all positions, and the result is that all companies want the entire set of skills of a whole IT dept. condensed into one candidate. It’s like people think “We can - realistically - only afford one developer, so that developer should be able to do everything.” Over the past 3-4 years, the number of recruitment posts on LinkedIn asking for an enormous amount of skills has increased exponentially.
Admittedly this example is one looking for a freelancer, but the contract is 2 months. Even so, this post could just as well be an advertisement for a permanent position. Considering the above requirements, I suspect only a handful of people would match up, and if any of these are available for a 2-month contract, I would be surprised. There are many lucrative freelance jobs out there, some likely offering much better terms. No applicants will likely be found for this position, the Azure + AWS experience requirement alone is enough to make most possible applicants pause, and the +10 year development experience is just the final straw. For the recruiter, Experience doesn’t tell you if the applicant is any good at their job, and if someone applied I would question how deep their knowledge and experience is because this is a HUGE list. I have a huge list I could put on my resumé, but I choose not to because I know I can’t back it up with any meaningful experience. Having “once worked with” does not make me an expert, or even experienced.
I don’t blame recruiters, I pity them most of the time. They have the unenviable job of looking for unicorns that match a list of skills they haven’t made themselves and probably don’t know half of. At some point, I imagine it becomes a process of trial and error for them, much like that “fit the block into a hole” we all played when we were babies.
The premise of this article is that experience is only weakly releated to talent. “Experience is the mother of wisdom” as the idiom goes. What you learn from an experience is important, though in my personal experience not as important as what you do with what you’ve learned. To me, that’s where talent shows. Not everyone has a flair for development, far from it, but if you learn from your experience and apply that knowledge, talent is not out of reach.
Choosing the best applicant is just as much about the process of recruitment, as the applicant. If you start by looking for a self-contained IT department housed in one person, you’ll likely fail. Getting a developer who’s just “Plug’n’Play” to your team, and immediately starts adding value is a dream scenario, appreciate it if it happens but don’t expect it. Especially not during the recruitment process. Divide your requirements into can’t teach, can teach, and not-important, and set the can’t teach as must-haves, can teach as nice to have, and ditch the rest. You’ll likely get a broader spectrum of developers to choose from, but you’ll also see more talented developers who might just be diamonds in the rough.
Lastly, we need to address the appalling lack of developers. The only way is to train them. Time and time again I hear “We can’t afford to have a junior developer, they take up too much development time”. First, this is not at all true. A junior dev takes more time completing tasks but also takes routine tasks away from the senior developer, so they can focus on other things. Second, training a junior means you’ll soon have an experienced developer on your team who knows your platform. No need to go recruiting for more experienced developers. Third, junior developers are - for a lack of a better term - cheap. For the price of unicorn developers, you’ll likely be able to add 2 if not 3 juniors to your team.