Senior Engineering Manager Interview Preparation Guide - FAANG Standards

Direct answer

I would split the work into three buckets: non-negotiable (the minimum scope the law and the deadline require, plus the evidence an auditor will ask for), delayed (valuable work that does not depend on this year), and dropped (work whose value does not survive the capacity cut). Then I give the business a plain price list in features and quarters, not an apology. Steps 1 to 3 below make the decision; the cases after them apply the same method.

Step 1: Establish what the regulation actually requires

Ask legal for a written reading that separates "must" (obligations and dates) from "should" (best practice). Gold-plating (building beyond what the rule requires) is how a one-year project becomes two. Treat the legal reading as an input, not as engineering's own interpretation.

Step 2: Capacity arithmetic (illustrative)

A 12-person team where the regulation needs 7.5 FTE (full-time-equivalent people) leaves 12 - 7.5 = 4.5 FTE, so compliance takes 62.5% of capacity. If 1.5 of the remaining 4.5 FTE go to keeping existing systems running, new product work is 3.0 FTE, or 25% of the original team.

Step 3: Sort the work

Scoring example (severity and likelihood each 1 to 5, illustrative):

The cleanup job looks low priority to product but scores 20, so it is protected first; the banner wording is a candidate to batch.

Applying the same method to common situations

• Conflicting requests on personal data. Legal wants data minimization (collect and keep only what you need), product wants analytics, sales wants customer-specific retention. Legal's mandatory constraints are fixed, and product and sales get the closest compliant alternative: aggregated data (totals, not individuals), anonymized data (identity removed), or opt-in (the user explicitly agrees).
• Region-specific legal rules. Build one configurable control, for example a data-location setting per region, instead of one code fork per region.
• High-value feature competing with compliance. Compare its dated revenue with the penalty and the delay risk of missing the deadline, and phase it behind the compliant core.

Quantify market entry

Entering a region that carries heavy compliance cost: compare expected gross profit (say $1.5M ARR, annual recurring revenue, x 80% margin = $1.2M per year once ramped) against the build (say 2 FTE x $200k = $400k) and an assumed ongoing audit burden of $200k a year. Net is $1.2M - $0.2M = $1.0M a year, so the build repays in about 0.4 years, roughly 5 months of ramped profit ($400k / $1.0M x 12 = 4.8). Entry is worth it on these numbers; delay it only if the ramp is slow or the compliance team cannot be spared this year.

Contingency for lost velocity (the amount of work the team ships per period)

Contractors help, but Brooks's law (Fred Brooks, 1975: adding people to a late software project makes it later) warns that new people need onboarding from existing staff. Assume 3 contractors deliver about half their capacity (1.5 FTE) in the first quarter and full capacity (3.0 FTE) later, and put them on well-bounded work, not on the critical path (the chain of tasks that sets the finish date). Phase delivery so partial compliance ships in quarter order.

Telling the business

Tell them in one page: what stops, what slows, what continues, when it returns, and what they could choose to trade back. Brief key customers before they hear it second-hand, and re-forecast every quarter.

Illustrative one-page price list, using the capacity arithmetic above: Stops: experiments with low confidence and nice-to-have refactors, for the full year. Slows: new product work falls to 3.0 FTE, 25% of the original team, so a feature set that took the whole team one quarter now takes about four quarters (1 / 0.25), before any help from contractors. Continues: keeping existing systems running (1.5 FTE) and features with a dated customer or revenue commitment. Returns: normal capacity in the quarter after the compliance deadline, re-forecast each quarter. Choice offered: the business can buy back capacity with contractors (about 1.5 FTE in the first quarter, 3.0 FTE later) or by narrowing the compliant scope the legal reading allows.

Direct answer

Give the startup a small set of measurable triggers, not a vibe: sustained traffic growth that vertical scaling can no longer absorb, a build or deploy pipeline slow enough to block multiple teams, incidents where one team's unrelated change repeatedly takes down another team's feature, and enough independent teams that they're routinely waiting on each other to ship. If none of those are true yet, stay on a well-structured monolith and invest in automation instead; splitting before any trigger fires adds real operational cost for a benefit the team can't cash in yet.

