Bombing the algorithm question

A modest proposal for making tech interviews better for everyone

Silicon Valley is a weird world.

I can legitimately claim to be what passes here for a senior developer. I’ve cofounded one startup, helped several on their products and built apps used by tens of thousands of monthly paying users. I’ve played a role in hiring decisions, met with investors, instituted engineering policies, managed product launches and so forth. I’m not the most experienced developer out there, but I’m not a rube either.

Yet until yesterday, believe it or not, I had never been in an interview with an algorithm question. And I bombed it. Royally.

To be specific, I semi-bombed one question on one interview and totally bombed three separate questions on another interview. It’s not clear how I managed to avoid algorithms in interviews altogether until this point in my (albeit, still young) career. But I can tell you that as someone who knows that he can build anything, bombing toy algorithms during an interview is a humiliating experience. <soul_searching>

As with any standardized testing situation, the algorithm portion of an technical interview says more about whether you have been taught to the test more than anything else. The fact is that shortly after my interview ended, it took me about 30 minutes to implement solutions to the questions that I flubbed, far below the time I was given.

My post-interview success isn’t because the interview gave me a chance to prep — believe me, that would be giving me too much credit for how far I got. It’s because I didn’t have to do it with some other developer’s face on my screen, judging my performance on a question that I’ve never had to deal with in my life (and frankly, probably never will). To the credit of my interviewers, both were very kind and professional, but that’s not the point. It’s just hard to be put on the spot like that, especially when you didn’t spend four years being put on the spot with those kinds of questions in exams, homework assignments, quizzes, etc. And it’s not clear what the experience proves.

Now, you may be thinking that this post is going to end with me yelling, as I have before, that algorithm questions are useless.

Not exactly.

After much hemming and hawing last night, I resolved that regardless of the interview algorithm’s merit, it would behoove me to get really good at it. So I got my ass over to LeetCode, a site where you can drill hundreds of algorithm interview questions, and I started doing a few.

First observation: Oh shit, these are really fun to work through! Maybe I’m more of a CS major at heart than I knew. Shoulda done this earlier.

Second observation: It’s interesting. As I do each question, subsequent questions seem to get easier because I’m becoming more familiar with the fundamental programming concepts used. More familiar isn’t quite right. I’m already quite familiar with recursion, hash tables, tree structures, etc., and have used them many times in the past, but I can feel the concepts coming to the fore of my mind in a way that hasn’t happened before. They’re all there together, building off of one another, helping me in this moment get better at one part of programming: optimization. In that sense, this experience is quite unlike preparing for the SAT.

Third observation: My dismissal of algorithm questions has been premature but not without merit. I can now see why these questions are asked, it does have some correlation to intellectual ability and knowledge of basic concepts. But, compared to asking me to talk through a feature or giving me a take home, this seems to have a relatively low ROI. You should know from talking with me and looking at my resume that I’m clearly an intelligent, sharp human being. So if that’s out of the way, how exactly is giving me an algorithmic brain teaser, one that I could easily hash out on my own outside of an interview, going to show that I will be a valuable team member?

Fourth observation: I feel better about myself. I’m clearly capable of doing well on algorithm questions in interviews, it’s just a matter of practice. Confidence restored. </soul_searching>

Based on these observations, I’ve arrived at a few conclusions:

• I personally can’t think of a situation where I would want to ask someone to do an algorithm question during an interview. I admit now that there are some grounds for doing it, especially if you’re interviewing for a company that does a lot of algorithm-y type work, as one of my interviewers claimed, though I’m not sure what that means exactly — as if I strive to write inefficient code! Unless you’re writing firmware or some such, I don’t see how asking me to implement an algorithm on the spot is going to be the best use of everyone’s time. In the real world, given the infinite ways to optimize a large web app, reimplementing some standard library function using quicksort is considered bad form; there are almost always lower hanging fruit.
• I think that whatever its merits, the algorithm question is a relatively poor source of information that’s biased in favor of a certain demographic with a specific kind of educational background. There are just too many potential confounding factors. And especially during a phone screen, the algorithm question can be a blocker: I didn’t get to demonstrate how awesome I am at thinking through engineering challenges or at pair programming because I simply bombed step 1.
• Finally, if we were to think of an interview as an optimization problem and if we wanted to optimize for homogeneity, quizzing on algorithms would be the standard operating procedure par excellence for achieving our goal. That’s probably a bad sign.

Given these conclusions, I just have one modest proposal:

• If you’re going to have an algorithm question, for the love of God, direct candidates to LeetCode and tell them beforehand that you highly recommend that they prepare by doing specific questions (no more than two or three) that you’ve chosen. The questions shouldn’t be the ones that you plan to quiz your candidates on but they should be related. If you’re going to give a recursion question, tell them to prep on a specific recursion question, etc. You’ll get a better idea of whether a candidate can is good with algorithms when you know that you’ve taken steps to ensure that stage fright isn’t going to add noise to the signal. DO NOT ASSUME THAT EVERYONE KNOWS YOUR SHIBBOLETH.

And a bonus, even more modest proposal:

• By all means, tell people to prep using whatever language they feel most comfortable in, but also qualify your advice with a caveat: what is most comfortable for you as a professional developer doing professional work may not be the most comfortable for you when doing algorithm questions. Jumping around in arrays with for loops is a breeze in C/C++/Java. It’s very painful in Ruby where the kind of idioms that are most suitable for algorithm questions are often considered anti-patterns.

What are your thoughts about algorithm questions during technical interviews? I’d love to hear from you in the comments below!