Google Engineering Manager (Junior Level) Interview Preparation Guide

Core metrics & logs I’d track (why it matters)

• Request rate (RPS/throughput) — detects load changes, correlates with errors/latency and capacity planning.
• Latency percentiles (p50, p95, p99) — shows typical and tail user experience; p95/p99 expose outliers that break SLOs.
• Error rate (4xx/5xx, business errors) — alerts on functional regressions; tie to releases and downstream failures.
• Saturation: CPU / Memory / GPU — indicates resource exhaustion and need for scaling or tuning.
• GC metrics (pause times, frequency, heap usage) — critical for JVM/Go runtimes causing latency spikes.
• Disk IO / Network IO / IOPS — surfaces bottlenecks for DBs, file services, and backups.
• DB metrics (query latency, slow queries, connection pool usage) — backend health and contention.
• Service logs / structured traces (request IDs) — root cause analysis and correlation across services.
• Business metrics (checkout rate, conversion, active users) — link technical health to customer impact and prioritize fixes.

Tools

• Prometheus + Grafana — metrics collection, rich alerting rules and dashboards; great for SLO-driven ops.
• ELK (Elasticsearch, Logstash, Kibana) or Loki + Grafana — centralized logs, search, and correlation; or Datadog for integrated metrics/logs/traces with built-in alerts.

As an Engineering Manager I focus on SLOs, clear alerting thresholds to avoid noise, runbooks, and dashboards that map metrics to actionable ownership.

Direct answer

Anchor the plan on a per-instance capacity number you can actually benchmark, not a guess: measure current queries per second (QPS, queries per second) and the 95th-percentile (P95, the value below which 95% of observations fall) CPU and memory per instance, project the 3x traffic target onto that per-instance capacity to get a target instance count, and only then work out what that delta costs in infrastructure spend versus what it costs in engineering time and headcount. Those are two different questions: "how many more instances" is usually a budget and autoscaling-configuration decision, while "does the architecture even support that many instances cleanly" is the one that turns into a hiring conversation.

Structured elaboration

Inputs to gather

• Current peak QPS and its trend over recent months, not just a single snapshot.
• P95 CPU and memory utilization per instance at current peak load; P95 rather than average, because average hides the moments the system is actually under stress.
• A benchmarked (not assumed) maximum sustainable QPS per instance, measured under realistic load, not theoretical hardware limits.
• Current autoscaling configuration: minimum and maximum instance counts, and how long a new instance takes to become ready (cold-start time), since that affects how much buffer you need above the bare-minimum forecast.
• Recruiting lead time for the team, if the forecast implies new engineering work rather than just more of the same infrastructure.

Key calculation

$\text{required instances} = \left\lceil \frac{\text{peak QPS} \times \text{growth factor} \times (1 + \text{safety buffer})}{\text{QPS per instance}} \right\rceil$

Assume, as a planning input rather than a measured fact, a current peak QPS of 3,000, a benchmarked capacity of 150 QPS per instance, a 3x growth target, and a 20% safety buffer for headroom above the raw forecast:

$\left\lceil \frac{3{,}000 \times 3 \times 1.20}{150} \right\rceil = \left\lceil \frac{10{,}800}{150} \right\rceil = \left\lceil 72 \right\rceil = 72 \text{ instances}$

For comparison, today's instance count under the same 20% buffer:

$\left\lceil \frac{3{,}000 \times 1.20}{150} \right\rceil = \left\lceil 24 \right\rceil = 24 \text{ instances}$

Instance count scales linearly with traffic here (from 24 to 72, a 3x increase matching the 3x traffic target), because per-instance capacity was held constant. That linearity check is itself useful: if the projected instance count did not scale roughly with the traffic multiplier, it would signal that something other than raw compute, a shared dependency like a database connection ceiling, is the real constraint, not instance count.

Turning the forecast into decisions

If the forecast requires new engineering work, translate the estimated effort into a hiring ask against your team's actual recruiting lead time (commonly a few months for a senior engineer, a planning assumption you should validate against your own team's recent hiring, not a fixed constant) rather than assuming headcount can be added instantly once budget is approved.

Trade-offs & pitfalls

