By Dan Kim —

The wild west of technical interviews for engineering managers

During my job hunt, I've gone through four entirely different types of technical interviews/screens for engineering manager roles. They all vary wildly in format and each has their own tradeoffs.

  1. The Take-Home Coding Project. This is where you are given a project to build a small app. You're usually given some basic boundaries – a week or so to do it, a recommendation on how much time to spend on it (4-8 hours), and directions on what they're looking for – and then you build and submit it. This is my favorite version of this interview because you can work at your own pace, break up the work as your schedule allows, nobody is watching you live code, you're expected to follow written instructions, and someone reviews it asynchronously and gives feedback. This is the closest thing to a real world work situation.
  2. The Time-Bound Coding Project. This is similar to the take home project, except the company presents you the project in a call and gives you a chance to ask any clarifying questions. You're then given a time window (2-4 hours) to build it, and then jump back on a call again to review it and talk through your code. This type of interview is pretty reasonable overall since you aren't being watched the whole time, though the time pressure element is entirely unrealistic. I do understand why they do this – they don't want people to go off and put 40 hours into an app and say they did it in 2 – but it does put a giant ticking clock over your head the entire time, and many people don't do great with arbitrary time pressure.
  3. The "Present One of Your Projects" Interview. In this interview, you come prepared to discuss a project you led, and then the interviewers will poke and prod on a variety of details about that project to get a sense of your responsibilities and ability to execute. I like this kind of interview because you're talking about something real you did, and it's more like a conversation with the interviewers. The problem is you have no idea going into it whether the project you choose will give them the signal they're looking for. You might be intensely proud of a project you worked on that was challenging and complex, but it might be so different from what the company is trying to get signal on, there's a halfway decent chance it may not land. This interview also entirely depends on the interviewer to ask the "right" questions, which is a pretty big variable.
  4. The Systems Design Interview. This is the one where the interviewer will give you a very broad, generic system to design, and you have to walk through how you would technically design it, top to bottom. The idea is to check how you think through a system, how you break down a large problem, see what kinds of questions you ask, see what you prioritize, etc. That all sounds good on paper, but honestly this one is pretty hit or miss. While the other types of technical interview have some element of concreteness to them, this is a largely academic exercise. Because the interview question has to be generic (so they can score against a standardized rubric), it's very likely the role may not be connected to the interview question at all. For example, once I was prompted "tell me how you would design a login system" for a role where I would literally never, ever have to design a login system.

So yeah, some closing thoughts:

  • Technical interviews vary wildly in style, and I would guess no two companies do it the same. They all have their own flavor of these (or others), so preparing is pretty tough and you kinda just have to be ready for anything.
  • Thankfully I've never had to do a LeetCode interview (I don't even apply to roles that require that) nor a live coding/pairing interview (I think these are OK, but I know I wouldn't do well).
  • Non-coding interviews rely heavily on the interviewer to drive properly. If you get a poor interviewer (which can and does happen), you're already at a disadvantage.
  • I honestly thought I would prefer the storytelling/more abstract interviews (the last two), but I'm starting to think that maybe the coding projects are more objective and ultimately less reliant on the interviewer. Yes code is still subjective and you're still relying on engineers who are assessing your work, but there is a concrete, top-of-mind project that serves as a shared starting point for a conversation that doesn't exist with the other types of interviews.