It’s October, the time of year when leaves start to fall from the trees, and companies start to recruit college students for summer internships. Last week, I spent half a day interviewing some of those candidates. I also came across a long Hacker News thread called I Hate HackerRank. So I thought it would be a good time to revisit the dreaded coding interview.
No one loves interviews. For the hiring manager, it’s great to have a growing team. But there’s also the hassle of going through countless resumes, and the worry of hiring the wrong person. For the candidate, getting called in for an interview is the goal. But that also means a stressful day of having their code picked apart. For the senior developer conducting the interview, being asked to do so means their manager trusts them with an important task. But they would probably rather be back at their desk writing code.
With all of these conflicting emotions, it’s not surprising to see rants from developers about the coding interview process. But there are some good reasons why interviews are the way they are. To help understand those reasons, let’s consider coding interviews from three points of view.
The Hiring Manager’s Perspective
The hiring manager’s goal is to find the best match for their open position. This means finding a developer who is qualified for the job, and who also enjoys the work that they’ll be asked to do.
To reach this goal, the hiring manager has to do a few things. First, they have to find candidates. The best way to do this is to have an existing network of contacts that they have been keeping in touch with. Beyond that, there’s the popular but far less effective approach of posting job listings and going through resumes.
Having found promising candidates, the hiring manager then has to organize an interview process. This means interrupting some of their most productive employees and asking them to conduct interviews. At this point, the idea of automated pre-screening using a tool like HackerRank starts to sound interesting.
Despite a manager’s best efforts to craft a perfect job posting and select only the best resumes, there’s still the chance of bringing in a candidate who is better at talking about coding than actually coding. Hiring managers would love to have a way to filter those candidates out without scaring off the good candidates.
The Interviewer’s Perspective
Let’s turn to the next group, the people who are asked to evaluate candidates by asking them to do some kind of coding test. Except in the smallest of software companies, the hiring manager usually enlists other developers to help in the interview process. And while the hiring manager can set guidelines about how the process should work, the interviewers ultimately decide how to interpret those guidelines. That gives them a lot of control over the experience that candidates have.
An interviewer’s main goal is to form an opinion about how the candidate will perform on the job. After the interview, they will try to convince the hiring manager and their fellow interviewers of their opinion, or at least try to present their opinion in a coherent way.
Interviewers are asked to collect information about several aspects of the candidate’s fitness for the job, including specific technical knowledge, communication skills, and general problem-solving ability. But these aspects are not all created equal. While evaluating someone’s communication skills requires a fair amount of judgement, grading performance on a coding problem is closer to a pass/fail outcome. It’s not completely binary, which is why hiring managers use human interviewers rather than outsourcing the job to an online judge. But it is possible to walk through someone’s code using test data, and decide whether their solution passes modulo a few minor bugs.
The desire for a firm opinion about a candidate explains why interviewers emphasize coding questions over other potential topics. It’s an easy way to collect specifics: the candidate didn’t handle edge cases, didn’t use an efficient algorithm, or maybe didn’t produce much of anything. It may even explain the interview war stories that some people report about interviewers who just ask gotcha questions to give them an excuse to reject everyone.
The Candidate’s Perspective
Finally, we get to the star of the interview, the developer who is trying to land the perfect job.
The candidate’s goal is primarily to make a good impression during the interview. But they also want to get enough information about the position to see if it will be a good fit for them, assuming they have the financial luxury to walk away from an offer.
Candidate perspectives can vary widely. Some developers like algorithmic problems. Maybe they spend a lot of time on competitive programming, or they just want something they can study for and be done with. Other developers prefer technology-specific coding problems, like how to connect to a particular database and execute a stored procedure. Still others think the whole idea of coding during an interview is silly, and would rather go over code from their GitHub account.
Despite these differences of opinion about what makes a good developer interview, I suspect that there are a few things we could all agree on. Here are some suggestions:
- The interviewer should give the candidate a chance to demonstrate what they know, and should give them their full attention during the interview.
- Given that the interview is already a stressful situation for the candidate, the interviewer should not rely on questions whose only purpose is to rattle the candidate and see how they react.
- Keep the number of interviews reasonable. Does a hiring manager really need more than four or five interviews to assess an individual contributor?
All Interviewing is Flawed
Coding interview expert Gayle Laakmann McDowell has concluded that “all interviewing is flawed“. Developers can rant all they want about it, but there is no company that uses a perfect process, because all of the processes have pros and cons. At best, a company can pick the one that most closely meets their constraints and goals.
That’s not to say that the coding interview process can’t be improved. But if someone really is interested in improvement (and not just ranting), the starting point is understanding what each party is looking for in the process.
Software companies provide developers with jobs, so they need a process that works for them. But using a process that developers don’t like can turn off good developers, who may decide after a bad interview experience that they’ll tell all their friends not to interview with that company. So the process has to work for developers as well. And finally, the process works best with interviewers who feel like their time is being put to good use. That means that only serious and qualified candidates should make it to an in-person interview.
I think some kind of automated interview process makes sense in the early stages of evaluating candidates. It’s analogous to the CAPTCHAs that we often have to solve on the Web to prove that we’re human. They discourage some bots, at the expense of annoying real humans. Similarly, automated programming tests are intended to compel a candidate to prove that they’re a programmer. The goal is to discourage non-programmers from applying for fun-sounding programming jobs that they’re not really qualified for. The trade-off is that these tests annoy many real programmers. But we’re still in the early days of using online judges for interview purposes, so I expect that they will improve over time.
In the meantime, here are some competitive programming training tips.