• The formula assumes per-instance capacity stays constant as load grows; if the bottleneck is actually a shared resource (a database, a single-instance cache, a rate-limited third-party API), adding instances past that point doesn't help and the linear projection will be wrong in a way the math alone won't reveal.
• Skipping the safety buffer and rounding down "to save cost" removes exactly the headroom meant to absorb the difference between a forecast and reality; a moderate buffer is worth its cost until you have data suggesting otherwise.
• Treating this as a one-time calculation rather than a recurring check misses the point: re-run it with fresh telemetry each quarter, because both the QPS-per-instance benchmark and the growth trend can shift as the product and traffic mix change.
• Converting a capacity gap directly into a headcount number without first checking whether it's actually an autoscaling or budget problem leads to over-hiring for what could have been solved by turning a dial.

When growing a team quickly, I start with the work, not the headcount.

What to hire first:

• I identify the biggest constraint: product velocity, platform reliability, or operational load.
• Then I map the missing capabilities, such as senior IC leadership, test automation, DevOps, or product engineering.

How many to add:

• I size hires based on throughput bottlenecks and onboarding capacity, not an arbitrary ratio.
• I prefer smaller waves so the team can absorb new people well and avoid creating management drag.

Internal promotion vs external hire:

• Promote internally when I need cultural continuity, domain knowledge, or a trusted interim leader.
• Hire externally when I need new expertise, a fresh pattern, or a capability the current org does not have.

I usually aim for a mix: internal promotions for ownership and team stability, plus targeted external hires for gaps we cannot fill quickly from within. The key is sequencing so each hire meaningfully increases capacity rather than just adding coordination overhead.

Diagnose (observe + ask + measure)

• Review past 6 sprints: committed vs completed, scope changes, carryover, and per-story cycle times (Jira/Trello).
• Run interviews: tech leads, PM, QA, and devs to surface causes (over-optimism, interruptions, unclear stories, technical debt, blockers).
• Run an augmented retro focused on root causes (use 5 Whys), and map typical flow — backlog → ready → in progress → done.

Concrete changes

Estimation

• Move to relative sizing (T-shirt or story points) + calibrate with a small set of reference stories.
• Timebox re-estimation monthly and track estimate accuracy per story to identify bias.
• Encourage “no single-person estimates” — pair or group-estimate for complex items.

Grooming

• Enforce Definition of Ready (acceptance criteria, mocks, deps identified).
• Short, frequent grooming sessions with dev + QA + PM; split ambiguous stories before sprint.

Sprint planning

• Use measured velocity (average of last 3 stable sprints) and reserve buffer (10–20%) for unplanned work.
• Limit WIP by enforcing capacity per engineer (planned hours) rather than point-guessing.
• Make dependencies visible and negotiate scope with PM up-front.

Tracking & Feedback

• Daily standups focused on blockers and progress against plan; highlight scope creep.
• Use a sprint health dashboard: percent complete, carryover, blocked items, burndown.
• Weekly check-ins mid-sprint to replan if necessary.

People & Culture

• Treat missed commitments as process signals, not blame. Celebrate delivered work and improvements.
• Coach teams on breaking down stories and raising blockers early.

Expected outcome: within 2–3 sprints, tighter planning, reduced carryover, improved estimate accuracy and predictability while maintaining team morale.

Direct answer

A stakeholder asking for something in half the honestly-estimated time is really asking you to either cut scope, accept more risk, or find more resourcing, and the job is to make that trade-off explicit and let them choose deliberately, rather than silently absorbing the pressure and hoping the estimate was pessimistic.

Structured elaboration

1. Understand WHY the timeline matters. A hard external commitment (a contractual date, a regulatory deadline) is a very different situation from an aspirational internal target; the response should differ accordingly.
2. Show your estimate's structure, not just the number. Break down what the time is going into (build, testing, migration, validation) so a compressed timeline reads as a specific trade-off against specific work, not an arbitrary padding you're being asked to cut.
3. Offer real options, not a single counter. A smaller first release that ships faster, more resourcing if that's genuinely available, or accepting a defined, bounded amount of additional risk (for example, less test coverage on a low-traffic path) are all legitimate paths; presenting one option as the only alternative to "yes" invites a standoff.
4. Make the choice theirs, explicitly. "Here are three ways to hit that date, each with a different trade-off; which fits your priorities" puts the decision where it belongs.

