91 — The interview protocol

The most important file here. You already know algorithms. What sinks strong candidates is arriving without a protocol: hearing the problem, going quiet for four minutes, and starting to type. Learn this until it is automatic, so your attention is free for the problem.

Prereqs: none · Reading: 8 min · Cards: 8

The map

Forty-five minutes, seven steps, and the ordering is not arbitrary: each step exists to prevent a specific failure. Restating catches a misunderstanding while it is still cheap. Clarifying decides which complexity you need to target. A worked example validates comprehension and frequently produces the solution. Stating a brute force guarantees you have something. Optimising before coding means everything you type is executing a plan rather than searching for one. Narrating while coding is what gets communication scored at all. And testing without being asked is what separates finished from submitted.

Underneath all of it is one idea from the email: "we're interested in how you approach the problem, not just the final answer." The right solution delivered in silence scores worse than a suboptimal one conducted well — not out of generosity, but because they are hiring someone who will work with other people on problems that have no ready answer.

What decides your score here

Not coding before you have a plan. The single biggest failure, and the easiest to avoid. Say the approach and its complexity, ask "does that sound reasonable?", and only then type.

Not going silent. If you think quietly for ninety seconds, the interviewer can neither assess you nor help you. Twenty announced seconds are normal; silence is a low communication score even when your solution is right.

Taking the hint. Interviewers do not drop hints idly. An ignored hint is read as an inability to collaborate, and it costs on Googleyness as well as on the technical axis.

The seven steps

Restate the problem, in your own words, in a minute or two. A misunderstanding discovered at minute thirty is a lost interview; discovered at minute two, it costs nothing.

Ask clarifying questions — two or three, not seven. Ask the ones that genuinely change your solution: the expected input size, whether the input can be empty, whether it is sorted or whether you may sort it, whether duplicates are possible, whether you may modify the input in place. Asking all seven mechanically sounds like a memorised checklist, because it is one.

Work a concrete example by hand, out loud. This is the step most people skip and the one that pays best: it validates your understanding, and the solution frequently falls out of it.

State the brute force and its complexity — and do not implement it. This proves you have a guaranteed solution in your pocket and establishes the baseline your optimisation will be judged against. No interviewer fails a candidate who has a brute force plus a path to improvement.

Optimise, still without coding. Ask yourself out loud: what am I recomputing, would sorting help, do I need random access or just the extreme, can I trade memory for time, is there structure I am not using? Then close the step by announcing the plan and its complexity, ending with "does that sound reasonable to you?" That question is free, and if the interviewer disagrees with the approach you find out now rather than at minute forty.

Code, narrating the intent rather than the syntax. Not "now I open a for loop" but "now I'll pop every meeting that has already ended". Use real names — end_times, not h — because at senior level that is assessed. Write the edge case as you reach it rather than promising to add it later. And if you stall on syntax, move past it: "I'll assume a helper that does X and come back to it."

Test and analyse, without waiting to be asked. Run your own example line by line with real values, saying them aloud. Then name the edge cases as you check them: empty, one element, all equal, reverse sorted. State the final complexity and where each term comes from. And offer the improvement you did not make — "if the input were already sorted this drops to linear" — which ends on judgement rather than on stopping.

If you find your own bug while testing, that is good, and better than having no bug: you have just demonstrated that you review your own work. Fix it calmly and do not apologise.

When you get stuck

It will happen, and what is assessed is not the getting stuck but how you do it.

Narrate the dead end instead of going quiet: "I'm trying to use a hash map here but I don't have a good key — let me think about what actually identifies a group." That sentence keeps the communication score alive and often prompts a useful hint.

Go back to a smaller concrete example rather than guessing at code. If you need thinking time, ask for it: "let me think about this for a moment", then resume out loud.

And when a hint arrives, take it visibly: "that's helpful — so if I don't need to preserve order, I could sort first". Naming what changed shows you understood rather than merely complied.

The English you should not have to improvise

Under pressure, in a second language, you will not compose phrasing. Have these ready.

Opening: "Let me make sure I understand the problem correctly." · "Before I start, I have a couple of questions about the input." · "Let me work through a small example by hand."

Thinking: "My first thought is a brute force — let me describe it and then improve on it." · "The bottleneck is that I'm recomputing X every iteration." · "There's a trade-off: O(n) time if I'm willing to use O(n) extra space."

Stuck: "I'm going to step back and look at a simpler version of this." · "I don't have the optimal approach yet, but here's what I know so far." · "Could you tell me if I'm heading in a useful direction?"

Closing: "Let me trace through my example to verify." · "Let me check the edge cases: empty input, single element, all duplicates." · "Time is O(n log n), dominated by the sort. Space is O(n)."

And admitting uncertainty, which scores rather than costs: "I don't remember the exact constant, but the upper bound is O(n log n)." · "I'd want to look up the exact API, but the idea is…"

Google Drawings

The email warns the interviewer may ask for it, and there is an official guide. Four things from it are worth knowing before the day, because discovering them live wastes minutes.

It opens from inside a Doc — Insert → Drawing → New — using the link that arrives in your time-slot confirmation, not as a standalone file. Share through Meet as a Chrome Tab rather than the whole screen. Text goes inside a shape by double-clicking it. And you cannot write on an arrow: to label one you create a text box and align it alongside, which is the detail that catches everyone.

Two more that reduce anxiety. Pen and paper are explicitly allowed — tell the interviewer at the start and test beforehand that the camera frames it legibly. And the guide says plainly: "Don't worry about having the correct shape to represent your design. Focus on answering the question."

Practise beforehand until you can create a box with text, an arrow, a label beside it, and a duplicate (Ctrl+D) without thinking. Then draw little: the diagram exists so you can think and the interviewer can follow, not as a deliverable.

Logistics

Test Meet on the machine and network you will actually use. Have water on the desk, because a dry mouth in a second language is a real problem. Put the light on your face rather than behind you. Turn off notifications and put the phone away. Keep a sheet of paper with the seven steps within sight — glancing at it is legitimate. And ten minutes before, solve one easy problem to warm up, so the interview is not the first thing your brain does that day.

Say it

Cover the answers. Out loud, in English.

Now do this

This module is rehearsed, not solved.

1. Read the seven steps aloud until you can recite them from memory. Two minutes a day for three days is enough.
2. Solve one easy problem while recording audio, in English, following the protocol exactly. Then listen to the recording. It will sting, and that is the point — it is the only way to hear what the interviewer will hear.
3. Practise Google Drawings for ten minutes: a box with text, an arrow, a label beside it, a duplicate, and sharing a single Chrome tab.

Stop when the seven steps come without effort and the recording contains no silence longer than twenty seconds.