Experience is not Talent
If past titles are not an accurate indicator of talent or experience level, what is? Recruitment can be a hard needle to thread, so here are some tips.
Even a title 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?
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 give men an indicator of what their experience level is, but they don’t tell me if the developer 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 Architect 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 to know how best to assist the team, who needs a little more attention, and what i should be looking for during reviews.
The value of indicators is debatable, and nothing is ever 100%. The ones I use work for me but may not work for you.
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 reached 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.
“Using buzzwords without knowledge is just another form of Bikeshedding.”
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.
Bonus: Check out: I’m not like you. I’m an Engineer for more details on how you move a buzzword conversation, to being a constructive one.
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 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 recognised 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.
The Fundamentals
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 17 years, and during that time I’ve accumulated knowledge of languages and frameworks. I’ve been a consultant for almost 11 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. 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?”.
“There are multi-talented people out there, but sometimes you need a specialist.”
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.
“Need an Azure DevOps guy? Test for Azure DevOps, don’t give them a test of their core PowerShell skills.”
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.
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 kids.
Not unrelated
The premise of this article is that experience is only weakly related to talent. 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.
“Experience is the mother of wisdom”
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.
“We can’t afford to have a junior developer, they take up too much of our senior developers time.”
Lastly, we need to address the appalling lack of developers. The only way is to train them. There is no schooling scenario where someone will finish school and be as good as someone with two or three years experience.
A junior dev takes more time completing tasks, and senior developers sometimes need to step in to help. However, they 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.
Summary
Experience is not the same as talent, but someone with enough experience can become talented. There are truly multi-talented people out there, but they are few and far between, so when recruiting don’t look for one of them.
Some key points to keep in mind for a smoother recruitment process.
- Decide which of your requirements are must-have, and which are nice-to-have.
- Be aware that applying skill tests may push away some senior-level applicants because they can get other jobs with less hassle.
- If you decide to test, test something meaningful to your business, instead of using generic algorithmic tests.
- No developer is going to be Plug’n’Play to your business.
- Truly multi-talented people do exist, but they are few and far between. This is why we call them Unicorns.
- Being opinionated is fine, but beware of those who use buzzwords without any underlying knowledge.
- Train Junior developers continuously. They become valuable senior members of your team down the line and take routine work away from your more senior team members.
Good luck with your next recruitment!
