Learn how to avoid five common developer hiring mistakes and form a team of skilled professionals.
You liked a candidate’s CV and portfolio; now it’s time to invite them for an interview.
But before you do, make sure to polish your interviewing practices—this increases your chances of talent accepting your eventual offer.
A 2021 survey has shown that 58% of job seekers have declined a job offer due to a poor experience with the hiring process, usually during the interview.
So, to make the developer interview enjoyable for candidates and effective for your staff, you have to be aware of the common pitfalls and best practices for conducting one.
This article brings you the best direction to take when setting up dev interviews, everything from arranging the interview to the final evaluation.
Table of contents
Be clear on your hiring goals
Before you even begin writing the job description and inviting applicants for interviews, you have to identify what you are looking for in a developer. The vision of the perfect candidate will help you shape the interview process.
Software development companies rarely look for a developer considered a finished product.
The process of creating a good developer is usually more important than hiring a developer who has already mastered a programming language or who handles many different technologies.
So-called unicorn developers are difficult to come by, and their desired salary is way above the average.
Rather than looking for one, companies generally try to find developers that would fit the team and who can upgrade their existing skillset along the way.
So, when composing interview tasks and questions, be mindful of the goals you’ve set for your new developer and make sure they shape the interview process.
The goal shouldn’t be to find candidates who answer all the questions 100% correctly; it should be to detect those who fit your culture and possess sufficient knowledge to have the potential for growth.
Determining the hiring goals also helps you narrow down the scope of questions to include in the interview.
For instance, if you’re interviewing a candidate for the position of Junior Android Developer, you shouldn’t expect them to understand the intricacies of how Kotlin’s coroutines work under the hood, but they should be familiar with enough surface-level details to use them.
The same goes for discussing the code you saw in their portfolio.
Even if your technical roles have noticed some issues there, the interview gives the candidate the opportunity to understand the problem or offer explanations.
“The process through which a candidate finds a solution reveals the most about whether they can write code”Li Haoyi, Tech Lead Manager at Databricks
Talking about code and technology helps you see if the candidate presents solutions in a logical and structured manner and asks valid questions. All these elements enable you to assess if they are a person you’d want on your team.
Carefully pick your coding test
If you choose coding tasks according to the position you’re hiring for and let candidates use the same tech your employees use, you’ll be able to make an accurate assessment of how the candidates would perform in your company.
However, keep in mind that recycling is great, but not when it comes to coding tests for developers.
In other words, assigning candidates for each position with generic tasks may save you time initially but won’t get you an accurate picture of how a developer can contribute to your company.
A better approach would be to consider the position you’re interviewing a candidate for and tailor the coding test accordingly. After all, you’re not assessing their overall knowledge; you’re trying to see if they would manage working with you.
This is why it’s wise to conduct the developer interview in conditions that reflect the processes and tools your employees use.
Pinterest is a great example of how to test coding abilities. Their process is focused on tasks and technologies similar to what candidates would actually see in the company.
The company also provides candidates with computers with VCSode, Sublime, and other common IDEs so that candidates can rely on syntax highlighting, code completion, and shortcuts they’re used to.
Your coding test should therefore include the technology the candidates are most comfortable with, so that they don’t have to waste time figuring out new pieces of software.
You now know the ideal method of implementing a coding test, but what about its content?
If you look up developer opinions on testing, you’ll get numerous results with devs complaining about the process, or even talking about refusing to do lengthy and irrelevant coding tests in interviews.
However, not many employers would agree to hire a developer without first seeing them write some code. Joel Spolsky, the former CEO of Stack Overflow, strongly agrees.
“Would you hire a magician without asking to show some magic tricks? Would you hire a caterer for your wedding without tasting their food? I doubt it. Do whatever you want during interviews, but make the candidate write some code.”
The middle ground to keep both employers and candidates happy would be implementing coding tests and ensuring they’re concise and relevant to the position.
That way, you’re not only testing the candidates, but you’re also giving them an insight into what developers in your company do.
Communicate your interview process to the candidate
If candidates experience stress during the interview, their skills may not shine through, making you unwittingly turn the best ones away. By communicating the interview process, you let the candidates know what to expect and eliminate the uncertainty.
Have you ever noticed how you instantly become more productive when you’re nearing a deadline, but if the pressure gets overwhelming, your brain just crashes, unable to come up with any ideas?
That’s Yerkes–Dodson law for you.
Formulated more than a hundred years ago, the law states that pressure can boost performance, but only up to a point. When the pressure becomes too high, performance decreases.
Since job interviews are already seen as stressful, the candidates will appreciate all your efforts in making the process more manageable.
This lets them experience just the right amount of positive pressure to perform well, without additional stressors that would slow them down.
The most straightforward way to remove the tension is by listing the interview elements. When a candidate knows what to expect, they can focus on the task in front of them without worrying about the following interview stages.
For instance, Pinterest dedicated an entire blog post to their interviewing processes for developers. They listed all elements of the onsite interview and described each step in detail, together with tips on how devs can best prepare.
You could go a step further by mapping out the timeline of the stages, so that candidates know how long the interview takes.
It’s also helpful to inform the candidates in advance about the type of tasks they’ll do and if there are any specific task requirements. For instance, some employers accept pseudocode on tests, while others insist on real code they can run and test.
Either way, you should clarify such details ahead of time. That way, the candidate can prepare and avoid performance-affecting surprises.
Surprises are also unwanted in the scope of interviews. You should only discuss the aspects of programming relevant to the position.
“When a job application fails to accurately describe the job duties, this can lead to a breakdown in communication. A person may show up at a programming interview prepared for one type of test, only to encounter something that they aren’t equipped for.”Jeff Swartwout, Codility
Finally, don’t forget to inform the candidate about the equipment they’ll be using. Whether they have to bring their own computer or you give them yours, the candidate should know in advance what to expect.
Make the interview reflect your working environment
The only way to get a realistic portrayal of how a candidate would perform in your company is to turn the developer interview into an experience that reflects your actual working environment.
Of course, we’re not suggesting that you invite a candidate to spend a day in your office and handle your employees’ tasks. However, the tasks and questions you ask them should be comparable to those that your company usually encounters.
Burdening candidates with hands-on tests shouldn’t be a concern. In fact, developers prefer to have their technical skills assessed with tasks that feature real coding questions.
Let’s look at an example of an interview that included a real-life coding question.
Ram Patra, a senior software engineer, applied for a position at Spotify. At the onsite interview, interviewers presented him with a real issue that once happened in production.
They gave the candidate clues he had to use and find the root cause of the issue, which he did successfully. The interviewers then asked him to give a slapdash solution, as well as a more reliable, permanent one.
Patra later described the interviewing experience as one of the best ones he’s had.
Besides providing a good experience to the candidate, an interview that imitates your company’s working environment will also allow you to see how the candidate would communicate and collaborate with others, and whether they would ask for advice or extra resources.
Backblaze, a cloud storage company, adopts such an approach to developer interviews, by taking a collaborative path and working on problems together with candidates.
A mistake doesn’t mean that a developer has failed the interview. Instead, the company gets to see the candidate’s thought process on the way to the solution.
The lead engineer even participates in the coding test and discusses the process with the candidate as they work.
“It’s trying to simulate how we would treat each other if I was a co-worker sitting next to him and I asked him for help on a problem.”John Shimek, Backblaze
To sum up, tasking candidates with abstract tasks or brainteasers won’t help you assess the candidate. Even Google has ditched the practice.
A better approach is to give the candidate the opportunity to showcase their skills in the context of the position they’re applying for.
And unless they will have to code on a whiteboard once they start working, don’t force them to do so during the interview, either.
Approach the evaluation holistically
Perhaps the most delicate part of the hiring process, evaluation requires quite a bit of planning.
Teamwork is also imperative here. You can’t do a complete evaluation without the participation of everyone involved in different phases of the interview process.
As much as we’d like to help you out and give you a foolproof formula for objective evaluation of developer candidates, we’re sorry—there isn’t one.
Objectivity requires measurable criteria, which is next to impossible in software development.
Unfortunately, it isn’t sufficient to set a criterion such as does the test code work? No—0 points, Yes—1 point.
Coding is a process, and factors such as the time needed, the number and type of bugs, coding practices, and the code structure matter more than the end result.
Even if two candidates created the same app, you probably wouldn’t want to hire the one who needed three hours more and who produced needlessly complex code.
And that’s all just for the coding test section. Imagine the complication of trying to quantify soft skills such as effective communication or deadline estimation.
You could use a software developer interview evaluation form, like this one, provided by Grove.
This template allows you to grade different aspects with marks 1 through 5. Some of the categories are education background, programming languages, teamwork, and more.
Here’s an excerpt showing the questions you have to answer to get the most objective evaluation.
Note, however, that one of the questions is about the principles of great software engineering, which is itself open to interpretation.
It could therefore be more helpful to decide on several must-have skills you’re looking for, and supplement your evaluation notes with candidate-specific observations.
Such observations should be substantiated. For example, a note along the lines of “the candidate is detail-oriented” may not be too helpful for final evaluation.
But if you jot down “the candidate tested the code for bugs and covered all edge cases”, you know the exact extent of their attention to detail.
Li Haoyi, Tech Lead Manager at Databricks, whom we’ve quoted in a previous section, also advocates this approach.
“This is much harder than just writing down subjective feelings, but forces you to be slightly more rigorous about why you feel a certain way about the candidate.”
A final piece of advice for finishing a developer interview with an evaluation is to approach it holistically.
The interview process involves people from different departments and specializations, all holding different subjective opinions.
Since you’re not only hiring a coder but also a person to join the team and affect its success, you need feedback from all people who interviewed the candidate. Some will share their remarks regarding the coding skills, and some will provide input on the candidate’s soft skills.
When you weigh all the considerations, you’ll be able to decide whether to offer the candidate the job.
Developer interviews involve more than asking the candidate to come in and talk about their previous programming experience.
The interviews often include additional assessments, ranging from coding to soft skills, which help determine whether a candidate is a good choice for the position.
Whatever steps you decide to include in the interview, make sure they’re closely related to the position you’re hiring for. This helps candidates form a clear picture of their future role and assists the interviewers in evaluating whether they are a good fit.
By applying these principles to your future dev interviews, you’ll have no problem forming a team of skilled and motivated developers.