Data structures and algorithms I actually used while working at tech companies

If your question requires having previously memorized or being able to come up with some tricky algorithm on the fly in 45 minutes and code a solution using it, your question is probably bad.

I get why they ask them - they're easy to ask, they're easy to score, and when your question inevitably gets burned because someone posted it all over the internet in their blog post titled "How I got a job at Google!!" and then bumped way up the list on hackerrankcode-whatever I forget the websites... it's easier to come up with a new one, because you just pick a new esoteric algorithm and ask that.

And honestly, coming up with interview questions can take awhile. When you have 5 or 6 very calibrated questions and all of them get burned and banned in a one quarter span, you now have to spend the better part of a whole workweek, plus dozens of more interviews coming up with new questions and recalibrating.

But, I just refuse to ask those types of questions anymore. They really don't give useful signal. The only three bits of signal you get are "does the candidate already know this algorithm (or are they a supergenius who just figured it out under time pressure)? can they communicate it to another engineer? can they write code?"

Importantly if the answer to the first question is no, then you get zero signal on the other two parts. That basically means as an interviewer you just failed your job.

It seems to control decently well for people who have practiced for interviews, because they do the usual dance of asking some clarification questions, mocking the functions, and narrating their code, but many of them hit a wall five minutes in. It's not because their algorithm doesn't work. They're using the right algorithm. The problem is that they haven't thought through "ok what do you do with the data now that you've traversed the tree?" In my experience, for my job, that's usually the actual hard question. For example, if you're checking a JWT, are you validating it in a way that is hard to subvert? Are you taking any time to think about pathological data inputs?

The counterpoint would be "what about a candidate who has solid coding skills but stumbles on the problem space because they're unfamiliar with it?" In my sample size of approximately n=10 since I started interviewing candidates this way (admittedly a small sample, but it's the sample I have), I have yet to see someone who writes code well who neglects thinking through the characteristics of the data up front. That said, it's a real issue. Data is usually contextual, so you're at an advantage if you have experience in the corresponding problem domain, which is not something I'm measuring for in the coding exercise. While I try to pick topics that should be universal, I inevitably get surprised, so I offer three different topics based on the candidate's resume, and I give the candidate a choice.

The biggest weakness I've seen in my interview process (within the scope of what you can do with only one hour) is that it doesn't control for nervousness or people who just don't operate well under time pressure. Unfortunately that's an unavoidable consequence of the mandated form factor, so I have to try my best to help relax the candidate and then rely on my gut for how much nervousness or pressure affected the interviewee.