Most lists of senior engineer interview questions are trivia: reverse a linked list, explain closures, describe the difference between a process and a thread. Trivia measures preparation. A candidate who studied last weekend will beat someone who has kept a payments system running for four years and forgot the textbook definition. Neither result tells you who can be trusted with a production system.
Write down what a good answer looks like before you talk to anyone, then split the questions across three interviews. In live coding, grade how the candidate works more than whether the tests pass. In systems design, ask what each decision cost. In the communication interview, have them write a status update. The red flags that sink senior candidates are about judgment and ownership, not trivia.
These are the questions I use when I vet engineers before placing them with client teams. They follow the three interviews in how I vet senior engineers, which covers the process itself, the paid probation and the evidence behind structured interviews. Here, for each question, I’ve written what I’m listening for and the red flags that sink a candidate even when the code works. Take them, change them, but read the next section before you do.
Write the rubric before the interview
A question is half of the tool. The other half is deciding ahead of time what a good answer contains. Google’s re:Work guide to structured interviewing recommends documenting, for every question, examples of a poor, borderline, solid and outstanding answer, and having every interviewer score on that same scale.
In practice, next to each question below I keep a few lines: what a senior answer mentions, what a mid-level answer tends to miss, and what disqualifies. I fill in my scores before I talk about a candidate with anyone. Once someone in the room says “I really liked her,” everybody’s notes start to agree.
What should you ask in a senior live-coding interview?
Ninety minutes, paired, on a problem shaped like the actual job. Passing tests is expected, so the grade comes from how they got there. These four prompts are where I look, with what a strong answer and a red flag sound like:
| Prompt | Strong candidate | Red flag |
|---|---|---|
| “This function fails intermittently in production. How would you find out why?” | Forms a hypothesis, picks the cheapest way to test it, narrows down | Edits code at random until something passes |
| “It works. Now the input is null, the API times out, the list is empty.” | Already thought about at least one of these | Treats each as a surprise and patches them one by one |
| “Talk me through your plan before you type.” | Restates the problem and names assumptions | Starts typing right away and explains afterward |
| You quietly break something small in their code | Reads the error and finds it fast | Can’t debug code they wrote ten minutes earlier |
The last row is my favorite. Someone who memorized a pattern can reproduce it. Understanding shows up when it breaks and they have to fix it.
Pay attention to long silences too. Some people think quietly, and a minute of that is fine. But a senior engineer on a remote team spends a lot of time explaining reasoning to people who can’t see their screen. When a candidate can’t narrate while they code, it’s often because they’re guessing.
On AI coding assistants: pick your rule before the interview and put it in the rubric. If your team uses them every day, banning them measures something the person won’t be doing at work. If you allow them, grade whether the candidate reads and questions what the tool produced. Accepting a generated function without checking it is a red flag by itself.
Which systems design questions show real experience?
Sixty minutes on architecture. The quickest way to separate someone who has operated systems from someone who has read a lot about them is to stop asking for the design and start asking about consequences.
- “Design X. Now, where does it fail first at ten times the load, and how would you know before your users do?”
- “You added a queue here. What did it cost you? What got harder?”
- “This has been in production for two years. What’s the operational pain the diagram doesn’t show?”
- “A junior on your team proposes the version without the cache. Are they wrong?”
The fourth question catches a lot of people. A strong answer is usually “maybe not,” followed by the conditions under which the cache earns its keep. A candidate who defends every component they drew, without being able to say what each one costs, tends to add complexity by reflex.
What fails here:
- Only the happy path. No failure mode comes up unless you drag it out.
- Microservices, a message bus or sharding appear with no trade-off named.
- They can tell you what a past system did but not why it was built that way.
- Every answer sounds like a conference talk, and none sounds like something they got paged for at 3 a.m.
Communication and ownership: where strong coders fall short
Forty-five minutes, no code. In my experience this is where technically strong candidates most often fall out, which is why it gets its own interview instead of a few questions squeezed in at the end of a technical one. It matters even more for engineers joining a US team remotely, where most of the day is written.
“Tell me about something you shipped and later regretted. What did you do about it?” Listen to who the subject of the sentences is. “I” when things went wrong is a good sign. “They,” every single time, is not.
“Your lead has settled on an approach you think is wrong. What do you say to them?” You want a specific, polite disagreement with a reason and an alternative. Folding immediately and getting defensive both fail.
“Write a two-paragraph status update for a project that’s two weeks late.” Give them ten minutes and a shared doc. The delay belongs in the first sentence, with a cause and a next step. If it’s buried under context, you’ll be reading updates like that every week.
“What code running in production right now do you wish you’d written differently?” Everyone with real experience has an answer. “Nothing comes to mind” is a strange thing to hear from a senior.
Red flags for this stage: blaming former teams for every failure, needing a fully specified ticket before starting, and written English that works in chat but falls apart in a design doc. For a remote role, that last one matters more than accent.
The eight red flags I watch across all three
These cut across every stage. I treat each one as serious on its own, however clean the code was.
- Starts coding before understanding the problem.
- Only describes the happy path.
- Adds complexity without naming a trade-off.
- Explains what they built, never why.
- Blames, never owns.
- Can’t disagree without caving or getting defensive.
- Writing that doesn’t hold up once the topic gets complicated.
- Freezes on ambiguity instead of asking questions that narrow it down.
Start with three questions
You don’t need all of the above to improve a hiring loop. Pick three questions, one per stage. For each one, write two or three lines on what a strong answer includes and what fails. Ask every candidate for the role those same three, and have each interviewer score on their own before the debrief. That alone will make your loop more consistent than most.
The questions are the easy part. Running them the same way on every candidate, with interviewers senior enough to read the answers, is where most teams slip. If you’d rather not run this loop for every hire, tell me about the role and I’ll send you engineers who have already been through it.