The best coding interview I ever took

Up your coding-interviewer game with these tips

Coding interviews are secretly dreaded by almost every software engineer, and a cottage industry of books and websites seems to exist just to ameliorate that dread. But the truth is that the INTERVIEWER is often not very good at the process and not getting specific enough feedback about his or her not-goodness.

In the interest of helping both sides constructively, I wanted to point out some features of the very best coding interview I’ve ever taken as the interviewee. It was such a great experience that I honestly had to raise my own bar as an interviewer… and hopefully now I can help a few other people raise theirs.

Prep in advance, save time in the interview

There is a strong correlation between how prepared the interviewer is, and how much of the interview will be devoted to actually writing code. In the best interview I ever had, basically we spent 100% of our time testing my coding ability because the interviewer was so well-prepared.

This interviewer came in with a laptop pre-loaded with a problem that was fully expressed — HTML, CSS, and a space for JavaScript — in an in-browser editing environment (e.g. Codepen, JSFiddle, etc.). We wasted little time fumbling with the mechanics of shared documents, whiteboards, etc. More critically there was a minimum of wasted time understanding the problem at a conceptual level, because I could see it as STRAIGHT CODE rather than a verbal description of a problem that depended on the interviewer’s ability to express.

Also it was clear to both of us whether my code actually did what I was asked to do! There was no ambiguity or subjectivity whatsoever: shit worked or it did not. As anyone who has done whiteboard interviews can tell you, the vast majority of non-trivial problems are not completely resolved in production-quality code because of the drag imposed by the the medium.

Side note on preparation: I’m always surprised how strong a correlation there is between the seniority of the engineer and the odds they have actually read your resume. When you spend a day at a company and the most senior person can talk to you knowledgeably about your previous work but the most junior person has no idea what job you’re applying for or whether the questions s/he is asking you are at all relevant… that at least puts the lie to the idea that it is simply “lack of time” that leads to bad technical questions.

Allow the interviewee to use the full range of dev tools

The best interviewer ever told me he wanted to see how I used the normal set of dev tools including JavaScript console, element inspector, and WEB SEARCH. I’m one of those people who gets super flustered during interviews if I forget some trivial part of an API, like whether a certain function returns a string or an array. I appreciated the chance to do a 20-second web search that cleared up that question in my mind, instead of making me crazy by forcing me to guess. Come on, I wasn’t Googling “how do I write teh JavaScriptz?”… more like, “Oh there is this super obscure CSS property I’ve never seen before but can use constructively here”.

In this day and age I think it is so much more important to see how devs use tools than to somehow prevent them from getting outside help. Any JavaScript dev who tells me that they never peek at Stack Overflow is a liar or an idiot. So why is it somehow still considered a quasi-moral virtue to cut off interviewers from their normal workflow instead of observing it in action?

Build up, don’t cut down

Great interviewers — almost always the most senior ones — invariably start with a smallish problem, and only increase the scope if you prove you can succeed with it. Mediocre interviewers — often the more junior ones — generally start with the biggest and most ill-defined scope, and cut it down once the interviewee is floundering around.

Not only does the big-to-small strategy often lead to unnecessarily awkward interactions, I believe it also tends to filter out qualified applicants who have even slightly shaky self-confidence aka imposter syndrome. It might surprise non-coders to know how much of a coding interview is actually just about not quitting on yourself… but if there is one thing I could tell every woman and person of color in the world, it is that. You need to have skills, but there’s a tactical part that is about being able to see it as a game rather than a reflection of your intrinsic human value. That’s the part that your young Teflon-coated white or Asian male is just better at than you, probably since he has been told he is the natural-born shit every day of his life and you haven’t — actually I’ve seen research that suggests it’s because we have learned we must completely succeed at a task or we have failed totally, so partial success is harder on us — but ladies and people of color, you need to make a promise to yourself that if you are going out, it won’t be because you quit on yourself.

Real-world context

I do infinitely better on questions which are presented in a real-world context that I care about. If you asked me to do a recursive depth-first search on a tree-shaped data structure, I’d totally stutter and choke. I would psyche myself out, basically. But if you asked me to write a polyfill to look for something in part of a DOM, I could come up with a decent piece of code. They’re the same question in a 45-minute interview context, one does not test coding ability better than another for a web developer.

The best interviewer I ever met used simplified versions of 3 real problems that he actually sees on the job. That was great because it was a very efficient way to show me something of what my actual day-to-day work would be about. But more importantly, he could see my real-world problem-solving in action and we could compare our solutions. When you’re potentially going to be teammates with this interviewer, it doesn’t help either of you to waste your few minutes together trotting out some tired old CS boilerplate like reversing a linked list or re-implementing strstr().

Eng managers: mock interview with your devs

I have been an engineering manager myself, and realized that I have not put the time into developing my team members as interviewers. I have no idea what most of them asked in their interviews, or what their interviewing style was.

Engineering managers need to start taking mock interviews with their devs, and giving them feedback about their interviewing skills. Most of us just default to whatever practices were current when we got into the industry, and there is often substantial room for improvement over time. Particularly in terms of attracting more diverse engineering teams, eng managers could be having a much stronger impact than I believe they do now.

TL;DR

• Load up code in an in-browser editor beforehand. Whiteboards are over.
• Let candidates use normal dev tools including web search.
• Start with smaller questions and build up on success, don’t start with a gigantic question and cut down on failure.
• Use questions from your daily work context, not generalized abstractions.
• Eng managers: subject yourself to your devs’ interviews and give them feedback.

If you like this post, don’t forget to recommend and share it. Check out more great articles at Code Like A Girl.