Peopleware is one of those books that show up on recommended reading lists for software development managers. Joel Spolsky was recommending it back in 2002. (It was written in 1987 and revised in 1999 and 2013). Chapter 16 (in the 3rd edition) begins with this vignette:
Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.
Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.
Manager: Do you work with flaming objects?
Manager: …knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.
Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It’s hilarious.
Manager: Well that sounds fine. I guess you’re hired.
Candidate: Umm… Don’t you want to see me juggle?
Manager: Gee, I never thought of that.
Hiring a Juggler
The chapter, called “Hiring a Juggler,” points out that no one would hire a circus performer without first seeing an example of their performance. And yet, the authors say, professionals in other fields can make it through a set of interviews without ever proving that they can do the job they’re interviewing for.
Software development interviews usually don’t have that problem anymore. But given the ongoing discussion of how these interviews should work, it’s worth thinking about what has gotten us to where we are now. Chapter 16 of Peopleware covers three alternatives to evaluating candidates simply by talking to them:
- The Portfolio: Ask candidates to come prepared with a portfolio of their work. For example, programmers would bring code that they have written.
- Aptitude Tests: Candidates are given an exam during the interview, and the results are used to inform the hiring decision.
- Holding an Audition: Candidates select a job-related topic to explain to their potential future co-workers in the form of a presentation.
Of the three options, the authors recommend the portfolio and the audition, and discourage using aptitude tests. They dislike the testing approach not because tests are useless, but because tests are only good at measuring entry-level skills like coding ability. The other two techniques, especially the audition, are better at measuring communication and interpersonal skills, which the authors argue are more useful over the course of an entire career. And companies should be hiring employees for the long term.
The Technical Interview As Aptitude Test
I have never heard of an interview for a programming job being conducted in the form of an audition, though I have been in situations where multiple interviewers are in the room with one candidate.
A programming portfolio is easier to assemble now that many programmers have examples of their work on sites like GitHub. Rather than just describing projects they worked on, which may involve proprietary code that can’t be shared with the interviewer, candidates can present their open-source code.
But since at least the late 1990s, the most common type of interview at software companies has been the programming interview. At its most basic level, a programming interview is an aptitude test as described in Peopleware, with all of the pros and cons of such a test. It is useful for evaluating whether a candidate can do what they claim to be able to do, namely write code. Interviewers use it primarily for that purpose, though they also look for a candidate’s ability to describe their thought process as they work through the problem. If an interviewer is doing their job properly, they’re adding value by conducting an in-person interview rather than handing the candidate off to an automated interview like those offered by CodeEval.
There is usually time in an interview for the candidate to describe projects that they have worked on. But for a coding interview, coding takes priority. The reason for this: evaluating someone’s performance in a coding interview can be difficult. It’s not enough just to present a problem and read the candidate’s answer. Any online judge can do that. The interviewer has to continually adjust the problem to make it easier for candidates who are struggling, or harder for candidates who are doing well, so that every candidate has a fair chance to show what they know (which may nevertheless be insufficient to get an offer). Coding usually happens on a whiteboard, so the interviewer has to evaluate the candidate’s program without the assistance of a compiler. And even with a carefully calibrated problem, there’s no telling how long each candidate will take to solve it. With all of this going on, there aren’t a lot of mental resources left over for other topics of discussion.
In a full day of interviews, the ones at the end of the day often involve less coding. At this point the candidate must be doing well, or they wouldn’t still be there. Their basic coding skills have been vetted. The interviewers tend to be higher up in the management chain. The aptitude test is over and the candidate can spend more time talking about their experience.
Why Developers Hate Coding Interviews
Developers like to write code. A coding interview involves writing code. So why do most developers dislike coding interviews? Here are a few answers to that (obviously simplistic) question.
Not all coding is equally interesting
Most programmers don’t want to write just any kind of code. They have opinions about what type of project they want to work on, at which company. Even ignoring factors like compensation and company culture, there are many ways in which some projects are more interesting than others: the technology stack; adding to an existing codebase vs. starting fresh; what part of the code they’re working on; and so on. Coding interviews focus on a specific kind of code: short solutions to programming puzzles. The less a programmer likes short programming puzzles in general, the less they’ll like coding interviews.
Coding interview problems often don’t reflect the type of coding a developer will be doing on the job
Companies generally don’t hire developers to write quick solutions to simplified problems that take 45 minutes to complete and are then discarded. So why are these types of problems used in technical interviews? Or as Quora user Ishan Dutta put it, Why are programmers in the software engineering job interviews tested on skills similar to a Topcoder contest irrespective of the fact that the skills required in the industry are entirely different?
Gayle Laakmann McDowell‘s answer to that question explains in detail why companies use that type of interview. There’s a good reason: These interviews are a way to assess a candidate’s problem-solving skills, with an emphasis on solving Computer Science-related problems. To accomplish this, the best interviewers focus more on problem-solving and less on knowing about specific algorithms or data structures. There’s also a not so good reason: A company may just be copying the interview process of well-known software companies like Microsoft and Google, even though their needs are different.
But regardless of the pros and cons, there isn’t an obvious alternative to the coding interview for evaluating programming ability over the course of a day or two. Some reasons why alternative interview methods are less than ideal:
- Testing for specific technology knowledge excludes good programmers who don’t happen to know that technology.
- Asking someone to explain their past projects is biased towards people who can explain effectively, not necessarily people who can do the work.
- Giving candidates a homework problem has several drawbacks: they may have someone else do the work for them; it is biased towards candidates with more free time; and because it requires negligible time for a company to send off a canned assignment, but potentially a lot of time for the candidate to complete it, it can be unfair to candidates.
- Having candidates work on a real project for one day makes it difficult to focus on characteristics that distinguish great programmers from good or mediocre ones, since real projects have a lot of simple tasks that almost any programmer can handle.
- Letting candidates use a computer during the interview can cause them to focus on syntax rather than problem-solving.
So although relevance to the job is a common criticism of standard coding interviews, it’s not clear that there’s a way to make the interview more relevant without adding a lot of undesirable characteristics.
Most programmers aren’t good at programming puzzles
Doing a difficult task that you’re good at is more enjoyable than doing one that you’re not good at. That’s why deliberate practice is hard: you’re continually working on things that are slightly beyond your comfort level. Most programmers focus on learning what they need to do their jobs, which generally doesn’t intersect much with what is required to do well on interviews. Interviews are already a high-pressure situation. Add to that the requirement to solve problems of a type that most programmers don’t encounter on the job, and you get a situation that most people don’t look forward to.
Proving That You Can Juggle Code
Coding interviews are imperfect exercises that most candidates dread. Even the interviewers would usually rather be doing their regular jobs than conducting an interview. But the alternative interview options have their own problems. As a result, many years after Microsoft started doing coding interviews, the software industry is still using them.
Coding interviews test for a particular type of coding fluency that isn’t captured by other forms of interviews. When run properly, they give the interviewer a unique insight into the candidate’s ability to think about and solve a coding problem in real time. Like a juggling act, a well-executed solution to an interview problem demonstrates a facility with coding and problem-solving that is difficult to fake.
If you extract a whiteboard coding solution from the high-pressure environment of an interview, the ability to do it well is kind of cool. Not only can you write code, but you can write it on demand, in front of an audience, and without a computer. It’s like the coding equivalent of these scenarios:
- Solving a math problem you haven’t seen before on the board in front of a classroom full of math students, not just at home in your notebook.
- Having a live conversation in French (assuming that isn’t your first language), rather than typing an email message in French with Google Translate open in another window.
- Making a presentation and fielding tricky questions from the audience.
I understand the perspective of programmers who just want to build systems that people will use, and who aren’t interested in solving puzzles for their own sake. But for those willing to develop an interest in it, there are a number of benefits to having a puzzle-solving mindset. What’s the best way to develop such a mindset? There are books that focus specifically on programming interviews (Cracking the Coding Interview being the obvious choice). They can provide a useful perspective. But with so many online judge available, it seems unnecessarily cumbersome to learn to solve programming puzzles from a book. So why not use a resource that allows you to submit your solution and get immediate reliable feedback? In other words, why not prepare for coding interviews by preparing for programming competitions?
There’s an obvious connection between coding interviews and competitive programming, and some less obvious differences between the two. But for most interview candidates, there are more similarities than differences. A programming competition’s short puzzles, time pressure, and focus on algorithms are all good preparation for coding interviews. As competitors get more advanced, the required skills diverge from those required for interviews. But by then any coding interview should seem rather easy.
(Image credit: Markus Lütkemeyer)