He had not written production code in four years, which he considered a sign of career progress right up until the recruiter said the words "technical phone screen" and he asked, in a small voice, whether that meant coding. It did. He was applying to manage twenty engineers, and Google wanted to watch him write a graph traversal in a shared document.
This is the single most common surprise in Google engineering manager interview questions: Google still runs a coding round for managers. Not a hard one, and not the deciding factor, but a real one — and managers who have let their fingers go cold get caught by it every hiring season. The rest of the loop is a genuine mix: system design, two or three people-leadership rounds, and a Googleyness round, all feeding a hiring committee that never meets you. I built Greenroom after freezing in an interview I had prepared for, so this guide covers each round and where managers actually lose them.
The Google engineering manager interview process
- Recruiter screen — scope calibration: team size, whether you manage managers, and which product area. Ask which rounds your loop includes; it varies by level.
- Technical phone screen — usually one algorithmic coding problem, often in a shared document with no execution.
- Onsite (virtual) — typically a coding round, a system design round, two people-management rounds, and a Googleyness and leadership round.
- Hiring committee — written feedback reviewed by people who never met you, which is why narrating your reasoning matters in every round including the people ones.
- Team matching — separate from the hiring decision, and frequently the slowest stage for managers because the scope has to match.
Our Google interview preparation guide covers the company-wide process and the engineering manager interview questions guide covers the role-general bank.
Yes, there is a coding round
The bar is lower than for a senior IC, but it is not zero. Expect a single problem in the LeetCode easy-to-medium range: a graph traversal, a hash-map counting problem, string manipulation, a heap question. You will be expected to state complexity and to write code that would compile.
Preparation that works: thirty problems in the comfortable range, written out in a plain text editor without autocomplete, over three or four weeks. You are rebuilding fluency, not learning new techniques. Our DSA coding interview preparation guide covers the list.
The failure mode is not difficulty. It is a manager who has forgotten how to type code while someone watches, gets flustered, and burns twenty minutes on syntax. Rehearse the situation, not just the problems.
System design for managers
The prompts are the standard ones — a feed, a rate limiter, a metrics pipeline, a notification system — and the technical bar is close to the IC bar. What is added:
- Team boundaries. How this system splits across teams, what the interfaces are, and the coordination cost you just created.
- Sequencing. What ships first, what can wait, and what you would cut to hit a date. Managers are expected to talk about time.
- Migration. Moving from the existing system without a big-bang cutover, including how you keep the team delivering during it.
- Operational load. On-call burden, alert volume, and how the design affects the humans who carry the pager.
- Cost. Both infrastructure spend and engineer-months.
Do not delegate the technical parts. "I would let my tech lead choose the database" is a failing answer even though it is often the right thing to say at work. Our system design interview guide covers the vocabulary.
The people management rounds
Two or three rounds, all probing for specifics rather than philosophy. The recurring questions:
- "How do you grow engineers?" Answer with a specific person, what they were missing, what you did, and where they are now.
- "Tell me about a performance problem." The timeline matters — when you noticed, when you said it, what changed. Vagueness here is the most common weak answer.
- "How do you handle a disagreement between two strong engineers?" A real instance, and what you did before you intervened as well as after.
- "How do you decide what your team works on?" Prioritisation under ambiguity, and how you say no upward.
- "Tell me about a time you influenced a decision outside your team." Google is heavily matrixed; influence without authority is a genuine and repeated theme.
- "How do you run your hiring?" Loop design, your bar, calibration, and a hire that did not work out.
- "What do you do when your team disagrees with the direction?" Especially when you also disagree with it.
Answer in STAR, first person singular, with numbers where they exist. Our behavioral STAR answers for senior engineers guide covers the structure at this level.
The Googleyness and leadership round
A scored round covering comfort with ambiguity, collaboration across boundaries, bias to action, and how you behave when you are wrong. For managers it leans towards influence, cross-functional friction, and decisions made with incomplete information.
Have ready: a decision you made without enough data and how you managed the risk, a cross-functional conflict you resolved, a time you changed your position publicly, and something you got wrong that affected your team. Our how do you handle criticism guide covers the honest-self-assessment shape.
Where each prep option actually helps
- LeetCode — thirty problems at a comfortable level, typed without autocomplete. Fluency, not new technique.
- Designing Data-Intensive Applications — still the best design-round preparation, even at manager level.
- The Manager's Path — good vocabulary for scope and levels, though Google's rounds want incidents rather than frameworks.
- Your own last two years — the highest-yield preparation is writing down eight real situations with dates, names and numbers before you rehearse anything.
- ChatGPT — useful for generating follow-ups on stories you have written down. It cannot tell you that your answer never named a single person.
- Greenroom — the spoken layer. Ari, the AI interviewer runs people-management rounds out loud and pushes for the specific instance when you answer with a philosophy. Honest tradeoff: Ari will not review your code, so pair it with the LeetCode reps.
How to prepare for the Google EM interview
- Weeks 1-3 — thirty coding problems in a plain editor, complexity stated aloud each time. Little and often beats a panic week.
- Week 3 — write eight real situations with names, dates and numbers: growth, performance, conflict, hiring, influence, a wrong decision, a late project, a departure.
- Week 4 — design three systems out loud, adding team split, sequencing, migration and on-call load to each.
- Final week — rehearse every story to two follow-ups deep, run two full spoken mocks including one coding round, and read the Google engineering manager prep page the night before.
Comparing loops? The Amazon engineering manager guide covers a more principle-driven and behaviorally heavier process, and the Google backend engineer guide covers the IC version of the technical rounds.
Frequently asked questions
Does Google make engineering managers do a coding interview?
Yes. Most engineering manager loops include at least one coding round, usually a single problem in the LeetCode easy-to-medium range such as a graph traversal, a hash-map counting problem or a heap question, often in a shared document with no execution. The bar is lower than for a senior individual contributor, but managers who have not written code in years routinely get caught out, so rebuilding typing fluency is worth three or four weeks of light practice.
What is the Google engineering manager interview process?
Candidates report a recruiter screen for scope calibration, a technical phone screen with a coding problem, and a virtual onsite of roughly a coding round, a system design round, two people-management rounds and a Googleyness and leadership round. A hiring committee then reviews written feedback from people who never met you, and team matching happens separately, which for managers is often the slowest stage because scope has to match.
What people management questions does Google ask?
They probe for specific instances rather than philosophy: how you grew a particular engineer and where they are now, a performance problem including when you first noticed and when you said it out loud, a real disagreement between two strong engineers, how you decide what your team works on and how you say no upward, a time you influenced a decision outside your team, how you run your hiring loop including a hire that did not work out, and what you do when your team disagrees with the direction.
Do engineering managers get a system design round at Google?
Yes, and the technical bar is close to the individual contributor bar, so deflecting to a tech lead is a failing answer even though it is often correct at work. On top of the standard design content you are expected to add team boundaries and the coordination cost they create, sequencing and what you would cut to hit a date, a migration path without a big-bang cutover, on-call and alerting load, and cost in both infrastructure and engineer-months.
What is the Googleyness round for a manager?
It is a scored round on ambiguity, cross-boundary collaboration, bias to action and honest self-assessment, weighted for managers towards influence without authority and decisions made with incomplete information. Prepare a decision you made without enough data and how you managed the risk, a cross-functional conflict you resolved, a time you publicly changed your position, and something you got wrong that affected your team.
How is the Google EM interview different from Amazon's?
Google keeps a real coding round and spreads its behavioral assessment across people-management and Googleyness rounds, with a hiring committee reading written notes rather than the panel deciding. Amazon runs more behavioral rounds, scores every one of them explicitly against named leadership principles, and adds a bar raiser from outside the hiring team who probes each story to the third follow-up and holds veto power.