Worked example

A product manager asks for a production-ready model in two weeks against a six-week honest estimate. Rather than simply pushing back, laying out three paths works better: (1) ship a narrower version covering the highest-value segment in two weeks, with the full version following in four more; (2) hit the full two-week date with a known, bounded quality gap (for example, no support for one edge case) that's explicitly flagged, not silently shipped; (3) keep the six-week estimate but pull in extra engineering support if it's genuinely available. Each path is honest about what's actually being traded, and the stakeholder picks based on what matters most to them.

Trade-offs and pitfalls

The risk in offering options is that a stakeholder picks the option with the least visible cost without fully registering the risk it carries; be explicit and specific about the downside of each choice, not just its upside, so the choice is genuinely informed.

Direct answer

Split along business capability and data ownership, not by technical layer, and treat coupling and cohesion as the actual test: a service boundary is right when it groups things that change together and separates things that don't, and when one team can own its full lifecycle (build, deploy, operate) without waiting on another team to also deploy. Team size and deployment cadence usually decide the timing more than the theory does: a well-modularized monolith can run comfortably until the coordination cost of shared deploys and shared blast radius starts to exceed the operational cost of running the same code as separate services.

Structured elaboration

The criteria, applied together

• Bounded context or business capability: one service per coherent business concept (Orders, Inventory, Billing), not per database table.
• Data ownership: the service that owns a piece of data is its only writer; everyone else goes through its API or its events, never a shared schema.
• Deployment independence: if two "services" cannot be deployed on separate schedules without breaking each other, they are one service wearing two names, a distributed monolith.
• Team boundaries (Conway's Law: a system's structure tends to mirror the structure of the team that builds it): align a service to a team that can own it end to end, so ownership and org chart don't fight each other.
• Transaction boundary: keep operations that need a real ACID (atomicity, consistency, isolation, durability) transaction inside one service; cross-service consistency should default to eventual consistency plus an explicit compensating action, not a distributed transaction.
• Chattiness: if two components exchange many synchronous calls per user request, the network hop between them is pure overhead with no ownership benefit; merge them.

The team-size-driven worked example (absorbed angle)

Consider an org at 200 people, organized as roughly 20 teams, running a well-modularized monolith with clear internal module boundaries (a modular monolith). Model the shared deploy pipeline as a single server processing one deploy at a time, 30 minutes each, across a 16-hour working day (960 minutes):

$$\text{deploy capacity/day} = \frac{960}{30} = 32 \text{ deploys}$$ $$\text{demand at 20 teams (1 deploy/day each)} = 20 \text{ deploys/day}$$ $$\text{utilization} = \frac{20}{32} = 62.5\%$$

At 62.5% utilization there is queueing delay, but the pipeline is stable. Now grow to 500 people, roughly 50 teams, same one-deploy-at-a-time pipeline:

$$\text{demand at 50 teams} = 50 \text{ deploys/day} > 32 \text{ deploys/day capacity}$$

Demand exceeding capacity on a single-server queue means the queue is unstable: it does not just get slower, it grows without bound. That crossing point, not a stylistic preference for microservices, is the concrete signal to start extracting services along the module boundaries the modular monolith already has, so teams stop sharing one serialized deploy pipeline and one shared blast radius.

