Why All Interviews Should Involve Writing Code

As a hiring manager I have done a lot of interviews. As you talk with other hiring managers about hiring engineers there seems to be this debate about whether candidates should write code in an interview. I believe that any candidate who expects to work on my team better be able to write code on a whiteboard in an interview. I am not talking perfect code, and I am not even saying the code has to be written in a specific language—but in order for a candidate to be hired into a software engineer on my team that is a minimum bar. I am sure some people are thinking, well that means that you might miss out on the good candidates—so I will elaborate as to why I do not believe that to be the case.For any person in a software engineer role, I would expect that a substantial amount of their time would be spent writing code. I am not going to get into the philosophical argument about design time versus coding time (I can save that for another entry), but I will say that building their piece of the product is a basic I expectation. And in the case of my team, our product is software, and that means any engineer better be able to write code and make their contribution. So I believe it is fairly clear the ability to write code is a job requirement and therefore should be tested, measured, or quantified in some way during the interview process.There are a series of objections one typically hears about coding in interviews:

• Writing code on a whiteboard, or notepad isn’t comparable to writing code at a terminal as one would do in a job.
• When you are writing code at your job you have all sorts of resources (books, Google, your peers, etc.) at your disposal.
• If a person has accomplished so much on their resume, and they have xxxx certifications, then they can do the job.

It is a true statement that if a person can write code at their computer it is much different than standing up nervous in front of a whiteboard. That is also why I don’t ask people to implement a metrics system in an interview. I ask them to solve simple problems—most of which can be solved in one white board (so not more than 20 lines of code max) to illustrate how they translate their thought into code (I promise to post some of my favorite interview questions at some point). If they can algorithmically solve a problem, and have a solid understanding of data structures, then isn’t it important that they be able to turn those solutions into something that can be compiled?Sometimes people are concerned that the standing up thing throws people off their game and hurts their performance, which is why I adapted the write the code on a pad of paper approach. This is also great because I can take their code sample into our debrief meeting and discuss their approach with the other interviews. The questions that are asked in these coding interviews do not involve complicated libraries—they require the syntactical knowledge that most students receive in an Introduction to Programming course. Furthermore, I will encourage students to write it in the language we use to do development (because then you can also assess at a basic level that person’s knowledge and style with a particular and relevant technology) but I always let them pick their language (I do try to make it object oriented though, since that is the type of development we do here) and I do not fault them on choice. This also allows them to be comfortable and be able to perform the best they can on a problem. But as an interviewer it means sometimes brushing up on languages you don’t love to use (for me that would be Python and Ruby).As for resources, if a person wants to use a library but can’t remember the syntax (as is often the case for hash tables in interviews) I tell them to write out the APIs as they would implement them in the library. This means that the candidate doesn’t get blocked on the fact they can’t remember the parameters to pass into some API they barely remember, which allows you to focus on the problem at hand—but it also demonstrates how they might design an interface. Often times, senior candidates can even articulate all the interesting aspects of interface design and what are the pros and cons of their approach. Another thing you can ask candidates is where they might go to find information. Resourceful people are the type of people I want on my team. In other words, the resources aspect of the argument is easily overcome if you are a savvy interviewer and make sure to remove this as an obstacle for your candidate.And finally, regardless of what a resume says, you should always approach candidates with the assumption everything isn’t always true. It sounds mean to assume that people would lie—but many do, and many more embellish. Understanding what is on the resume and how it translates to your business and your team is an important and necessary part of the interview process. Plus, if worse comes to worse you can compare what all those accomplishments really mean in comparison to other candidates and your own team on a set of baseline problems. In my opinion there is never a reason a candidate shouldn’t be able to write code. Your job as an interviewer is to set the stage in such a way so they can clearly demonstrate their ability and put their best foot forward.Another stylistic thing I do is I almost always ask them (once they are completed with their first pass at the code solution) to explain it to me (since being able to explain your code is an important skill). Then if there are bugs I try to see if they will catch them, if they don’t I will suggest they walk through an example, if they still don’t I will let them know there is a bug. I like to see that people can identify and fix their own mistakes with a little help (since this is a reality in the life of a software engineer—everyone should know the basics of debugging). I then follow up with a question about testing. Good software engineers should have some basic ideas on how they would test their solution. And then finally, since the code is usually messy (because of the medium), I ask them what they would do if it were production code (some people say comments, formatting, moving methods around etc.). A lot of people will also delve into running time, performance, space usage, etc—all informative lines of questions that can help you understand more and more about the candidate, their approach to problems and their experience thinking about their code.There is a ton of value in doing this line of questioning. I would not judge a candidate on these type of questions alone (since it takes a lot more than being able to write code to be a successful engineer), but I believe any good software engineer should meet a minimum bar.