Last week I asked a question on Twitter about how interview processes can be improved at companies like Google, Amazon, and Microsoft.
What would make you feel more confident about interviewing at a big/famous software company like Google?
— Aja Hammerly 🦖 (@the_thagomizer) February 16, 2018
I got a lot of great replies, and one of the issues that came up was a lot of people that hate whiteboard coding. So at CoffeeOps on Friday I asked why people hate whiteboard coding. Again I got a lot of passionate and interesting replies. In both of these forums though, I noticed that people had a lot of assumptions about what made a whiteboard answer good. Most of those assumptions were not things that I and others I know look for in whiteboard interviews. So I decided to share what I’m looking for in a whiteboard interview.
What I’m Not Evaluating
There is a pervasive belief that interviewers expect candidates to be able to write syntactically correct code in one go without any mistakes, planning, or backtracking. And, sadly, I’m sure some interviewers expect exactly that. Those people are bad interviewers.
I’m also not looking for you to implement algorithms from scratch. I don’t ask these questions because I don’t want to work with people who write their own sorting and compression algorithms. I want to work with people who use well tested libraries and spend their time on the business specific problems.
And I don’t care what language you use. I assume that if you are otherwise a competent developer, you can learn a new language when needed. I also don’t give bonus points for using a language I like or a language that’s hard. Personally, when I interview I use Ruby because I know it well and I’m confident when using it.
What I Am Looking For
I use the whiteboard portion of the interview to try to figure out a couple of things. First, I want to know that the candidate can come up with at least one approach to solving a small technical problem. I’ve started to ask candidates to tell me their plan/approach and the language they are using before they start writing code. I also encourage the candidate to ask me questions about the problem. Candidates who do well usually ask about edge cases.
Second, I want to find out if the candidate can explain their approach to me and justify any trade-offs or design decisions. Experience tells me that candidates who can tell me a high-level plan are more likely to succeed once we get to the actual code. Also, in DevRel we often get asked: “how would you solve this problem I’m having?” Asking the candidate to explain how they’re going to solve a coding problem is one way I evaluate how a candidate might do in customer scenarios. Also, I want to work in a culture where people can respectfully challenge each other and respond to those challenges. A respectful challenge I might use in an interview would be something like, “why did you use an array instead of a queue?” or after a candidate has finished coding I may ask “This works, but can you make it more efficient?” I’m not trying to tell the candidate their approach is wrong. I just want to understand how they made the decision they made and if they can communicate that to me.
The third thing I look for is if the candidate can translate their plan into code. In DevRel we teach through our code, so the code we write needs to be simple and idiomatic. As we go I may point out missing semicolons and misspelled words, but I don’t penalize folks for those mistakes. And if the candidate wants to use a library function, I usually allow it as long as the candidate can define the inputs and outputs. I don’t expect the code to be correct the first time through. In fact, I prefer it if a candidate runs into trouble and needs to rethink their original solution. Being able to solve problems, debug, and handle changing requirements are important for success in most tech jobs, and watching a candidate rethink their solution shows how the candidate deals with those challenges.
After the candidate has completed their code, I may ask for the Big-O runtime analysis. Or I might ask questions about the data structures used in the answer. A lot of people object to these type of questions, and I know they can be intimidating. I ask them because Big-O, data structures, and other CS fundamentals are one way programmers communicate about the merits and drawbacks different solutions. Runtime and space usage aren’t the only things we should use to make decisions but common vocabulary is helpful if we want to avoid “well my gut says Nick’s code is better” as our primary decision-making criteria.
Other Thoughts
I’ve written before about how I think all interview tech processes are awful. I prefer to run interviews as a conversation where we chat about the things you’ve done that are relevant to the job, and then we work together to solve a technical problem. In the past, I’ve run the whiteboard portion of an interview more like a pairing session. I give feedback, spot errors, and help with syntax. But in the 100+ interviews I’ve done, most candidates find the collaborative approach more distracting and nerve-wracking than helpful. So now I sit quietly and say encouraging things like, “Looks like you have a great start, would it make sense to do _____ next?” and “This looks great, keep going.”
The other big misconception I feel many folks have is that the interview is a confrontation. At least if you are interviewing with me that isn’t the case. As the interviewer it is my job to figure out why we should hire you. I want to find the things you are good at. If you are struggling, I may ask the same question a different way. I want candidates to have multiple chances to succeed. At Google, my feedback goes to a committee of senior folks who make the hiring decision. Since that committee never meets you, I take a lot of notes, many of them verbatim, during our conversation. I refer back to those notes to ensure I’m being fair when I write my recommendations for the committee. I try as much as possible to include direction quotes from the interview so that my error-prone memory isn’t an impediment to folks getting hired. Focusing on the positives and taking extensive notes makes me feel like I’m doing everything in my power to help candidates get a chance at the job.
I want to close with something I said a few years ago. Good interviewers want you to succeed. They aren’t trying to make themselves feel better by watching you struggle. They aren’t looking for reasons to say no. Whenever I make a no-hire recommendation I look back through my notes to see if there was somewhere that I messed up. Hopefully, that is reassuring to you. I know it has been for me.
Top comments (0)