Anti-patterns that signal you split wrong (or didn't split at all)

• Shared database schema across "separate" services: the clearest sign of a distributed monolith with extra network hops.
• Splitting by technical layer (a UI service, an API service, a database-access service) instead of by capability: nothing can deploy alone, because every user-facing change touches all three.
• A "god" service or shared library that every team depends on for routine changes: it recreates the same coordination bottleneck a monolith had, with worse debugging.
• Over-splitting a capability that still needs real ACID guarantees just because a diagram looks tidier with more boxes.

Trade-offs & pitfalls

• Splitting too early, before the coordination cost above actually bites, buys distributed-systems complexity (network calls, partial failure, eventual consistency) for a coordination problem you didn't have yet.
• Splitting too late means the deploy-pipeline math above turns into a real, measured queue of waiting teams, not a hypothetical.
• The bounded-context choice is the expensive one to get wrong: correcting a wrong service boundary later means a data migration, not just a configuration change.
• Watch for teams treating microservices as a goal instead of a response to a specific coupling problem; the checklist above should produce the boundary, not the other way around.

Summary goal (18 months): grow headcount 20 → 120 while keeping autonomous, high-quality teams.

Assumptions & constraints

• Product areas: 6 domains. Hiring evenly but prioritized by roadmap.
• Target team size: 6–9 engineers product-aligned.

Team topology

• Stream-aligned teams (owner of feature areas)
• Platform team(s) for common infra, CI/CD, observability
• Enabling teams for migrations/skill gaps
• Complicated-subsystem team for core infra

Manager/lead spans

• Frontline EM span: 7–9 ICs (1 EM per team)
• Tech lead (senior IC) per team handling day-to-day architecture
• Director layer: 3 Directors (each 3–4 EMs)
• VP/Head of Eng overseeing the org

Hiring/phasing plan (18 months)

• Phase 0 (0–3m): hire 6 EMs / 12 ICs to start forming 3 new teams; hire Head of Eng.
• Phase 1 (4–9m): hire 30 ICs + 2 Directors + 3 Tech Leads; ramp platform and enabling teams.
• Phase 2 (10–15m): hire 40 ICs + remaining EMs to keep spans ≤9.
• Phase 3 (16–18m): final 12 hires, QA, SRE, and training capacity.

Onboarding & mentorship

• Onboarding throughput: 8–10 hires/month peak. 2-week bootcamp + 90-day ramp plan.
• Mentorship ratio: 1 mentor per 3 new hires; rotate senior ICs with 0.2 FTE mentoring support.
• Buddy + onboarding OKRs; weekly checkpoints.

Quality controls

• Standardized code review SLAs, trunk-based CI, automated tests, SRE SLOs.
• Architecture review board (lightweight) for cross-team changes.

Key risks & mitigations

• Hiring quality drop — use bar-raisers, hiring metrics, slow ramp if needed.
• Manager shortage — hire/promote early EMs; internal leadership program.
• Knowledge silos — cross-team guilds, docs, rotation weeks.
• Culture dilution — maintain rituals, offsites, 1:1 cadence, competency frameworks.

Why this works: preserves autonomy via stream-aligned teams, keeps spans manageable, builds platform/enabling support, and phases hiring to protect quality while scaling.

Direct answer
Three boundaries matter most: confidentiality (what's said in a mentoring conversation doesn't automatically become input to a performance review), favoritism (visible time and opportunity should be fair and roughly trackable, not just felt fair), and the evaluator conflict (mentoring someone you also formally evaluate creates a structural incentive problem, since they cannot be fully candid with someone who scores them). The practical fix is not avoiding all overlap, since it is often unavoidable, it is naming the boundary explicitly up front and having a plan for when it blurs.

Structured elaboration

Worked example
Situation: I was mentoring someone I would later be asked to give calibration input on for a promotion cycle.
Task: keep the mentoring relationship honest without compromising the integrity of the eventual evaluation.
Action: I told them directly, early, that promotion calibration might eventually involve my input, so mentoring conversations and evaluation conversations were separate. When something they shared in a mentoring context, a specific technical mistake, later became relevant to an honest performance discussion, I went back to them first rather than using it silently, and asked how they wanted it handled.
Result: the relationship stayed trustworthy because the boundary was named rather than assumed, even though the overlap between mentor and evaluator could not be fully removed.

Trade-offs & pitfalls
Pretending you can be a purely neutral mentor when you structurally have some evaluator influence is dishonest and erodes trust once it surfaces. Over-formalizing boundaries, a written contract for every casual pairing, feels bureaucratic when the stakes don't call for it, so match the formality to the actual overlap: an evaluator relationship needs an explicit conversation, a casual peer pairing usually doesn't. The senior distinction is naming the boundary before it's tested, not scrambling to explain it after a mentee feels burned.

Direct answer

Say what the success metric was, where the baseline number came from, and what target you set, before you describe the outcome. The interviewer is probing whether "success" was defined up front and grounded in a real measurement, versus decided retroactively once you knew how things turned out.

How to define and defend success criteria

Pick a metric tied to an outcome, not an output. "We shipped the feature" is an output; "time-to-first-task dropped" or "escalation volume fell" is an outcome. Output-only "success" criteria are a common tell that the metric was picked after the fact.

Establish the baseline honestly. State exactly where the baseline number came from: an existing dashboard, a manual count over a defined window, or a proxy metric if the exact one didn't exist yet. If you had to estimate, say so and say how.

Set the target with reasoning, not a round number pulled from nowhere. A defensible target is anchored to something: a competitor benchmark, a prior period's rate of improvement, or the minimum change needed to matter to the business.

Leading vs. lagging metrics:

Pairing one of each lets you show early progress without over-claiming the final outcome too soon.

Worked example (skeleton)

Baseline: support tickets tagged "onboarding confusion" averaged 20 per week over the prior month, pulled directly from the ticketing system's tag filter. Target: cut that to under 10 per week within two months of shipping a redesigned onboarding flow, a 50% reduction chosen because it was the minimum drop the support lead said would let them reallocate a headcount from triage to other work. Guardrail: overall support volume tracked in parallel, to catch a bug where confused users simply stopped filing tickets instead of getting unconfused.

Trade-offs and pitfalls

• Don't present an output metric as if it were the success criterion; "we launched on time" is a milestone, not a definition of success.
• Be ready to say exactly where the baseline number came from; "around 20 a week" with no source is the kind of claim that collapses under a follow-up question.
• Watch for target numbers that look precise but have no derivation behind them; a round target with stated reasoning is more credible than a falsely precise one with none.
• A guardrail metric (something that would catch you gaming the primary metric) is what separates a senior answer from a junior one here.

High-level approach
Estimate monthly delta = (compute + control-plane + LB + storage + data-transfer + logging + monitoring) for EKS minus current EC2 baseline. Break each into unit metrics (hours, GB, vCPU-hours, GB transferred, log GB) then multiply by cloud pricing.

Factors and how to size them

• Compute: translate 1,000 RPS → required concurrency → pods → vCPU & memory. Example: assume one pod (0.5 vCPU,1GB) handles 200 RPS → 5 pods baseline; with HA and autoscaling buffer use 3× → 15 pods. Map pods to node sizes (e.g., m5.large, 2 vCPU). Calculate node count and vCPU-hours × price.
• EKS control plane: managed EKS fee (~$0.10/hr per cluster) and cost of managed node groups or Fargate (use whichever you plan).
• Load balancers: NLB/ALB hourly charges + per-GB processed. Estimate active connections and egress.
• Storage: EBS for nodes (size × IOPS if provisioned) and persistent volumes (EFS if used).
• Data transfer: egress to Internet and cross-AZ; multiply GB/month by per-GB rates.
• Logging: CloudWatch ingestion and retention (GB/day → monthly cost) and S3 archival.
• Monitoring: Prometheus/Thanos on EKS (additional nodes/storage) or managed solutions (CloudWatch Container Insights) — include their compute and storage.

Concrete quick example (illustrative)

• Compute: 15 pods → ~5 m5.large nodes @ $0.096/hr → 5 * 24 * 30 * 0.096 ≈ $345/month
• EKS control plane: 24300.10 ≈ $72/month
• ALB + data: ALB ~$20 + 10TB egress @ $0.09/GB ≈ $900
• CloudWatch logs: 100 GB/month ingest ≈ $30
  Total ≈ $1.4k/month (values illustrative; compute precise with real metrics)

Validation strategy (tests / pilot)

• Metric collection: instrument current EC2 service to capture RPS, latency P95/P99, CPU/memory per process, connection counts, network egress, and daily log volume.
• Small-scale pilot: deploy identical service on EKS with autoscaling; run synthetic load tests (k6, Gatling) ramping to 1,000 RPS while measuring pod density, node packing, LB behavior, and egress.
• Cost pilot: run pilot for 1–2 weeks with representative traffic (or replay production traces) and gather billing tags to extrapolate monthly spend.
• Safety checks: run chaos tests (node drain, scaling) to ensure HA and validate headroom assumptions.
• Iterate: adjust pod sizing, node types (spot vs on-demand), use savings plans/reserved instances, and re-run pilot to refine TCO.

As an engineering manager I’d present the modeled estimate, validation plan, and risks (control-plane + LB and logging often drive surprises), then run the short pilot with clear success metrics before wider migration.