Google Engineering Manager (Entry Level) Interview Preparation Guide
Engineering Manager
Google
entry
6 rounds
Updated 6/17/2026
Google's Engineering Manager interview process for entry-level candidates consists of a recruiter screening phase, followed by a technical phone screen focused on foundational problem-solving and system thinking, and an onsite loop of 4-5 interviews covering technical depth, system design fundamentals, behavioral competencies, people management scenarios, and cultural alignment. The process emphasizes both technical credibility and people leadership capabilities.
Interview Rounds
1
Recruiter Screening
45 min3 focus topicsculture fit
What to Expect
Your initial contact with a Google recruiter who evaluates your background, motivation for the EM role, and cultural fit. This conversation establishes your management philosophy, technical background, and readiness for the role. The recruiter will also provide an overview of Google's interview process, timeline, and interview preparation resources.
Tips & Advice
Be genuine and concise about your transition to management. Clearly articulate why you're interested in leading at Google specifically. Prepare specific examples of how you've helped team members grow or improved team processes. Ask thoughtful questions about the role, team structure, and what success looks like. Mention any relevant technical background that makes you credible in managing engineers. This round is primarily to screen for basic fit and to ensure you understand the process ahead.
Focus Topics
Early Leadership Experience
Mentoring peers, leading projects, influencing decisions, or supporting team members in past roles
Practice Interview
Study Questions
Technical Background and Credibility
Your experience as an engineer, technical depth, and ability to maintain technical oversight while managing
Practice Interview
Study Questions
Motivation for Engineering Management
Why you're transitioning from IC role to management; specific interest in Google; understanding of EM responsibilities
Practice Interview
Study Questions
2
Technical Phone Screen
60 min3 focus topicstechnical
What to Expect
A 60-minute technical assessment covering data structures, algorithms, and problem-solving fundamentals. As an EM, you'll demonstrate your technical depth using medium-level coding problems (LeetCode-style). This validates that your engineering foundation is solid enough to credibly lead engineers and participate in technical decisions. You may code in your language of choice.
Tips & Advice
This round assesses whether your technical fundamentals remain sharp. Walk through your thinking process aloud—interviewers want to see your problem-solving approach. Start with a brute-force solution and optimize from there. Write clean, readable code. Discuss time and space complexity clearly. It's acceptable as an entry-level EM to take time to think; don't rush. If you get stuck, communicate your thought process and ask clarifying questions. Focus on demonstrating competence, not perfection.
Problem-solving approach, recognizing patterns, optimization from brute-force to efficient solutions, time/space complexity analysis
Practice Interview
Study Questions
Data Structures Fundamentals
Arrays, linked lists, trees, graphs, hash tables, queues, stacks—when to use each and basic operations
Practice Interview
Study Questions
3
Onsite: Technical Depth & System Thinking
60 min3 focus topicssystem design
What to Expect
This 60-minute session evaluates your ability to think about technical systems at a higher level than typical coding problems. You'll discuss or design aspects of systems you've worked on, demonstrating architectural thinking and the ability to consider scalability, trade-offs, and design decisions. As an entry-level EM, this assesses your foundation for understanding the systems your team will build and your ability to guide technical direction.
Tips & Advice
Focus on foundational system design thinking rather than complex distributed systems. Ask clarifying questions to understand requirements. Start with a simple design and explain trade-offs (e.g., consistency vs. availability). Discuss why you made certain architectural choices. It's acceptable to acknowledge areas you'd need to research deeper—entry-level EMs are still learning. Draw diagrams to illustrate your thinking. Connect your design to real problems you've seen your team face or systems you've worked with.
Focus Topics
Design Decisions and Technical Reasoning
Explaining why you chose certain technologies or approaches; discussing constraints (cost, latency, availability); considering team capability and timeline
Practice Interview
Study Questions
Scalability and Performance Trade-offs
Identifying bottlenecks, scaling strategies (vertical vs. horizontal), database scaling, caching strategies, understanding trade-offs between latency and consistency
Practice Interview
Study Questions
System Architecture Fundamentals
Components of systems, how they interact, client-server models, APIs, databases, caching, queues; basic architectural patterns
Practice Interview
Study Questions
4
Onsite: People Management & Team Leadership
60 min4 focus topicsbehavioral
What to Expect
This 60-minute behavioral interview focuses on your ability to manage and support engineers. Expect questions about mentoring, feedback, conflict resolution, supporting underperforming team members, developing team members, and creating psychological safety. You'll discuss your philosophy on 1:1s, career development, and building high-performing teams. As entry-level, you're expected to show foundational understanding and eagerness to learn management practices.
Tips & Advice
Use specific examples from your career where you've supported others—mentoring peers, helping resolve conflicts, giving feedback, or supporting someone through a challenge. Use the STAR method: Situation, Task, Action, Result. Be honest about what you've learned from management mistakes or situations that didn't go well. Show self-awareness about areas you're still developing. Frame early-stage management challenges as learning opportunities. Focus on your genuine interest in helping people grow. Avoid sounding overly scripted; authenticity matters here.
Focus Topics
Conflict Resolution and Difficult Conversations
Handling disagreements between team members, addressing performance issues, managing personalities, maintaining team dynamics, psychological safety
Practice Interview
Study Questions
Diversity, Inclusion, and Psychological Safety
Creating an environment where all team members feel valued and safe to contribute, recognizing bias, supporting underrepresented colleagues
Structure and purpose of 1:1s, giving constructive feedback, listening effectively, supporting engineers through challenges, documentation and follow-up
A 60-minute behavioral interview focused on your ability to plan projects, set priorities, execute under constraints, and collaborate across teams. You'll discuss how you've managed projects from planning through delivery, how you handle ambiguity, manage stakeholders, and work with non-engineering teams. This evaluates your operational leadership and ability to get things done at Google's scale.
Tips & Advice
Prepare 2-3 detailed examples of projects you've worked on—discuss the problem, your approach, challenges faced, how you collaborated with others, and outcomes. Quantify results where possible (e.g., timeline met, resources saved, impact). Discuss how you've handled ambiguous requirements or changing priorities. Show your ability to break down complex problems into manageable pieces. Discuss stakeholder communication and how you've managed expectations. For entry-level, it's fine to discuss lessons learned rather than always perfect execution.
Focus Topics
Cross-functional Collaboration
Working with product, design, data, other engineering teams, stakeholder management, communication across disciplines, resolving dependencies
Practice Interview
Study Questions
Prioritization and Trade-off Decisions
How you make decisions about what to focus on, handling competing priorities, saying no, understanding business impact, technical vs. business trade-offs
Breaking down projects into phases, setting realistic timelines, identifying dependencies and risks, tracking progress, adjusting when needed
Practice Interview
Study Questions
6
Onsite: Google Culture & Leadership Values
60 min4 focus topicsculture fit
What to Expect
A 60-minute behavioral interview assessing cultural alignment with Google's values and your leadership philosophy. This round evaluates your understanding of Googleyness—bias toward action, collaboration, user focus, innovation mindset—and how you embody these in your leadership approach. You'll discuss how you've driven impact, acted with urgency, fostered innovation, and aligned with Google's mission.
Tips & Advice
Research Google's leadership principles and mission. Prepare examples demonstrating: bias toward action (making decisions despite uncertainty), user focus (thinking about impact), collaboration (working effectively with others), and continuous learning (adapting and growing). Show genuine interest in Google's mission and products. Discuss how you'd bring these values to your team. As entry-level, acknowledge areas where you're still developing but show commitment to these principles. Be authentic—Google is looking for leaders who genuinely align with these values, not those reciting them.
Focus Topics
Leadership Philosophy and Team Culture
Your approach to leadership, how you want to be seen as a leader, what kind of culture you want to build, your values, how you handle setbacks
Practice Interview
Study Questions
Continuous Learning and Adaptability
Willingness to learn new technologies and management practices, adapting to feedback, growing through failures, intellectual curiosity
Practice Interview
Study Questions
Impact and Business Acumen
Understanding how your work connects to business outcomes, driving measurable results, thinking about scale and impact, data-driven decision-making
Practice Interview
Study Questions
Google Culture Alignment and Googleyness
Understanding Google's mission and values; bias toward action and rapid iteration; user focus and customer impact; innovation and learning mindset
Describe your approach to onboarding a new senior engineer joining a feature team. Provide a concrete 90-day onboarding plan that includes: goals and milestones for weeks 1, 2-4, and 30-90; mentorship and pairing strategy; key documentation and technical setup; and 3 measurable success criteria. Explain how you would adapt this plan for fully remote hires.
Sample Answer
**Overview (role & goal)** I treat the first 90 days as rapid context-building + early impact while setting up long-term expectations. The plan balances technical onboarding, team integration, and ownership.**Weeks 1 — Orientation & setup**- Goals: full dev environment, access, and repo familiarity.- Activities: HR/IT onboarding, run local build + first smoke PR, read architecture overview and recent RFCs.- Mentor assignment: senior engineer buddy + manager weekly 1:1.**Weeks 2–4 — Deep dive & small deliveries**- Goals: ship a small bugfix or feature; learn codebase, CI, deploy process.- Activities: pair on two tickets, join design reviews, attend on-call shadowing.- Mentor: rotating pairing with modules’ owners; manager focuses on career expectations.**Days 30–90 — Ownership & impact**- Goals: lead one feature, own a service/area, propose one improvement (performance/tech debt/process).- Activities: design doc ownership, mentor another engineer, participate in roadmap planning.**Key documentation & setup**- Architecture diagrams, runbooks, deployment playbooks, coding standards, recent RFCs, tickets, monitoring dashboards, Slack/Docs access.**Mentorship & pairing strategy**- Buddy for social/context, rotating technical pairings for domain knowledge, weekly syncs with manager, bi-weekly feedback loop.**3 measurable success criteria**1. First PR merged and deployed within 14 days. 2. Ownership: leading a feature and merged release by day 60. 3. 360° feedback score ≥ 4/5 from peers on collaboration and code quality by day 90.**Remote adaptation**- Add scheduled async checklist, twice-weekly pairing via screen-share, recorded walkthroughs, virtual coffee intro with stakeholders, and explicit documentation of decisions and async expectations.
Conflict Resolution and Difficult ConversationsMediumTechnical
68 practiced
Your team avoids direct disagreement and instead files long RFCs where no one makes a clear decision, causing delays. Diagnose this 'silent conflict' pattern and propose interventions (changes to rituals, roles, decision rules, facilitation techniques) to encourage healthy debate and faster resolution.
Sample Answer
**Diagnosis (pattern & cause)** The team uses RFCs as a proxy for conflict avoidance: lengthy documents replace live debate, decisions are deferred, accountability blurs. Root causes: low psychological safety, unclear decision ownership, lack of timeboxed forums, and a culture that equates politeness with consensus.**Interventions — Rituals** - Add a 30‑minute Decision Kickoff: present options, assumptions, and recommended choice. - Timeboxed RFC review meetings with explicit decision agenda (accept/reject/defer). - Weekly “Triage” slot to close outstanding RFCs older than X days.**Interventions — Roles & Decision Rules** - Assign a RACI per RFC; name the final decision owner (e.g., Tech Lead or EM). - Use decision rules: consult, majority, or single‑owner for different scopes. - Rotate a neutral facilitator for heated topics.**Facilitation Techniques & Culture** - Encourage dissent with structured techniques: pre‑mortem, red‑team, and “one-minute rebuttal.” - Normalize visible pros/cons in RFC header and a recommended decision. - Use 1:1s to surface blocked opinions; coach psychological safety and reward constructive challenge.**Expected outcomes** Faster resolutions, clearer accountability, reduced RFC churn, and healthier debate that improves technical quality.
System Design and Architecture FundamentalsMediumSystem Design
104 practiced
As an Engineering Manager, design a distributed rate limiter to enforce per-user and per-endpoint quotas across multiple stateless service instances. Requirements: low-latency enforcement, burst support, configurable policies, horizontal scalability, and graceful degradation if the limiter fails. Describe algorithms and storage choices.
Sample Answer
**Clarify requirements**- Enforce per-user and per-endpoint quotas across stateless instances- Low latency, allow bursts, config per user/endpoint, scale horizontally, graceful degradation on failures**High-level approach**- Use a Token Bucket algorithm for burst + steady-rate control.- Place a single authoritative store for counters (fast in-memory DB like Redis Cluster) and a local fast-path cache on each instance for low-latency checks.**Architecture**- Each service instance: - Maintains a small local token cache (tokens refilled periodically from central store). - On request: try local consume; if miss, call central store with a fast Lua script for atomic token refill/consume.- Central store: - Redis Cluster with key sharding by (userId:endpoint). Use Lua script implementing token-bucket semantics atomically. - Fallback durable store (DynamoDB) for long-term quotas and sync.ASCII flow:Client -> Service instance -> (local cache) -> Redis (Lua) -> Respond**Algorithms & implementation details**- Token-bucket state per key: last_refill_ts, tokens.- Redis Lua script:
lua
-- load state, compute tokens += (now-last)*rate, cap to burst, if tokens>=1 then tokens-=1; save; return allowed
- Configs stored in config service/feature flags (per-user/per-endpoint): rate, burst, enforcement window.**Scalability**- Shard Redis keys using consistent hashing; autoscale Redis Cluster nodes.- Service instances stateless — scale independently.- Use batching for refill sync and TTLs to purge inactive keys.**Graceful degradation**- Fail-open soft limits: if Redis unavailable, allow local cached tokens up to a conservative emergency burst; degrade to global soft-rate (e.g., 10% capacity) and emit alarms/metrics.- Circuit breaker + rolling rate reduction policy pushed via config service.**Consistency & correctness trade-offs**- Strong correctness via central atomic Lua calls; local cache improves latency at cost of slight over-allowance (bounded by local burst).- For strict accounting, route all checks to Redis (higher latency) or use central proxy.**Monitoring & ops**- Expose metrics: allowed/blocked, cache-hit rates, Redis latency, fallback activations.- Automated alerts and dashboards; periodic reconciliation job to detect drift.Why this design (as manager)- Balances product need (low-latency bursts, configurable quotas) and engineering constraints (operational complexity, cost).- Enables incremental rollout, measurable fallbacks, and clear SLAs for availability and correctness.
Data Structures and ComplexityMediumTechnical
80 practiced
A reporting endpoint is slow because queries are doing full table scans. From a data-structure perspective, explain how B-tree indexes, hash indexes, and covering indexes work and when each is appropriate. As a manager, outline the triage steps your team should take to diagnose and fix the performance issue.
Sample Answer
**Overview — data-structure behavior**B-tree indexes - Balanced tree storing sorted key ranges; supports range scans, ORDER BY, prefix lookups, and inequality comparisons efficiently. - Appropriate when queries filter on ranges, do ORDER BY, multi-column left-prefix lookups, or when index must be disk-friendly for large tables.Hash indexes - Hash table mapping keys to row pointers; excellent for exact equality lookups (key = value) with O(1) expected cost, but cannot serve range queries or ordering. - Appropriate for high-volume point-lookup workloads where equality predicates dominate and the DB supports hash indexes.Covering indexes - An index that contains all columns a query needs (filter + select), so the engine can answer without touching the base table (index-only scan). Great for reducing I/O and avoiding random reads. - Use when frequent reports request a small fixed set of columns; trade-off: increased write cost and storage.**Manager-level triage and remediation plan**1. Quick verification (0–2 hrs) - Reproduce slow query; capture EXPLAIN/EXPLAIN ANALYZE and metrics (latency, CPU, IO). Identify full table scan and missing index recommendations.2. Triage (2–8 hrs) - Check query patterns: equality vs range, columns in WHERE/ORDER/GROUP/SELECT. Review table size, existing indexes, cardinality, and data skew. Check recent schema or data growth.3. Fix design (8–48 hrs) - Add appropriate index: B-tree for ranges/ordering, hash for point-equality (when supported), or a covering index if query can be satisfied entirely. Consider multi-column left-prefix order. Test on staging with realistic data.4. Validation & rollout (48–72 hrs) - Run EXPLAIN to confirm plan changes. Monitor production after deployment, track latency, IO, and write amplification.5. Longer-term (weeks) - Implement index-usage monitoring, cost/benefit review for maintenance overhead, and query ownership: enforce query reviews, add automated EXPLAIN checks in CI.**Trade-offs & governance** - Weigh read benefit vs write overhead and storage. Use monitoring, runbooks, and assign owner for slow-query alerts and index lifecycle.
People Management and Team BuildingHardSystem Design
29 practiced
Design an organizational structure and hiring/phasing plan to scale an engineering org from 20 to 120 engineers in 18 months while preserving team autonomy and engineering quality. Specify team topologies, manager spans, leadership roles to add, onboarding throughput, mentorship capacity, and key risks with mitigation strategies.
Sample Answer
**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.
Prioritization and Stakeholder AlignmentMediumTechnical
70 practiced
Describe a playbook to sequence cross-team dependent work to minimize blocked engineers and wasted effort. Include at least six concrete steps (e.g., contract-first APIs, vertical slices, parallel spikes, interface tests, feature flags, and integration windows) and a short explanation of how you would measure the playbook's effectiveness.
Sample Answer
**Playbook to sequence cross-team dependent work****1. Clarify requirements & contracts first**- Require API/interface contracts (OpenAPI/IDL) and data schemas before implementation so teams can work against a stable spec.**2. Slice vertically**- Break features into end-to-end vertical slices that deliver customer value and limit cross-team scope per increment.**3. Run parallel spikes**- Allocate short-timebox spikes for unknowns (performance, infra, auth) so dependent decisions land early.**4. Provide interface tests & mocks**- Ship consumer-driven contract tests and provider mocks; CI validates compatibility on every PR.**5. Use feature flags & progressive rollout**- Deliver behind flags to decouple deploy from release, enabling incremental integration and easy rollback.**6. Schedule integration windows & syncs**- Reserve regular cross-team integration windows (biweekly) and short daily syncs during cutover to resolve blockers.**7. Documentation + ownership**- Maintain a single source of truth (confluence + ownership matrix) and clear escalation paths.Measuring effectiveness- Track cycle time for dependent work, number of blocked engineers, frequency of integration regressions, and deployment rollback rate. Target: reduce blocked time by X% and regressions by Y% over a quarter. Combine quantitative metrics with monthly team feedback surveys to validate reduced friction and improved predictability.
Cross Functional Collaboration and CoordinationHardTechnical
49 practiced
Senior executives disagree with your recommended technical path: it reduces short-term revenue but materially improves long-term security and compliance. How would you influence executives and get sponsorship without formal authority? Explain the narrative, data, stakeholders you would enlist, and a phased approach to de-risk the recommendation.
Sample Answer
**Situation (brief)** When I inherited a payments platform, security debt required a migration to a hardened stack that would delay a new revenue feature by ~3–6 months. Execs pushed to ship the revenue feature immediately.**Task** Win executive sponsorship for the security-first technical path without formal authority, by demonstrating business impact, aligning stakeholders, and proposing a de‑risked phased plan.**Narrative & Influence approach** - Start with the customer and regulatory story: explain how a single breach or non-compliance fine could halt revenue flow, erode merchant trust, and trigger audits. Paint the future risk in business terms they care about. - Translate technical benefits into financial metrics: probability of breach, expected loss (revenue loss, fines, remediation cost), and risk reduction per investment dollar. Use a simple risk equation:
text
Expected Loss = Probability of Breach × Cost per Incident
Explain intuition: lowering probability materially lowers expected loss.**Data to present** - Incident benchmarks (industry breach rates, average remediation costs) and internal telemetry (vulnerable endpoints, failed audits). - Scenario models: best/likely/worst case financial outcomes over 1–3 years comparing both paths. - Time-to-market impact quantified and mitigations for near-term revenue.**Stakeholders to enlist** - CIO/security lead for credibility on technical and compliance impact. - Product lead and revenue owner to co-own trade-offs and identify minimally viable revenue scope. - Legal/compliance to validate regulatory risk. - Finance to co-create the cost/loss model. - A respected engineering technical lead to validate feasibility and timelines.**Phased, de-risking plan** 1. Quick wins (0–4 weeks): implement compensating controls (WAF rules, extra monitoring, emergency rollback plans) to reduce immediate risk while work begins. 2. Phase 1 (1–3 months): refactor critical surface areas to the hardened stack that protect high-value transactions; release a narrow revenue feature slice. 3. Phase 2 (3–6 months): complete migration, run external pen-test and compliance audit, and enable full feature set. 4. Gate reviews: at each phase present KPIs (incident rate, test results, compliance checklist, revenue milestones) to execs for go/no-go.**Outcome & ask** Request a time-bound sponsorship: executive endorsement of the phased plan, commitment to KPIs, and a contingency budget for accelerated vendor help if metrics lag. This aligns short-term revenue needs with long-term security and makes the decision data-driven and reversible.
Team Leadership and DevelopmentEasyTechnical
57 practiced
How do you structure one-on-one meetings with direct reports to balance short-term delivery, career development, and personal well-being? Provide a reusable one-on-one agenda template and explain cadence, preparation, and what you track between meetings.
Sample Answer
**Approach (why this structure works)** I split one-on-ones into short-term delivery, career growth, and personal well‑being so each meeting balances urgent work and long‑term investment. Consistent cadence and prep make them efficient and psychologically safe.**Reusable 1:1 Agenda (30–45 min)**1. Quick check-in (2–3 min) — mood, blockers, context 2. Delivery focus (10–15 min) — status, priorities, risks, decisions I need to make 3. Career & growth (8–10 min) — progress on goals, skills to practice, feedback, stretch opportunities 4. Roadmap & context (5–7 min) — product/tech updates, dependencies, stakeholder signals 5. Well‑being & workload (3–5 min) — bandwidth, burnout indicators, time off needs 6. Action items & recap (2 min) — who does what, deadlines, next steps**Cadence & prep**- Weekly for ICs on critical projects; biweekly for steady state. New hires weekly for first 8–12 weeks. - I ask reports to add 1–2 topics to a shared agenda before the meeting; I add mine. I read updates beforehand and bring decisions/answers to avoid wasted time.**What I track between meetings**- A shared tracker: action items, due dates, career goals, recent feedback, skill development plan, and blockers history. - I use PR/issue links for delivery context and update a simple status (Green/Yellow/Red). Before each 1:1 I review the tracker and add any follow-ups.**Outcome**This predictable, lightweight format preserves focus on delivery while ensuring continuous career support and wellbeing checks.
Conflict Resolution and Difficult ConversationsHardSystem Design
75 practiced
Design an organizational conflict-resolution governance model for a company with 20 product teams and 3 shared infrastructure teams. Include escalation tiers, a RACI for cross-cutting changes, decision authority for infra impact, meeting cadences, tooling or artifacts required, and KPIs to track governance health.
Sample Answer
**Brief framing / goals**Design a lightweight, auditable governance model that resolves cross-team conflict quickly, preserves team autonomy for local decisions, and centralizes decisions that materially affect shared infra or product experience.**Escalation tiers**1. Team-level: owning Product PM + Tech Lead — attempt technical/priority resolution within 3 business days. 2. Cross-team sync: involved Product Tech Leads + affected Infra Lead — meeting within 2 business days; aim resolution in 5 business days.3. Governance Board (weekly): Engineering Manager reps (one per product group), Head of Infra, Principal Architect, Product Leadership — decision within 3 business days of meeting.4. Executive Escalation: CTO/VP Eng — reserved for >48hr blocking outages, >$X cost, major security/regulatory impact.**RACI for cross-cutting changes**- Proposal author: Product Team Tech Lead — Responsible- Impact analysis: Infra Team Lead — Accountable- Reviews: Affected Product Tech Leads — Consulted- Approval: Governance Board — Responsible/Accountable for acceptance- Implementation: Implementing Team — Responsible- Communication/Docs: Release Manager/Technical Program Manager — Informed**Decision authority**- Local infra config/optimizations within team-owned boundaries: Product Tech Lead- Changes that modify shared infra (APIs, auth, cost > threshold, SLA changes): Infra Lead must sign off; Governance Board for conflicts or risk > threshold.- Architecture standards: Principal Architect owns standards; Board approves exceptions.**Meeting cadence / rituals**- Weekly governance board (30–60m) — triage escalations, approve RFCs- Bi-weekly cross-team syncs for active multi-team projects- Monthly postmortem review for infra incidents- Quarterly architecture review + roadmap alignment**Tooling & artifacts**- RFC + ADR repository (Git) for decisions- Ticketing system with escalation flags (Jira)- Decision log (searchable)- Runbooks + impact matrix for shared services- Dashboards: resolution SLAs, deployment stats (Grafana/Datadog)**KPIs to track governance health**- Median time to resolution by tier- Number of escalations per month (goal: downward trend)- Change Failure Rate for cross-cutting changes- % of RFCs approved within SLA- Stakeholder satisfaction score (quarterly survey)- Mean time to detect & remediate infra-impacting incidents**Example**A Product team proposes schema change affecting shared auth: Team-level review → Infra impact analysis (accountable) → Governance Board approves with migration window and rollback plan → decision recorded in ADR; metrics tracked (deployment success, incident count).This model balances fast local action with clear gates for shared risk, visible audit trails, and measurable health indicators.
System Design and Architecture FundamentalsHardSystem Design
79 practiced
As an Engineering Manager migrating notifications and reporting from synchronous REST to an event-driven architecture, outline incremental migration steps. Include dual-writing strategies, consumer contract evolution, managing data duplication, validating end-to-end correctness, and a plan to decommission old synchronous paths.
Sample Answer
**Overview / Goals**Migrate notifications & reporting from sync REST to event-driven incrementally with zero customer-impact, observable correctness, and clear rollback/decommission criteria.**Phased Migration Steps**1. Discovery & contracts - Inventory sync endpoints, producers, consumers, SLAs, payloads. - Define stable event schema and consumer-driven contract tests (Pact or similar).2. Dual-write & fan-out - Implement dual-writing at producer side: continue REST call + publish event to message bus behind a feature flag. - Use an adapter layer/service to encapsulate dual-write and retries, ensuring idempotency and at-least-once semantics.3. Consumer evolution - Start new event consumers for notifications and reporting reading from bus; initially they shadow behavior of sync flow. - Use consumer contract tests to validate event compliance continuously. - Introduce schema versioning and backward-compatible changes (additive fields, optional fields, version header).4. Data duplication & reconciliation - Accept temporary duplication: events + existing persistent state. - Build a reconciliation job (CDC or scheduled diff) to compare event-derived state vs sync-backed state; surface mismatches in dashboards. - Maintain canonical source-of-truth marker until cutover.5. Validate end-to-end correctness - Canary rollout: route a small % of live traffic to event path; run parity checks (metrics, counts, content). - Automated E2E tests simulating failures (out-of-order, retries). - Observability: business metrics, SLA latency, consumer lag, error rates, and reconciliation error trends.6. Cutover & decommission - Once parity thresholds met (e.g., 99.9% match over 48–72h, acceptable latencies), promote event path to primary for subsets, then all traffic. - Gradually disable dual-write feature flag; keep read-only sync endpoints for a grace period. - Final decommission when reconciliation shows zero/new acceptable drift and stakeholders sign off. Archive logs, remove contracts, retire infra.**Operational/Team Plan**- Cross-functional migration squad with producer, consumer, QA, and SRE.- Weekly milestones, clear rollback plans, runbooks for incidents.- Metrics-driven gating and stakeholder demos.**Risks & Mitigations**- Inconsistency: reconciliation + idempotent writes.- Contract drift: consumer-driven contract testing CI.- Latency/regression: canary + throttling.This balances engineering safety, visibility, and speed while giving teams safe rollback and clear decommission criteria.
