By Geoff Roberts
Sorry, I don’t buy it.
You simply cannot distill a reasonable understanding of a person’s skill level in programming down to a 20-30 minute session. I don’t care what magic wand you wave.
Software development takes time to think, to evaluate, to plan and to deliver. Can’t be done convincingly even in a 1 hour interview, and I have yet to see a believable automated skills test that really reveals skill level.
It’s the difference between book-smart and street-smart. Those automated skills tests give you candidates who are good at automated skills tests, not someone who understands developing modular codebases that can grow and respond to changes as the business needs change, or deal with that grumpy developer on your team.
Even considering that you can measure someone’s knowledge, and assuming that’s a predictor of their future at your company is folly and a sure sign of ridiculously short-sighted thinking. It’s a “code smell” for an organisation.
At the end of the day, it’s impossible to reduce someone’s future to a score.
You want to know if someone can do the job?
Check their CV, call 2 references, and if they clear those hurdles then hire them for 1 week or maybe 2. No even on a probationary basis. Just a simple short-term contract with possibility for renewal.
See how they interact with the team. See if they can get to grips with the software stack. See what their thought processes and approaches to problems look like. If they’re not a complete waste, hire them longer term and train them up.
They not only get a chance to show they know their stuff in a natural way, but they also get a chance to see what life is like in your environment.
By far the ability to work with others and willingness to learn new things outweighs specific knowledge. An algorithm (or language or framework, etc) can be taught. Attitude is everything.
Hire someone for one or two weeks? Who would take that offer? Only the most desperate idiots I can imagine. I have a bunch of other companies that offer (or are going to offer) me permanent positions.
If you still cannot make up your mind after 3 interviews I don’t want to work for you.
There’s stupid simple way to test interview process - let your current engineers go through it. I bet best performing ones will fail mentioned algorithmic and abstract assignments.
Sometimes the best value to the team bring a person who doesn’t know algorithms but can e.g. foresee problems or ask “stupid” questions which lead others to think differently.
I like this article and thread! A lot of interesting and personal experience opinions.
Want to see authors replies on those messages
3 interviews? I could see 1 hour for going over past experience and 1 hour for trying to get a sense of the person, but what’s the third one for? Given that I believe interviews don’t really tell me a lot about how someone performs, that seems wasteful.
This seems like semantics to me. If it bothers you that much, then call it a “1 month induction” with a following “2-3 month probation”.
The bottom line: try someone out in situ. See if they can code. See if they really can handle pair programming. See if they have a decent approach to tricky situations. See if they can bring information you don’t have to the organisation.
It’s about far more than if they can repeat the merge sort off by heart.
I hear you! Automated coding assessments definitely aren’t a magic wand. What I’m advocating for is two-fold…
For junior engineers, an automated coding assessment is a useful tool when hiring because you’re giving candidates an opportunity to showcase that they have some baseline level of skills. It can be an effective pre-screening tool.
For more senior engineers, we recommend giving them a more thorough coding project that closely mimics the actual experience of writing code at your company. To your point, even in a couple of hours you’re not going to fully understand whether or not they’d be a perfect fit on the job. But you will have a sizable coding sample, and you can use code playback tools to watch their thought process unfold and get some sense of their problem solving ability. Likewise, you can cap the project at a couple of hours then do a pair-programming session with the candidate to really dig into the decisions they made and what they might do next. This is where you’ll really learn about their problem solving ability and what they’re like to work with rather than using pair-programming to watch them code live.
Hiring devs on a contract basis prior to offering them a full-time role is a great practice if you can make it work. I think lots of developers would shun the idea of a 1-2 week contract, but I’ve seen lots of developers start working with a company on a long term contract basis then eventually move to full time if a good fit is realized.
Finally, agreed that attitude is everything—getting a sense of attitude, ambition, and collaboration style is a critical part of the interview process. Thanks for sharing your thoughts!
It’s definitely on the employer to make sure they’re being mindful of each candidates’ time—to your point if you’ve conducted three interviews and aren’t ready to make a hiring decision, you’re probably not using that time very effectively.
Giving the candidate the opportunity to complete a coding assessment in their own time then talking through it together via a pair programming session does two things. First, it gives the candidate the ability to complete the assessment just as they would actually write code in the real world rather than putting them on the spot. Second, it gives hiring managers and opportunity to ask questions that give them insight into thought process and what the candidate would be like to work with.
Your use of coding assessments and your hiring workflow in general are an important early impression of your company that can actually build credibility with developers if handled appropriately!
I completely agree with your point—if you’re building a hiring process for engineers, you should absolutely ask your current engineers to go through it as part of basically QAing that process. But the point here is to make sure that you’re using coding assessments that much more closely mimic the process of writing code at your company. If you’re coding assessments are abstract, that’s a failure on the part of the hiring company.
Agreed—expecting devs to demonstrate that they know algorithms by heart has little to do with the work they’d do on the job. Let them complete an assessment in their own time in an environment in which they are most comfortable, then discuss the decisions that they made with them and talk through what they might do next. You’ll learn a lot in the process.