Technical depth without a whiteboard problem

There is a widely held belief that EM interviews go easy on the technical side. They do not go easy; they go sideways. The question is rarely whether you can produce an algorithm under time pressure. It is whether you can still engage credibly with the detail of work you no longer do yourself.

That distinction produces three formats, and they demand different preparation.

Format one: the coding round

Medium difficulty. Data structures, basic graph traversal, reasoning about optimisation trade-offs. No tricks. The signal is not speed — it is whether your process and code quality are still good enough that your review of a pull request would be worth having.

The main risk is dismissiveness. Google's EM loop includes a must-pass coding round, and candidates who treat it as a formality find out during the loop. Two weeks of medium-difficulty practice is enough for most managers who were competent engineers; zero weeks is not.

Format two: code review and debugging

This is the format EM candidates are least prepared for, and the one where Google EM candidates most often struggle. You are handed logic somebody else wrote, usually without IDE support, and asked to find the fault and fix it.

It is a fair test of the job. Reading unfamiliar code and locating a defect is closer to what a manager actually does than writing a fresh function from a blank editor. It is also a distinct skill from writing code, and it decays faster, because as a manager you increasingly read code sympathetically — looking for what the author meant — rather than adversarially.

How to prepare, concretely:

• Read pull requests in a codebase you did not write, and try to predict review comments before reading them.
• Practise saying your reasoning out loud while reading. In this format silence looks like confusion, and the interviewer is scoring your search strategy, not just the find.
• Have a stated approach: understand the intent first, then find where the code and the intent diverge. Candidates who start line-by-line at the top usually run out of time.
• When you spot the bug, do not stop. Say how it would have been caught — a test, a type, an assertion, a review checklist. That answer is the management signal inside the technical exercise.

Format three: system design, with the EM twist

The format is standard. The expectation is not.

WatchExponent · 07:10

Seven minutes for the whole five-step frame, and worth watching even though it is aimed at engineers rather than managers. Watch it for the shape of the process, then read the section below — because the EM version of this interview does not stop where this video does, and the difference is the entire lesson.

How to Answer System Design Interview Questions — Complete Guide Play “How to Answer System Design Interview Questions — Complete Guide” on YouTube

The twist is that interviewers keep pushing. A Google L6 candidate described it exactly:

"For system design, I would not stop at saying which framework or storage I would use. They kept pushing for actual implementation underneath."

The same candidate reported being asked to go past "the usual black-box architecture answers". This is deliberate. A manager who can name a queue, a cache and a sharded datastore, but cannot say what happens when the queue backs up, is a manager who cannot tell whether their team's design review was any good.

So prepare one extra layer under every component you would normally draw:

You do not need to volunteer all of it. You need to have it available, so that the third follow-up finds something there.

"Tell me about a system you designed"

Many companies ask this instead of a "design X" prompt, and the reasoning is sound: past experience evaluates real expertise better than a hypothetical does, because it cannot be prepared from a course.

It is also harder than it looks, because the story has no built-in structure. The version that scores covers five things in order:

1. The constraint that made it non-trivial. Not what the system did — why it was hard. Scale, latency, a migration with no downtime window, a compliance boundary, a deadline.
2. The design, at the level of components and their contracts. Brief. This is the part candidates over-tell.
3. The alternative you rejected, and the reason. This is the highest-scoring sentence in the answer and the one most often missing.
4. What it cost. Where you took on debt knowingly, and what you would have needed to avoid it.
5. What happened. Latency numbers, incident counts, migration duration, what broke in production that you did not anticipate.

The related question — tell me about a time you scaled a system — wants the same shape with the emphasis moved to the third and fifth items. Practitioners recommend talking specifically about incremental scaling, modular upgrades and smooth migrations rather than a heroic rewrite, because those are the things that indicate you have done this on a system with users on it.

Trade-offs and technical debt

How do you handle trade-offs? is asked in nearly every EM loop, and one coach's statement of what they are listening for is unusually direct:

"I expect a thoughtful discussion on why one design was chosen over another, and how to balance 'move fast now' versus 'pay down later'."

Two things follow from that. First, the answer must be a discussion, not a principle — meaning a specific decision with two viable options and a reason. Second, the tech-debt paydown half is not optional. An answer that only defends moving fast is half an answer, and an answer that only defends engineering quality is the other half.

The version that lands has three parts:

• Debt taken deliberately, with a reason and a note. A launch date, a hypothesis that needed testing before it deserved good architecture. Written down, with the condition under which it gets repaid.
• Debt repaid inside normal delivery, not in a separate quarter you have to negotiate for. A standing allocation, or a rule that whoever touches an area cleans it up, or a rewrite that rides along with the feature that needs it.
• The debt you decided to keep. Naming a piece of ugly code that is not worth fixing is a strong signal, because it shows the framework is about return rather than aesthetics.

Prioritisation

How would you prioritise these tasks? usually arrives as a small scenario — four things, not enough people. What is being scored:

"I expect a good EM to have a structured approach to decisions: being data-driven, considering trade-offs, and making structured arguments."

So do not rank the list. State the criteria first — user impact, revenue or cost, risk if deferred, dependency order, team growth — then rank against them, out loud, and say which item you are deliberately dropping and who you would tell. The dropped item is the answer. Anyone can order four tasks; the signal is in being explicit about what does not get done and communicating it rather than quietly letting it slip.

What to carry into the next module

Technical credibility is necessary and not sufficient. The next module is about the part of the job that consumes most of a real manager's week: delivery when it goes wrong, influence across teams you do not control, and the metrics you will be asked to defend in an interview and then live with afterwards.