A coding round is a 45-minute performance with a rubric, and the rubric scores more than whether the code works. This chapter shows what interviewers write down, how each company runs the round, a minute-by-minute method with the exact words to say, what to do when you are stuck, and a full annotated mock session. If you run interviews yourself, the rubric will look familiar; the work here is building the candidate-side habits until they hold up under a clock.
What the interviewer scores
Every large company uses some version of the same four signals. Names differ (Meta says problem solving, coding, verification, communication; Google's guides talk about algorithmic problem solving, code implementation, and communication and clarification), but the content is the same. The interviewer fills in a form after the round with evidence for each signal and an overall recommendation on a scale such as strong no hire / no hire / lean no hire / lean hire / hire / strong hire. A hiring committee or debrief then reads that evidence, not your code.
| Signal | What they look for | Evidence they write down |
|---|---|---|
| Problem solving | You understand the problem, find a correct approach, reach the optimal complexity, and justify it. | "Asked about input size, proposed O(n²), then found the monotonic two-pointer argument on their own." |
| Coding fluency | Correct, idiomatic, readable code written at a steady pace without the interviewer's help. | "Clean Python, good names, one helper, no syntax fumbling, finished with 12 minutes left." |
| Verification | You test your own code before being asked, find your own bugs, and pick meaningful edge cases. | "Traced the example by hand, caught an off-by-one in the shrink loop themselves." |
| Communication | You think out loud, state trade-offs, take hints, and the interviewer never wonders what you are doing. | "Explained why the window can only move right before coding. Took the hint about duplicates immediately." |
Strong hire vs lean hire at Senior
At Senior (L5, E5, SDE III) a correct optimal solution is the floor, not the ceiling. The difference between "hire" and "lean hire" is usually how much the interviewer had to do.
| Signal | Strong hire sounds like | Lean hire sounds like |
|---|---|---|
| Problem solving | "n is up to 10^5, so I need O(n log n) or better. Brute force is O(n²); the waste is that I rescan the same events for every start, and the left edge never needs to move back, so two pointers give O(n)." | Gets to the optimal approach after a hint, or jumps to it without being able to say why it is correct. |
| Coding | Writes it once, top to bottom, with names that explain themselves, and the code runs as written. | Code works after two or three corrections; variable names like d, tmp2; duplicated logic. |
| Verification | "Let me trace the example." Finds a bug, fixes it, then lists edge cases and walks two of them. | Says "I think this works" and waits; tests only after the interviewer asks; misses the empty input. |
| Communication | Narrates decisions, not keystrokes. Checks in at each milestone: "Does that approach sound reasonable before I code it?" | Long silences, or a running commentary of every keystroke with no reasoning. |
| Follow-ups | Handles the follow-up (stream, unsorted input, return the window) in a minute or two with a clear statement of what changes. | Runs out of time before the follow-up, or needs to restart the solution to handle it. |
A solved problem with weak verification and communication often comes back as "lean hire". At Senior that is frequently a down-level or a no. An almost-solved problem with excellent reasoning, testing and communication can still come back as "hire". You cannot control whether you have seen the problem; you can control the other three signals every time.
Formats you will meet
Formats change every year, so confirm with your recruiter which editor you will use, whether code runs, and how many problems to expect. The table reflects public guides read in October 2026 (see Sources) and is a starting point, not a promise.
| Round | Shape | What it means for you |
|---|---|---|
| Phone / video screen | 45 minutes. About 5 minutes of introductions and 5 of your questions leave 35 for coding. One or two problems in a shared editor, usually with syntax highlighting but no autocomplete, and often no way to run code. | You must type correct Python from memory (no IDE hints for heapq.heappush) and test by hand. |
| Onsite coding | 45–60 minutes each, usually two coding rounds at Senior. Same editor or a whiteboard/laptop on site. Harder problems than the screen, more follow-ups. | Pace is less frantic, but the bar on code quality and edge cases is higher. |
| Meta | Two problems in a 45-minute round, roughly 35–40 minutes of coding. Medium to hard, CoderPad without execution. Grades problem solving, code quality, verification, communication. Meta also runs an AI-enabled coding round (60 minutes, multi-file codebase, AI chat available) that replaces one onsite coding round for many candidates. | About 17 minutes per problem. Speed of recognition matters more than anywhere else. Practise pairs of mediums against a 35-minute timer. |
| 45 minutes, usually one problem that is medium-hard, then follow-ups that change the constraints (now the input is a stream, now it does not fit in memory). Sometimes a second, shorter problem if you finish early. Code is not run. | Depth over speed: expect to discuss alternatives and prove correctness. Leave 10 minutes for the follow-up. | |
| Amazon | Each loop round is 55 minutes. Interviewers typically ask two or three Leadership Principle questions in their round, then a coding problem. Code is judged on being correct, readable, and handling bad input. | Your coding window can be only 25–30 minutes. Have stories ready and keep them to 3–4 minutes each. |
| Online assessment | Automated, timed, code runs against hidden tests. Amazon's SDE II OA gives 90 minutes for two coding questions; SDE III (L6) candidates usually skip the OA and go straight to a live coding phone screen. CodeSignal's General Coding Framework is 4 questions in 70 minutes. HackerRank tests are usually 60–90 minutes with 2–3 problems. | No one watches, so only correctness and speed count. Read every constraint, pass the easy ones first, and submit partial solutions: hidden tests usually give partial credit. |
In a no-execution editor, candidates who rely on "run it and see" lose the verification signal. Practise on a plain text editor with autocomplete off for the last three weeks before the loop. You will learn exactly which standard-library signatures you do not remember.
The six-step method
The method exists so that you never have to decide what to do next under stress. Each step produces something the interviewer can score. The steps are: clarify, examples, brute force, optimise, code, test, and you close every round by stating the final complexity.
Minute-by-minute budget for a 45-minute round
- 0–3 min
- Introductions. One sentence about yourself; save the stories for behavioural rounds.
- 3–7 min
- 1 · Clarify. Input types and sizes, sortedness, duplicates, negatives, empty input, what to return when there is no answer. Write the agreed constraints as a comment at the top of the editor.
- 7–9 min
- 2 · Examples. Work the given example by hand, then make one of your own that hits an edge case. Confirm the expected output with the interviewer.
- 9–12 min
- 3 · Brute force. Describe the obvious solution in two sentences with its time and space. Do not code it unless the interviewer asks or the optimal is out of reach.
- 12–18 min
- 4 · Optimise. Use the input size to name the target complexity. Find the wasted work in the brute force. Agree the approach before writing code.
- 18–32 min
- 5 · Code. Write it in one pass, top to bottom, narrating decisions. Helpers for anything fiddly.
- 32–39 min
- 6 · Test. Trace one small example line by line, then run the edge-case list. Fix bugs out loud.
- 39–41 min
- Close. Final time and space, what you would change for production, follow-up if offered.
- 41–45 min
- Your questions for the interviewer.
For a Meta-style round with two problems, halve everything: about 2 minutes to clarify, 3 to reach the approach, 8 to code, 3 to test. That only works if problem recognition takes seconds, which is why Meta preparation is mostly volume on mediums.
The budget fails most often in step 4. If you are past minute 20 without an approach the interviewer agreed to, code the brute force cleanly. A working O(n²) with good tests beats an unfinished O(n). Say that you are doing it on purpose and which part you would optimise next.
Step 1 · Clarify
Clarifying is not a ritual. Each question should change what you build. The four that matter most:
- Size. "How large can n get?" It decides the target complexity. Rule of thumb for about a second of running time: n up to 20 allows exponential work, up to 5,000 allows O(n²), up to a million needs O(n log n), and beyond that O(n) or better.
- Shape. Sorted? Duplicates? Negative numbers? Unicode or ASCII? Can the graph have cycles? Is the tree balanced?
- Empty and impossible. What to return for empty input, or when no answer exists:
-1,None, raise? - Output form. Value, index, or the whole thing? Any valid answer or a specific one? Order of the output?
"Before I start: how big can the input get, can it be empty, and are values guaranteed sorted? If there is no valid answer, should I return minus one?"
Step 2 · Examples
Work the interviewer's example by hand to prove you read it the same way. Then build a small one of your own that hits the case most likely to break a naive solution: duplicates, all equal, a single element, the answer at the very end.
"Let me make sure I read it right: for this input the answer is 6, from the window starting at index 2. And if every event is the same trader with k equal to 2, there is no answer, so minus one. Correct?"
Step 3 · Brute force with complexity
Say the obvious solution so the interviewer knows you have a correct baseline, then move on. Name its cost and the waste in it, because the waste is where the optimisation is.
"The direct approach tries every start index and scans right until it has k distinct traders. That is O(n²) time and O(k) extra space. With n up to 10^5 that is 10^10 steps, too slow. The waste is that each start rescans events the previous start already looked at."
Step 4 · Optimise
Use the input limits to name the target before searching for it. With n ≤ 10^5 in Python you need O(n log n) or better; with n ≤ 500, O(n³) is fine and the "optimal" algorithm may be overkill. Then ask three questions in order:
- What work does the brute force repeat? (Rescanning a window, recomputing a sum, revisiting a state.)
- Which structure removes the repetition? (A running count, a prefix sum, a hash map, a heap, a sorted order, memoisation.)
- What property makes it correct? (A pointer that never moves back, a monotonic stack, an optimal substructure.)
"If a window from left to right covers k traders, every window that extends it to the right does too. So for each right end, I want the largest left that still works, and that left never moves backward as right grows. Two pointers with a count map gives O(n). Shall I code that?"
Always end step 4 with a question. "Shall I code that?" gives the interviewer a cheap moment to steer you before you spend 14 minutes on the wrong idea. Interviewers will often tell you outright if they want a different approach.
Step 5 · Code
Write top to bottom in one pass. Narrate the decisions, not the syntax: "I'll keep a dict of counts so removal is O(1)" is useful; "now I am typing a for loop" is noise. If a piece is fiddly (bounds checks, neighbour generation, parsing) put it in a helper with a clear name and come back to it. If you forget an API, say what it does and move on: "I'll assume heappush takes the heap then the item; I can confirm after."
"I'll write the main loop first and treat the neighbour logic as a helper, so the core reads cleanly. I'll fill the helper in after."
Step 6 · Test, then state complexity
Testing has two halves: a line-by-line trace of one small example (finds logic bugs), then an edge-case sweep (finds boundary bugs). Both are shown in full in Testing technique. Finish with the complexity, justified against the code you wrote, not the idea you had.
"Each event enters the window once when right passes it and leaves at most once when left passes it, so the inner while loop runs n times in total across the whole run. That's O(n) time, and O(d) space where d is the number of distinct traders."