Module 1 · Stories and the Interview Loop · Lesson 1 of 11
How Senior Interview Loops Work: What Each Round Measures and How You Are Scored
Learning outcome
You can name the usual rounds in a senior software engineering loop (coding, system design, code review or debugging, behavioral, and sometimes a hiring-manager or bar-raiser conversation), say what signal each round is designed to collect, and prepare for the round you are in rather than the one you wish you were in.
Intuition
Every round is a sensor. The interviewer has a short list of signals to collect and a written rubric to fill in afterwards. Your job is not to "perform well" in general; it is to make the signals that round measures easy to see and easy to write down.
flowchart LR
C["coding: problem solving, code quality"] --> D["hiring committee / debrief"]
SD["system design: scope, trade-offs, depth"] --> D
CR["code review: judgment, communication"] --> D
B["behavioral: ownership, conflict, leadership, impact"] --> D
D --> L["decision + level"]Deep dive
- The usual rounds for a senior .NET backend role:
- Coding: a problem in C#. They watch how you clarify the problem, test, and explain complexity, as well as whether it works.
- System design: an open problem (a URL shortener, a notification system). They score how you scope, estimate, choose components, and defend trade-offs.
- Code review or debugging: you read someone else's code and say what is wrong and why it matters. This is common for senior roles because it mirrors daily work.
- Behavioral: past situations told as stories. It covers ownership, conflict, leadership, failure and impact.
- Hiring manager or bar-raiser: a mix of the above, with a focus on level and team fit.
- How decisions are made: interviewers write structured feedback against criteria, and a debrief or committee decides. Most companies decide the level from the same evidence. That is why the same loop can lead to "hire at senior" or "hire one level below" (Lesson 9).
- Scope is the senior signal. At senior level and above, interviewers listen for the size of the problems you owned, the people you influenced, and the decisions you made under ambiguity, more than for the technologies you used.
- Ask the recruiter for the format: the round names, their length, whether design is whiteboard or doc-based, whether the code review is live, and whether behavioral questions follow a published framework, such as Amazon's Leadership Principles. That is legitimate preparation, not gaming the process.
- Prepare assets, not answers:
- a story bank (Lessons 2-5);
- a design method you can run in 45 minutes (Lessons 6-7);
- a review checklist (Lesson 8);
- a clear statement of your scope (Lesson 9).
Worked example
Recruiter: "The onsite has four rounds: coding (C#), system design, a code review exercise, and a behavioral round with the hiring manager." Preparation plan from that one sentence: coding -> practise talking while coding; test cases before running system design -> one method: requirements, estimates, API, design, deep dive, trade-offs code review -> severity-ordered comments with a reason and a fix behavioral (HM) -> 8-10 stories covering ownership, conflict, failure, leadership, ambiguity all rounds -> one sentence on your scope: "I lead the checkout area for 3 teams"
Failure modes
- Treating behavioral as a "soft" round that needs no preparation; at senior level it often decides the level.
- Using the system design round to show off technologies instead of reasoning about requirements.
- Rushing the code review to find every nit, instead of the issues that matter.
- Answering what you prepared instead of the question asked.
- Asking no questions about the format, and discovering on the day that "design" means a written doc.
Interview angle
"Walk me through how you approach an interview loop like ours." This is rarely asked directly, but your behaviour answers it. In each round, restate what is being asked, make your reasoning visible, and close with a short summary the interviewer can copy into the feedback form.
Practice questions
- What does a code review round measure that a coding round does not?
Answer: Judgment about someone else's code: what matters most, how you phrase feedback, and whether you can explain the impact.
- Why does the behavioral round often decide the level?
Answer: Level is about scope and influence, and the behavioral stories are the main evidence of both.
- Name three questions to ask a recruiter about the loop.
Answer: Any three of: the round names and their length, the design format (whiteboard or document), whether code review is live, the language for coding, and whether a framework such as leadership principles is used.
Revision checklist
- Know each round's signal before you walk in.
- Assets: story bank, design method, review checklist, scope sentence.
- Ask the recruiter for the format.
- End every answer with a sentence the interviewer can write down.
Related on TechInterviewNotes
- Lesson: Interview blueprint
- Lesson: Behavioral and leadership questions
- Course: System Design for .NET Developers
Analogy
A medical check-up
Each specialist checks one system and writes it down; the doctor reads all the notes and decides. You cannot impress the eye doctor with your blood pressure. Give each round the measurement it is there to take.
Quick reference
Round → signal
- Coding: clarify, test, complexity, clean C#.
- System design: scope, numbers, trade-offs, depth.
- Code review: priorities, reasons, tone.
- Behavioral: ownership, conflict, failure, leadership, scope.