Structured elaboration

Triggers, with what each one actually signals

Default for an MVP-stage team
For a brand-new MVP with one or two engineers and no confirmed product-market fit yet, none of these triggers are even reachable: default to a single, well-organized modular monolith (one deployable codebase with clear internal module boundaries), because splitting now means guessing at service boundaries before there's usage data to draw them correctly, and redrawing a wrong boundary between two live services is far more expensive than redrawing it between two modules in one codebase.

When triggers do fire
Extract incrementally using the strangler pattern (pulling one bounded, high-value piece out from behind the existing interface at a time), named here without re-deriving its mechanics, and check that team structure already matches the boundary being proposed (Conway's Law, named only): if a small team doesn't already own the candidate service end to end, extracting it just relocates the coordination problem onto the network.

Worked example

A 25-person engineering org split into four product teams sees average deploy lead time climb past 45 minutes as all four teams queue behind one release train, and in the last quarter, three of nine production incidents were an unrelated team's change breaking a different team's feature through shared code. That's two of the four triggers above (deploy lead time, blast radius) firing at once, on an org that already has team boundaries to extract along (the third trigger). This combination, not any single signal alone, is what justifies picking one bounded, high-value capability, say the search or recommendations code, since it is already the most independently used and owned piece, as the first strangler-pattern extraction, rather than a big-bang rewrite of the whole system into services.

Trade-offs & pitfalls

• Extracting the first service based on which code is oldest or ugliest rather than which extraction actually relieves a measured trigger.
• Splitting without the operational maturity (CI/CD automation, monitoring, on-call ownership) to run more than one deployable thing, which adds cost with no offsetting benefit.
• Treating "we might need to scale eventually" as a trigger on its own; without a load number or a deploy-lead-time number attached, it's speculation, not evidence.
• What separates a senior answer: naming the first service to extract and why, based on a specific measured pain point, rather than describing microservices in the abstract.

Direct answer
An executive dashboard needs 6-8 metrics that translate directly into business risk without requiring engineering context to interpret: cycle time, build failure rate, test coverage, mean time to recovery, bug escape rate, and deploy frequency, each with a plain-language "why this matters" and a threshold that means "needs attention now."

Structured elaboration

Add two more only if they map to a specific business concern this quarter, for example incident count (if reliability is the current executive focus) or dependency-freshness (if security/compliance is the current focus); resist the urge to include every available metric, since a crowded dashboard defeats the purpose of an executive-facing view.

Worked example
A quarterly executive review shows deploy frequency down 30% and bug escape rate up 20% over the same period, both crossing their concern thresholds simultaneously. Presented together, these two numbers tell a coherent story ("we're shipping less, and what we do ship has more defects") that a single metric alone wouldn't convey as clearly, and it directly motivates the capacity-allocation ask without requiring the executive to understand cyclomatic complexity or test architecture.

Trade-offs & pitfalls
The pitfall specific to this audience is presenting metrics without translating WHY each matters in business terms; an executive dashboard that just relabels an engineering dashboard still requires the same context to interpret. A second pitfall: setting thresholds too sensitively, so the dashboard cries wolf every sprint and executives stop trusting it exactly when it matters most.

Direct answer

I state the role's purpose in one sentence tied to a business outcome, not a task list ("this role exists to make sure the product team can trust the numbers they're making decisions on," not "this role does dashboards and SQL"). Then I pick three 30-day priorities that each map back to that purpose: usually one is about understanding the current state well enough to be trusted, one is a concrete early contribution that proves competence, and one is a relationship or process gap that would otherwise slow everything down later.

Structured elaboration

• The "why those three" test. Does each priority map to the stated purpose? Would skipping it create a bigger cost later than doing it now? Is it achievable with the access and trust I'll realistically have in 30 days?
• What I deliberately leave out. Deep technical debt and big strategic bets usually need more context and more trust than a first month provides. Tackling them too early risks confidently solving the wrong problem.
• Sanity-checking against expectations. I compare my three against what my manager and my skip-level (my manager's manager, one level above my direct manager) actually expect, because what I would prioritize and what leadership assumes I'm prioritizing can quietly diverge. That gap is one of the more common reasons a strong first quarter still reads as disappointing.

Worked example

Joining as a Product Manager on a struggling onboarding flow, I'd frame the role's purpose as "get more new users to their first meaningful action, faster." My three priorities: first, spend two weeks instrumenting and understanding the actual drop-off funnel, since I can't trust the existing dashboard's definitions yet; second, ship one small, low-risk change we can measure within 30 days, to prove I can move the metric, held to what that window can honestly support: two weeks of instrumentation leaves about sixteen days to build, ship and read a result, so I run it as a split against a holdout rather than a before-and-after, because the "before" period was measured on the funnel definitions I have just replaced, and comparing across that change measures my instrumentation rather than my fix. If new-user volume is too low for a split to separate the effect from noise inside sixteen days, I say that up front and present the day-30 number as directional, with the honest read scheduled for day 60, rather than claiming a causal win that a marketing push, a pricing test or a seasonal dip would explain just as well; third, set up a recurring sync with the three most affected teams (support, growth, engineering), since that coordination gap was previously slowing every prior fix. I would explicitly not touch the pricing page redesign that's been discussed for months, because it needs more organizational buy-in than 30 days of trust can generate.

Trade-offs and pitfalls

Choosing priorities that are all "learning" tasks with no visible output looks passive to stakeholders watching for signal; choosing all "shipping" tasks with no listening phase risks confidently fixing the wrong thing. The failure this question exists to catch is a candidate who lists three generic activities (meet people, read docs, ship something) with no connection back to why the role exists in the first place.

Direct answer

Interrupt the blame in the moment by redirecting the question itself, from "who caused this" to "what about our systems and process let this happen", and say it out loud as an explicit redirect rather than just steering the conversation quietly. A room that's turned adversarial needs to hear the norm restated, not just have it enforced silently.

Structured elaboration

This is the core discipline of a blameless postmortem: separate the person who made a change from the system that allowed that change to cause an outage.

1. Interrupt explicitly: pause and name what's happening ("we're drifting into blaming a person, let's get back to what let this happen") rather than letting it continue and hoping it self-corrects.
2. Redirect to the timeline and evidence: logs, timestamps, the sequence of what happened, not opinions about who should have known better. Facts are hard to argue with; character judgments are not.
3. Reframe the specific accusation as a systems question: "the config was wrong" becomes "what let a config like that reach production without being caught," which is a question about review process, tooling, or guardrails, not about the individual.
4. If the tension is genuinely personal, not just heat-of-the-moment, take it offline: tell the room you'll follow up with the two people individually, and actually do it. Don't let "we'll talk later" become a way to avoid an uncomfortable moment.
5. Convert the discussion into specific, owned action items before the meeting ends, so the room leaves with something concrete instead of residual tension.

Worked example

In a post-incident review for an outage caused by a misapplied configuration change, one engineer says, in front of the group, "this happened because Sam pushed a config change without checking it." Sam gets defensive and the exchange starts to escalate. You interrupt: "let's park who pushed it and look at the path it took to reach production, config change, review, deploy, what step should have caught this?" That question can't be answered with blame, only with a description of the pipeline, and it surfaces that there was no required second reviewer for that config path, which is the actual fixable thing. After the meeting, you check in with both engineers individually, since even a well-handled public moment can still leave one person feeling singled out.

Trade-offs and pitfalls

• "Blameless" can drift into "consequence-free" if repeated carelessness never gets addressed anywhere. That conversation still needs to happen, just privately and separately from the incident review, framed around the pattern, not the incident.
• Interrupting too gently, a soft "let's stay positive," often doesn't land as a real redirect. It needs to be specific enough that everyone in the room understands exactly what changed.
• Redirecting to systems can become a way to avoid ever naming that a specific action needs to change, which trades honesty for comfort.
• If you personally have a stake in the outcome, it was your team, your call, your redirect can read as protecting your own team rather than the process. Bringing in someone more neutral to facilitate is sometimes the better call.

Situation: On one project, engineering and design were operating in separate lanes, which caused late feedback and rework.

Task: I needed to rebuild trust and unblock delivery without turning the problem into a blame conversation.

Action: I set up joint working sessions where both teams reviewed the same problem statement and success criteria. I also introduced a shared definition of done so we were clear about what “ready” meant before handoff. To build trust, I made sure both sides had equal airtime, captured decisions in writing, and followed through on small commitments quickly. After that, I kept the collaboration healthy with regular check-ins, shared demos, and a single place to track open questions.

Result: The teams started catching issues earlier, handoffs became smoother, and there was less tension around ownership. The biggest lesson was that silos break down faster when people share context and make small reliable commitments over time.

Direct answer

A good multi-year vision for an engineering, data, product or cloud organization says who it serves, what will be true for them in about three years, and what the organization will deliberately not do. You can tell a real one from a slogan because it forces a choice, a team can use it to settle a disagreement, and a year later you could tell whether you moved toward it. A slogan could be pasted onto any competitor's slides.

Vocabulary

• A vision is a description of the future you intend to create, and why it matters.
• A slogan is a phrase that sounds right but does not tell anyone what to do.
• A platform team builds shared tools that other teams use to ship their own work.
• SRE (site reliability engineering) is the discipline of keeping live services up and fast; reliability targets are agreed numbers for that, such as "99.9% of requests succeed".
• On-call means being the engineer who is paged first when a live service breaks; an escalation path is the agreed route to the next person when the first responder cannot fix it.
• Governed self-serve data means data that is documented and access-controlled, so teams can use it themselves without asking a data team for each request.
• A bespoke pipeline is a custom-built data feed made for one team only. A compliant workload is an application that already meets the company's security and regulatory rules.

The four tests

1. Choice test. Does it rule something out? If every project can claim to serve it, it guides nothing.
2. Competitor test. Could a rival org say the same sentence? If yes, it is generic.
3. Decision test. Hand it to two teams with a conflict between two projects. Does it help them pick?
4. Evidence test. In a year, could you point to something observable that shows progress (or not)?

Slogan versus vision (illustrative)

Each real vision names who benefits, what changes, and one thing it gives up.

What else a real one contains

• A first-year picture so the three-year horizon is not abstract.
• Two or three principles that guide trade-offs.
• A few ways to see progress, without turning into a metric list.

Trade-offs and pitfalls

• A vision can be too specific (naming a tool that may be obsolete in two years). Aim for a customer outcome, not a technology.
• A vision can be right on paper and unused. Test by asking engineers to restate it and to name a decision it changed.
• Avoid inspirational filler. If a sentence would survive deletion without anyone noticing, delete it.

Direct answer

I weigh a short list of signals against each other: what the team or product genuinely needs next, where I'm personally the bottleneck, how durable the skill is versus how much of its appeal is short-lived hype, how long it'll take to become useful, and how it fits where I want to grow longer-term, then I deliberately resist just picking whatever happens to be most interesting that week.

Structured elaboration

The signals, roughly in the order I actually weigh them: what's genuinely needed next (not hypothetically useful, but blocking something soon); where I am the bottleneck versus where someone else already covers it; durability, since a skill built on something likely to be replaced in a year pays off less than one that generalizes; time to first usefulness, since a skill that takes six months to pay off is a different bet than one that pays off in a week; and longer-term direction, since some choices compound toward where I want to be in a few years and some don't.

If I use anything like a scoring approach across those signals, I keep it as a judgment aid, not a formal weighted-matrix exercise. Reducing this to a spreadsheet score tends to manufacture false confidence in what's actually a judgment call.

There are times the right answer is to learn nothing new and go deeper on current work instead, particularly when the team's actual bottleneck is depth in something I already do, and picking up something new would just be more comfortable than admitting that.

Worked example

Recently I had to choose between going deeper on Airflow, the batch-orchestration tool I already ran our nightly pipelines on, or picking up event-driven stream processing, an adjacent area I'd never worked in that a few upcoming projects seemed likely to lean on. I weighed it using the signals above: streaming wasn't blocking anything yet, so it scored low on "genuinely needed next," but it scored high on durability and on long-term direction, since it was a skill I expected to matter regardless of which specific project used it. I chose to learn streaming. In hindsight, my durability read was mostly right, but I underestimated how long it would take to become useful: I expected a project to need it within a couple of months, but it was closer to eight months before a fraud-detection feature actually required near-real-time signals instead of our usual nightly batch, so it paid off later than I expected, which is worth reporting honestly rather than pretending the choice was cleanly validated on schedule.

Trade-offs and pitfalls

The common failure mode is turning this into a rigid scoring exercise that produces a false sense of objectivity about what's ultimately a judgment call. The opposite failure is always chasing whatever's currently getting the most attention under the label of "future-proofing," without actually checking it against need or durability.

Direct answer

For a workflow spanning around 30 services, the real choice is not orchestration versus choreography as a single binary decision for the whole workflow; it is which steps need a component that can prove ordering and drive compensations (orchestration), and which steps can react to events with no central authority at all (choreography). Orchestration puts one coordinator in charge of calling each step and firing compensations in a known sequence; choreography has each participant publish an event when its own step completes and react to others' events, with no single place holding the overall plan.

Orchestration

A coordinator persists the saga's state as an explicit record (an event-sourced log or a saga_state table with a status per step), calls each participant directly, and on a failure at step k issues compensating calls for steps 1..k-1 in reverse order. Because the plan lives in one place, ordering and auditability are straightforward to reason about; the coordinator itself must be made durable and, typically, run as a small number of replicas, since it is now a component the whole workflow depends on.

Choreography

No coordinator exists. Participant N completes its local step and emits a domain event; participant N+1 subscribes to that event and reacts; a failure is just another event (e.g. ShippingFailed) that any interested participant can subscribe to and use as its own trigger to compensate. This removes the central dependency but means "what state is this workflow in" is a property of the whole event graph rather than one component's state, which is harder to reconstruct when debugging.

Compensating actions

A compensating action is the business-meaning inverse of a step, not a literal undo: refunding a settled charge is not "un-charging" it, and cancelling a shipped order needs a return flow, not a rollback. Compensations must be idempotent (safe to invoke more than once with the same effect), because a coordinator restart or a redelivered event can cause the same compensation to be issued twice.

Idempotency of each step

Every forward and compensating action is invoked with a natural key, typically (saga_id, step), that the receiving service stores alongside the resulting effect. If the same key arrives again, the service returns the already-recorded result instead of re-applying the effect (charging twice, releasing stock twice). This is what makes it safe for either a restarted orchestrator or a redelivered choreography event to retry a step it cannot be sure completed.

Detecting and recovering a mid-protocol crash

Orchestration: the coordinator's saga state is durable, so on restart it scans for sagas stuck in an in-flight status past an expected time bound, reads the last completed step from that record, and resumes forward execution or begins compensation from there. Because every action is idempotent, resuming is safe even in the worst case (crash after a participant executed but before the coordinator recorded it): the only possible cost is one duplicate no-op call.

Choreography: there is no single resume point. Each participant instead needs its own local timeout: for example, the inventory service reserves stock with an expiry, and if it never receives a downstream "payment confirmed" event within that window, it independently emits its own "reservation expired" event to trigger compensation across whatever already acted. Detecting "stuck" is decentralized and has to be designed per-participant rather than once, centrally.

Worked example: order O-500 across Payment, Inventory, Shipping

Orchestration trace:

sequenceDiagram
    participant C as Coordinator
    participant P as Payment
    participant I as Inventory
    participant S as Shipping
    C->>P: charge(step=1)
    P-->>C: success
    C->>I: reserve(step=2)
    I-->>C: success
    Note over C: crash before calling Shipping
    Note over C: restart, reads saga_state
    C->>S: schedule(step=3)
    S-->>C: fail
    C->>I: release(step=2)
    C->>P: refund(step=1)

1. saga_state(saga_id=S-500, step=1, status=STARTED).
2. Coordinator calls Payment.charge(saga_id=S-500, step=1, key=S-500:1); succeeds; saga_state updated to step=1, status=DONE.
3. Coordinator calls Inventory.reserve(saga_id=S-500, step=2, key=S-500:2); succeeds; saga_state updated to step=2, status=DONE.
4. Coordinator crashes before calling Shipping (step 3).
5. Coordinator restarts, reads saga_state for S-500: last DONE step is 2, step 3 was never started, so it resumes at step 3 and calls Shipping.schedule(saga_id=S-500, step=3, key=S-500:3).
6. Shipping fails permanently (undeliverable address).
7. Coordinator runs compensations in reverse for the completed steps: Inventory.release(saga_id=S-500, step=2), then Payment.refund(saga_id=S-500, step=1).
8. If the coordinator crashes again mid-compensation and retries Inventory.release(step=2) a second time, Inventory recognizes the key S-500:2 was already applied and returns the recorded result instead of releasing stock twice.

Choreography, same scenario: Payment emits PaymentCharged(S-500); Inventory, subscribed to it, reserves stock and emits InventoryReserved(S-500); Shipping, subscribed to that, tries to schedule and fails, emitting ShippingFailed(S-500); Inventory and Payment, both subscribed to ShippingFailed, independently run their own compensations on receiving it. If Shipping crashes before ever publishing ShippingFailed, no coordinator exists to notice the gap; Inventory only recovers because its own reservation carries a TTL (time-to-live, an expiry after which it self-cancels; say 15 minutes), and on expiry with no follow-up event it self-triggers its own compensation.

Trade-offs & pitfalls

A common pitfall is writing a compensation that isn't actually the semantic inverse of the forward action, which produces a technically-completed rollback that is still wrong for the business. In practice, a workflow like this is often a hybrid: strict, auditable steps (payment, billing) run under orchestration because ordering matters and correctness is expensive to get wrong, while more tolerant downstream steps (inventory, shipping) are choreographed since they are naturally eventual and cheaper to compensate if something goes wrong.

Assumptions to document

State every load-bearing assumption explicitly before building the roadmap: 30% year-over-year user growth held constant across the full 3 to 5 year horizon (a strong assumption, real growth curves usually decelerate, flag this the same way you would for any multi-year compounding projection), traffic-per-user held roughly constant (or explicitly modeled separately if usage intensity, like video, is trending up faster than headcount, a common miss for network capacity specifically), and the peak-to-average traffic ratio used to translate user growth into provisioned capacity, since network circuits are sized for peak, not average.

Worked out, a constant 30% YoY rate compounds fast:

for years in [3, 5]:
    print(f"1.30^{years} = {1.30**years:.1f}x")

1.30^3 = 2.2x
1.30^5 = 3.7x

Which is why holding that single rate constant for the full horizon needs to be flagged explicitly rather than trusted as-is.

Scenario planning for growth uncertainty

Build named scenarios rather than one number, for example conservative, base, and aggressive growth rates bracketing the 30% figure. Commit near-term, hard-to-reverse decisions (this year's circuit orders) to the base case, while keeping later years' commitments as a range with defined trigger points, so the roadmap can flex without having to be rebuilt from scratch if actual growth lands outside the base case.

Procurement cadence for circuits and appliances

Network hardware and circuits have long, often multi-month lead times, circuit installation especially in geographies without existing fiber, and appliance procurement and deployment. The roadmap's real output is a trigger date for each procurement action: start the order when the forecast crosses (current capacity - lead_time_worth_of_growth), not when capacity is actually exhausted, because by the time you're out of headroom it's already too late to order more.

Capacity headroom targets

Because rebuilding network capacity once installed is slow, carry a real percentage buffer above the forecasted peak rather than sizing exactly to it, larger near-term (where you're already committing capital) and can stay a wider range further out where you're mostly setting expectations rather than placing orders yet.

Communicating uncertainty and contingencies to leadership

Present the roadmap as a range with explicit trigger points tied to action: "if growth exceeds the base case by some threshold by a given quarter, the accelerated buildout contingency activates," and attach the dollar and lead-time cost to each named scenario so leadership can see the cost of both over- and under-provisioning, not just a single "trust us" number. Set a recurring re-forecast cadence, quarterly is typical for network capacity given its lead times, to true up the roadmap against actual growth rather than treating a multi-year plan as fixed once approved.