Developers hate being interviewed. They detest the high-pressure environment, coding on the whiteboard, the artificial feeling questions and judgment they undergo. Many would argue that the traditional developer interview, including writing code on the spot, is broken.
Can't you just take them out to coffee and talk about the previous projects? Can't you just go to GitHub and review their code? Can't you just give them an 8 hour homework assignment and see how they do? Can't you just temp hire them for a while and see how they do?
Coding interviews are not broken and I would like to explain why. First let's recognize that there is a broad spectrum of hiring practices. At one extreme, you could just hire the first person whose resume looks good and talks a good talk. On the other end, you could give them a 6-month trial with real projects and pay, but only offering the job at the end if they meet expectations.
There are two perspectives that we need take into account: 1. the candidate perspective - would like to get a good feel for the company without experiencing too much stress or discomfort and be able to accurately represent one's self 2. the hiring perspective - looking for a comprehensive evaluation of candidate's abilities and fit without spending too much time or money
The ideal process maximizes both dimensions. Let's looks at some of the different approaches.
We'll start with the resume + chat approach.
| X resume + chat
|
candidate |
perspective |
|
|
------------------------------
hiring perspective
This approach is pretty comfortable for the candidate. They won't have much pressure, as long as they're able to communicate clearly.
But, you may end up hiring someone who can barely code. Most people don't intentionally lie, but as humans we tend to think of our skills and contributions as higher than they really are. Some people are great at talking about the projects their team has worked on. This makes them seem very smart (and they may be in other ways), but ask them to develop some code, and they can't. Good communicators are an important part of the team, but if you're hiring a developer, they also need to be able to code.
Next, let's talk about the 6-month on-the-job trial.
|
|
candidate |
perspective |
|
| X trial
------------------------------
hiring perspective
You're asking someone to give up months of their life so they can be judged every day. Changing jobs is not a simple process. They'll need to figure out health insurance, fill out tons of paperwork, learn your codebase, possibly move to a new city (with their family), all with a good chance that it won't work out! If they have any other offers, they're going to take the other one. You will only end up with the leftover candidates.
Candidates with no experience are usually willing to go through this process (it's called an internship). Even if you don't hire them long term, they've gained some experience for their resume.
On the other hand, internships are a longer-term investment for the hiring company. An intern will need a lot of help coming up to speed and doesn't bring the same skills as a veteran.
Let's do a separate graph for internships.
|
| X internship
candidate |
perspective |
|
|
------------------------------
hiring perspective
If they are on GitHub, you should take a look at their work.
|
| X code review
candidate |
perspective |
|
|
------------------------------
hiring perspective
This one is in the upper right quadrant of the graph!
Unfortunately most candidates aren't doing their work in public, so it's hard to make this a standard part of your hiring process. You can't ask them to bring in code from their current job.
This approach doesn't give you an feel for their personality, so you will need to supplement it with something else.
What about take home assignments?
|
|
candidate |
perspective |
| X homework
|
------------------------------
hiring perspective
Asking the interviewee to set aside several hours before you've even met is inconsiderate. If you meet in person first, and verify personality fit and interest then it's not as bad.
If the candidate is valuable, and has gained attention from several hiring companies, they are less likely to take the time for your cute little project, especially if other companies have also given them homework. You're creating a filter that drives away the good candidates.
Now let's look at the more traditional approaches, starting with on-site coding interview.
|
|
candidate | X on-site
perspective |
|
|
------------------------------
hiring perspective
From the candidate's perspective, it's not perfect, but it beats some of the approaches above. At least they can be present and do their own evaluation of the people they might work with. It also gives them the opportunity to really sell themselves.
It's hard to beat an onsite interview from the company's perspective. Not only do they get to check skill, but also personality fit. The process isn't perfect, partly because of nervousness, partly because of the imperfect representation of a real work environment, but it's not bad for the short time period.
Coding questions over the phone.
|
|
candidate |
perspective | X phone screen
|
|
------------------------------
hiring perspective
This one works nicely for the hiring company, because it's very cost effective, and is a pretty good way to measure basic technical skill.
Candidates don't love this approach, most developers don't really like phones, so this part can be a little stressful. It can be hard to really sell yourself in such a short time period. It's also hard to know what the interviewer is thinking when you can't see their facial expressions. However, they will get to write code using a computer, and talk to a real person.
If your developers have past colleague that they highly recommend, this is a very good indicator.
|
| X past colleague
candidate |
perspective |
|
|
------------------------------
hiring perspective
You'll still want to do an on-site interview for verification purposes, but it doesn't need to be as in-depth, and you can probably skip the phone screen.
You need to ensure you're employee's know how valuable this is and are willing to take an active role here. Your employee who knows the person is much more likely to pique their interest than a cold call from your HR representative. It's pretty common for companies to have incentive programs for this kind of thing.
The main negative here is you'll quickly run out of these people.
It's good to have a standard process, but you should be willing to adapt it based on the candidate. Your standard process should definitely incorporate on-site interviews and phone screens with code. It's important to make sure you're executing each of these steps effectively. In particular, make sure you're asking good questions and avoiding bad ones.
