The Senior Engineer's Guide to Coding Interviews

I bombed a coding interview about 4 years into my career. Not because I couldn't code; I'd shipped plenty of production software by that point, and I knew the language cold. I just froze on a problem I'd have solved in 5 minutes at my own desk, and the interviewer sat there watching me flail while I watched myself do the exact same thing, and neither of us really enjoyed the half hour it took.

That whole experience taught me something years of grinding leetcode never did. Senior interviews are a genuinely different game, and if you prepare for one the way a junior would, you tend to get rejected the way a junior does, however strong an engineer you actually happen to be.

So this is more or less the guide I wish someone had handed me back then. It focuses on the approach itself rather than a pile of problems to memorize.

What interviewers are really checking at the senior level

When you ask a junior "can you solve this?", that's basically the whole test right there. When you ask a senior the exact same question, something else is going on underneath it entirely; what they're really asking is whether you can think, and whether they could hand you something vague and half-specified and still trust you to come back with a reasonable answer.

The problem on the whiteboard barely matters on its own; it's mostly a prop for the real evaluation that's happening around it.

What they're really doing the whole time is watching how you work. They notice whether you clarify things before you start typing or whether you assume and charge in. They notice whether you go quiet and freeze the moment you hit a wall, or whether you keep thinking out loud. And they're quietly checking whether you can actually weigh tradeoffs or only really know the one approach, and whether the code you leave behind is something a teammate could still read 6 months later without hating you for it.

I've sat on both sides of that table. As the interviewer, I've honestly passed people who never even finished the problem, just because their reasoning was clean and they were upfront about the gaps; and I've failed people who reached the optimal answer and then couldn't tell me why it actually worked, or what they'd change if the constraints shifted a little. That second group concerned me more, because a correct answer that the candidate can't really explain tells you very little about how they'd actually work day to day.

The framework I actually use

I run more or less the same loop on every single problem. It's deliberately boring, and that's the entire point; a boring, repeatable process is the thing that keeps you actually moving forward when you're under pressure and your mind wants to go blank on you.

1. Restate and clarify. Say the problem back to them in your own words first, and then ask the questions that actually change the answer: how big the input really is, whether it can be empty, whether there are duplicates in it, whether it's already sorted, and whether you're supposed to be optimizing for time or for space. None of that is stalling. A good clarifying question is one of the clearest early signals of seniority there is.

2. Talk through the naive approach first. Say the brute-force version out loud, even when it's obviously way too slow. Something like: "the straightforward way here is O(n²), just nested loops comparing every pair; let me get that working first and then optimize." This does two things at once. It gets a working baseline up on the board, and it shows the interviewer that you understand exactly where you're starting from.

3. Find the bottleneck, then optimize it. Don't jump straight to the clever trick. Point at the expensive part first. "the nested loop is the problem here; if I had O(1) lookups instead of scanning every time, this drops to O(n), which basically points me at a hash map." Optimization should look like a decision you actually made. It shouldn't read as a trick you happened to recall from memory.

4. Write it cleanly. Use real names. left and right, not i and j, when they actually carry meaning. Add a small helper function when it genuinely improves readability. The interviewer is quietly picturing you as a teammate the whole time you write, so give them an actual reason to want that.

5. Test it yourself. Walk through a normal case first, then an edge case, out loud, before anyone even asks you to. Catching your own bug is worth a lot more than never having written one in the first place.

Here's the loop applied to the most common opener, two-sum:

function twoSum(nums: number[], target: number): [number, number] | null {
  // seen maps a value we've passed -> the index it was at.
  // One pass, O(1) lookups, so O(n) total instead of the O(n²) double loop.
  const seen = new Map<number, number>();

  for (let i = 0; i < nums.length; i++) {
    const need = target - nums[i];
    if (seen.has(need)) return [seen.get(need)!, i];
    seen.set(nums[i], i);
  }

  return null; // no pair sums to target
}

Nothing there is actually fancy. What makes it a senior answer is really everything around it; the "I'll start with the double loop and then trade space for time" narration, the comment that explains why rather than what, and the null case that's handled instead of just quietly ignored.

The mistakes that sink senior candidates

The first one is going silent, and it's honestly the most damaging thing on this whole list. If you're thinking, then think out loud; an interviewer just can't give you partial credit for reasoning they can't actually hear, and they can't redirect you when they have no idea where you currently are.

The second is optimizing too early. Jumping straight to the clever solution and getting it slightly wrong tends to read worse than just building up methodically. I've watched candidates try to reproduce the optimal answer from memory, get exactly one boundary condition wrong, and then completely struggle to debug it, mostly because they'd memorized the answer without ever really understanding it.

The third is treating clarifying questions as optional. At this level the ambiguity genuinely is part of the test, and often the real work is just noticing that the problem is underspecified and asking the one question that pins it down.

And the last one is ignoring the interviewer's hints. When they ask something like "is there a way to avoid sorting here?", they're effectively handing you the answer, so just take it; defending your own approach while the interviewer is clearly steering you elsewhere is a real red flag about how you'd handle code review later.

How to actually prepare (without wasting three months)

I honestly don't believe in grinding 500 problems. I've never once really seen it correlate with stronger offers, and it just burns people out. A few other things tend to work a lot better than that.

Learn the patterns, not the individual problems. There are really only around 15 that matter: two pointers, sliding window, hashing, BFS/DFS, binary search, heaps, dynamic programming, and a handful of others. Once you learn to recognize which pattern a question is really asking for, you can derive the solution on the spot instead of trying to recall it from memory, and building that recognition is basically what the rest of this series is going to be about.

Do fewer problems, but actually do them properly. 40 problems you can explain line by line will take you a lot further than 200 you only half-remember. After each one, close the editor and try to re-explain the whole approach out loud; if you can't do that, then you didn't really learn it.

Practice talking while you're coding. This one is high-impact and almost always skipped. Record yourself solving a problem out loud; it feels genuinely awkward, but it exposes those long silences you fall into whenever you actually stop to think, which are exactly the thing that hurts you in a real interview.

Simulate the pressure too. Solving a problem calmly on your own is honestly a totally different skill from solving it while somebody else watches you do it. Do mock interviews, and just get used to being a little uncomfortable.

What I tell people the night before

Sleep. A rested brain that actually knows 5 patterns will easily outperform an exhausted one that crammed 20 the night before.

And try to reframe the whole situation while you're at it. You're not being interrogated here. You're pair-programming with someone who just wants to see how you actually work. The best interviews I've ever had genuinely felt like two engineers just solving a problem together, and that's the tone to aim for rather than some kind of performance.

You honestly don't need to be perfect. You need to be clear, upfront about the things you don't know, and steady when the problem gets hard. That's really what senior looks like from the other side of the table.

Next up in this series, we get quite a bit more concrete with the arrays and hashing patterns, which show up in more interviews than just about anything else.