DoorDash Senior Software Engineer Interview Preparation Guide

Decision Memo Outline — Consolidate 20 Internal Services into a Platform-Managed Library

1. Executive Summary

• Purpose, scope, target timeline (18 months), high-level recommendation (phased consolidation to a platform library with optional adapters).

2. Benefits (quantified)

• Reduced duplication: eliminate ~20 codebases → reduce maintenance by estimated 40% (FTEs)
• Faster feature delivery: common SDK reduces onboarding by 30%
• Consistency/security: single vetted implementation reduces vulnerabilities and runtime bugs by X%
• Operational savings: lower infra & CI costs; estimate 20–35% reduction.

3. Risks & Mitigations

• Risk: Breakage / API incompatibility → Mitigate: compatibility layer, semantic versioning, automated migration tests, canary rollouts.
• Risk: Single point of failure / bottleneck → Mitigate: decentralised runtime libs, robust SLAs, performance budgets.
• Risk: Org resistance → Mitigate: stakeholder working groups, migration incentives.

4. Migration Plan (phased)

• Phase 0: Discovery — inventory, usage map, dependency graph (4–6 weeks).
• Phase 1: Core library + docs + adapters for top 5 consumers (3 months).
• Phase 2: Pilot migrations (2 teams, 2 months).
• Phase 3: Bulk migration with CI automation, deprecation windows, and rollback plans (6–9 months).
• Phase 4: Sunset of legacy services and monitoring (2 months).

5. Cost Estimates

• One-time: engineering (X FTE-months), documentation, training, CI work (~$A)
• Ongoing: platform maintenance (Y FTEs), support rotation
• Expected payback: N months via reduced maintenance + infra savings

6. Governance & Ownership

• Platform team owns core library, release cadence, security, SLAs.
• API Council (cross-functional): approves breaking changes, roadmap prioritization.
• Contribution model: RFCs, code owners, clear deprecation policy, automated compatibility checks.

7. Success Metrics

• Technical: % clients migrated, reduction in duplicated LOC, mean time to update client (MTTU), runtime error rates.
• Business: engineering hours saved, time-to-market for dependent features.
• Developer Happiness: NPS/weekly sentiment surveys, onboarding time, number of support tickets per release.

8. Next Steps

• Approve discovery phase budget, appoint platform lead, schedule stakeholder kickoff.

Appendices: inventory sample, cost model spreadsheet, migration checklist, sample SLA and semantic versioning policy.

GOAL:
Provide a thread-safe, performant LRU cache for high concurrency on mobile.

DESIGN OPTIONS:

1. ConcurrentHashMap + Doubly-linked LRU list with locks

• Use ConcurrentHashMap for storage and maintain an LRU list protected by a small lock (or ReentrantLock). On access, update list under lock.
• Pros: simple, good concurrent read; Cons: LRU updates still bottlenecked by single lock under extreme write-heavy workload.

2. Segmented (striped) cache

• Partition keys into N stripes (shards). Each shard has its own HashMap + LRU list and lock. Map key → shard by hash.
• Pros: reduces contention, preserves near-LRU per-shard; Cons: global LRU is approximate.

3. Lock-free read path + write serialization

• Use ConcurrentLinkedHashMap pattern—atomic references for nodes and CAS updates (complex to implement). Prefer libraries if available.

MEMORY PRESSURE HANDLING:

• Maintain cache size by byte/entry count; evict LRU entries on insert.
• Hook into OS memory pressure callbacks to aggressively trim cache.
• Use soft/weak references carefully (Android GC can reclaim unexpectedly).

TESTING APPROACH:

• Unit tests for correctness (put/get/evict) and invariants.
• Concurrency stress tests using ThreadPool executor that simulates heavy concurrent gets/puts and verifies no corruption and total size constraints.
• Fuzz tests to randomize operations and compare with single-threaded reference LRU.
• Use race detectors / thread sanitizers in debug builds where possible.

RECOMMENDATION:

• Use segmented cache (e.g., 16 shards) with ConcurrentHashMap per shard and a simple lock-protected LRU list per shard. This balances performance and implementation complexity while giving predictable evictions and low contention.

ADDITIONAL:

• Consider using an existing tested library (Caffeine for Java) adapted for mobile if acceptable. Instrument metrics for hit/miss rate and lock contention.

Direct answer

Start by confirming the page's own signal is real and getting a fast read on customer impact, then check the most likely and cheapest-to-rule-out causes first (a recent deploy, a dependency, resource saturation) before diving into deep investigation, and mitigate toward reducing customer harm even before you fully understand the root cause.

Structured elaboration

A useful way to organize the first 15 minutes is in three phases: confirm and scope (roughly the first 2-3 minutes), cheap-hypothesis triage (the next 5-7 minutes), and mitigate-or-escalate (whatever time remains in the window). Concretely, that is ten actions:

Confirm and scope (minutes 0-3)

1. Check that the alert reflects reality, not a monitoring artifact: a quick look at raw request logs or a second, independent metric source.
2. Get a rough read on customer impact: is this affecting all traffic to the service or a narrow slice, one region or all of them, since that shapes how urgently the next steps need to move and whether to loop in anyone beyond yourself yet.

Cheap-hypothesis triage (minutes 3-10), in order of how fast each is to check and how often it explains a sudden spike like this
3. Check whether there was a recent deploy or configuration change to this service (a deploy dashboard or recent-changes log takes seconds to check and explains a large fraction of sudden regressions).
4. Check whether a dependency this service calls is showing its own elevated errors or latency, from that dependency's own dashboard if one exists.
5. Check whether the service itself is resource-saturated (CPU, memory, connection pool exhaustion, disk), from the same dashboards you'd already have open for the service's own health.
6. Read the service's own error logs for the actual error messages, which often point directly at the cause: a specific exception type, a specific downstream call failing.
7. Correlate timing: does any of the above (a deploy, a dependency's own alert, a saturation metric) line up closely with when the spike actually started.

Mitigate or escalate (minutes 10-15)
8. If a recent deploy correlates closely with the spike's start time, roll it back, usually the fastest safe mitigation, even before fully understanding WHY the deploy caused the regression, since a rollback returns you to a state you already trust.
9. If no clear single cause emerges within this window, shift priority to containment: reduce customer impact through some means, like shedding non-critical load or failing over a slice of traffic, while continuing investigation.
10. Escalate: loop in another engineer or the service's on-call/owning team if you are not making progress alone, rather than continuing to investigate solo well past the point where a second perspective would help.

Data sources to check first, roughly in this order: the service's own error logs (the actual error messages, which often point directly at the cause), a recent-deploys/changes dashboard, the service's resource-utilization dashboards, and the dashboards of its immediate upstream dependencies. Deprioritize deep distributed-tracing investigation for the first 15 minutes unless the above cheap checks come up empty, since tracing analysis is valuable but slower, and the goal in this window is triage and containment, not full root-cause diagnosis.

Worked example

Minute 0-2: the page fires; a quick check of raw request logs confirms 5xx responses really are elevated for Service A, not a monitoring glitch, and a fast look at traffic-by-region shows it is affecting all regions roughly equally, not a localized issue. Minute 2-5: checking the deploys dashboard shows a deploy to Service A landed 4 minutes before the spike began, a strong correlation. Minute 5-8: cross-checking Service A's error logs shows the actual exceptions are all coming from one specific code path that lines up with what the deploy changed, corroborating the deploy as the likely cause rather than coincidence. Minute 8-10: given the strong correlation and corroborating error signature, the deploy is rolled back. Minute 10-15: the 5xx rate is monitored closely post-rollback; it begins dropping within 2 minutes and returns to baseline by minute 15, confirming the rollback was both executed correctly and actually addressed the cause, at which point the incident moves from active mitigation into stabilization and eventual root-cause writeup, rather than closing the moment the rollback command was issued.

Trade-offs and pitfalls

The ordering above (cheapest, most-likely hypotheses first) is a heuristic, not a guarantee, and the real pitfall is getting anchored on the first plausible-looking correlation (the recent deploy) without a quick corroborating check (the matching error signature in the worked example) before acting; rolling back a deploy that turns out to be innocent both fails to fix the real problem and costs the time the rollback itself took. The other common failure mode in a genuine first-15-minutes window is spending all of it on deep investigation without ever mitigating, when a fast, reasonably-confident containment action taken at minute 10 is usually worth more to affected customers than a fully-certain root cause found at minute 25.

Direct answer
For a decade-old, high-scale monolith, the recommendation is rarely "stay monolithic" or "go fully microservices"; it's a targeted decision framework that identifies the specific parts of the system whose independent scaling or independent team ownership is actually costing the business money today, extracts those first, and leaves the rest alone until it earns the same treatment. Presenting it as an all-or-nothing rewrite is both riskier (a full rewrite of a decade of business logic is a multi-year, high-failure-rate project) and usually unnecessary, since most of the pain in an aging monolith concentrates in a handful of hot spots.

Structured elaboration
The decision framework has four legs:

• Technical: which modules have the sharpest scaling mismatch with the rest of the system (a payment-authorization path handling 100x the load of an admin screen, for example), and which modules have accumulated the most operational risk (frequent incidents, long deploy times, brittle test suites)?
• Organizational: which modules are owned by teams that are actively blocked on each other's release schedule, versus modules nobody has touched in years and that carry no coordination cost today?
• Operational: what's the current cost of a full-monolith deploy (build time, test-suite time, blast radius of one bad change) compared to what a partial extraction would cost to build and run?
• Business: what's the actual dollar or reliability cost of the status quo (missed SLAs, engineer-hours lost to slow deploys, revenue at risk from an outage in a hot path) versus the cost and risk of a migration?

Given those four inputs, the framework picks a minimal-viable first split: the one or two modules where the technical, organizational, and business signals all agree, rather than the module that is merely easiest to extract technically. A concrete growth target, such as an expectation of reaching roughly a billion monthly users, sharpens the technical leg specifically: it tells you which modules are within striking distance of hitting a real scaling wall at that volume (and therefore belong near the front of the queue) versus modules whose load profile stays comfortably flat regardless of how large the user base gets.

Worked example
For a ten-year-old payments monolith, a realistic first split is the fraud-scoring path if it independently spikes under promotional traffic and is owned by a distinct team from the rest of checkout, even though other parts of payments (refunds, reporting) stay in the monolith for years longer. The migration plan for that one path covers: strangling the fraud-scoring code path behind a routing layer, standing up the new service against a read-only copy of the data it needs, dual-running it against production traffic to compare outputs before cutting over, and only then removing the old code path. Rough cost and velocity estimates come from the extraction size (lines of code, number of database tables touched, number of consuming call sites) rather than from the size of the whole monolith.

Trade-offs and pitfalls
The scenario where staying monolithic is still correct is a module with low change frequency, no independent scaling need, and a single owning team: extracting it produces the operational cost of a new service (deploy pipeline, monitoring, on-call surface) with none of the benefit. The most common failure mode in these efforts is scope creep, where a targeted first extraction turns into "let's redesign the whole payments platform," which reintroduces the risk of the big-bang rewrite this framework exists to avoid; the discipline of picking the smallest split that clears the bar on all four dimensions is what keeps the migration low-risk.

Direct answer

I distinguish by pattern, not just output level. Burnout or disengagement usually shows up as a broad decline across previously strong areas, paired with a real change in energy or affect (a person's visible mood and emotional expression). A skill gap is usually narrower, tied to a specific type of task, and doesn't come with that affect change. Once burnout is suspected, the shift is from output-focused coaching to a wellbeing-first conversation and workload adjustment.

Distinguishing signals

The diagnostic move

Because the same output pattern (missed deadlines, lower-quality work) can come from either cause, guessing from behavior alone risks the wrong intervention. More skill-focused coaching aimed at someone who's actually burned out just adds pressure. The reliable move is to ask directly and non-accusatorially rather than only inferring, since it's the fastest way to tell the two apart.

What to do differently once suspected

Shift the conversation from task correction to workload and wellbeing. Reduce scope or redistribute urgent items in the short term rather than expecting normal output immediately. Check in more on process and how they're doing than on deliverables for a while. Point toward available support resources where they exist. Avoid escalating straight to a formal performance conversation while this is unresolved, but also avoid treating it as an indefinite excuse, set an actual review point to reassess rather than letting it run open-ended.

Worked example

A mentee whose work had been consistently strong started slipping across several unrelated tasks, not just one. The decline was recent and came with noticeably less participation in discussions, which pointed away from a narrow skill gap. A direct, private conversation surfaced an unsustainable workload building up over recent weeks. The short-term adjustment was reprioritizing their task list and explicitly deprioritizing anything non-urgent, with a check-in scheduled two weeks out to see whether things had actually improved rather than assuming they had.

Trade-offs and pitfalls

A common mistake is treating every dip in output as a skill or effort problem and escalating straight to a formal process. The stronger approach separates "can't" (skill), "won't" (motivation or disengagement), and "can't sustain right now" (burnout), because they call for different responses, while staying alert that a genuine performance issue can coexist with real burnout, one doesn't automatically rule out the other. It's also a pitfall to assume burnout excuses declining output indefinitely: there still needs to be a check-in cadence, and if it doesn't resolve, it may need to go beyond what a mentor alone can fix, involving a manager or people-ops rather than absorbing an open-ended situation solo.

Direct answer

Assume temporary coordination authority, not decision authority you do not have: pull in the specific people who can actually resolve the blocker, make only the calls that are reversible and fully inside your own component, and explicitly flag anything that changes another team's commitments or a customer-facing date to a real decision-maker, even if that means the release slips.

Structured elaboration

1. Identify exactly what is blocking the release and who has the context or authority to resolve it; this is usually a specific person on another team, not 'leadership' in the abstract.
2. Assume coordination authority: convene the right people, set a timebox, and drive the discussion to a decision, without unilaterally deciding something that is not yours to decide, such as another team's interface contract or a customer commitment.
3. What is safe to decide alone: reversible calls fully inside your own component, a config value, an internal implementation detail, delaying your own team's non-customer-facing sub-task.
4. What is not safe to decide alone: anything that changes a cross-team interface, a customer-facing date, or commits another team's time or budget; escalate these, even informally, to whoever holds that authority, a peer lead, a skip-level, or the manager via a quick async message even while officially out.
5. Document and hand off: leave a clear written trail of what was decided, by whom, and why, so the manager can review it on return instead of reconstructing it from memory.

Worked example

A release is blocked because a downstream team's interface contract needs a field renamed, and that team's lead is the only person who can approve it, with the manager unreachable. The feature owner convenes a 15-minute call with the downstream lead and the engineer best placed to make the change, timeboxes the discussion, and gets an approved change within the hour. They unilaterally decide to delay their own team's internal cleanup task, fully inside their own scope and reversible, to free up the engineer for the fix, but they do not unilaterally decide to slip the customer-facing release date; instead they flag the realistic new timeline to the product stakeholder for that person's call, and leave a written summary of what happened for the manager.

Trade-offs and pitfalls

A common wrong turn is treating 'my manager is out' as license to make any call that feels urgent, including ones that touch another team's commitments or a customer date; that is overreach dressed up as initiative. The opposite failure is freezing and waiting until the manager is reachable, which stalls the whole release for a decision that did not need to wait. The right scope is narrower than it feels under pressure: coordinate broadly, decide narrowly.

Direct answer. Add a thin safety net first (characterization tests around the highest-risk paths), then make the smallest behavior-preserving changes that let you keep shipping features on top of a codebase that's incrementally getting safer -- never stop feature delivery to do a big-bang rewrite.

A pragmatic, incremental plan

1. Triage by risk, not by ugliness: use bug/incident history and traffic volume to find which parts of the codebase actually cause production pain, rather than starting with whatever looks messiest to the eye. That's where safety-net investment pays off fastest.
2. Characterization tests around the riskiest, most-touched code first: pin current behavior before changing anything there, so the very next change (a bug fix someone was going to make anyway) has a safety net.
3. Introduce seams for testability opportunistically: when you're already touching a function for a bug fix or small feature, take the extra step to extract its logic behind a seam (dependency injection, a wrapper around a hard-to-test dependency) rather than scheduling a separate 'add tests' project that competes with feature work indefinitely.
4. Establish a ratchet, not a rewrite: a simple rule like 'code you touch must leave with equal or better test coverage than it had' compounds over months without ever requiring a stop-the-world effort.
5. Fix bugs as they're found, but track root causes: if the same TYPE of bug (e.g., null handling) recurs, that's a signal for a small, targeted structural fix (a value type, a validation layer) rather than continuing to patch individual symptoms.
6. Communicate progress in business terms: incident rate trending down, cycle time on bug fixes shrinking -- so the ongoing investment stays visible and defensible against pressure to 'just ship features.'

Why NOT a big rewrite

A rewrite requires understanding the FULL current behavior (including undocumented edge cases relied on by real users) well enough to reproduce it exactly, which is precisely the thing 'frequent production bugs and no tests' tells you the team does NOT currently have -- the rewrite would be built on the same uncertain understanding that caused the bugs in the first place, at much higher risk and with a long period of zero feature delivery.

Trade-offs and pitfalls

• This plan trades a fast dramatic fix for a slower, compounding one; if leadership expects a visible turnaround in weeks rather than months, be explicit up front about that mismatch rather than overpromising a timeline the approach can't deliver.
• The 'ratchet' rule needs actual enforcement (a CI coverage-delta check, or review discipline) or it silently stops being followed the first time a deadline gets tight -- decide in advance whether it's a hard gate or a norm, and be honest that a norm alone often erodes under pressure.

Direct answer
Open with the headline status (on track, at risk, or blocked), then give the reader exactly what changed since the last update, what you need from them if anything, and by when, in that order.

Structured elaboration

1. Headline status first, as an explicit word, not something the reader has to infer from the tone: "on track," "at risk," or "blocked." This lets a reader triage in two seconds whether they need to read further.
2. What changed, briefly: the one or two things that happened since the last update that the reader doesn't already know.
3. What you need, if anything, stated as a specific, actionable ask rather than a vague mention of a problem. If there's nothing needed, say so, so the reader isn't left wondering whether an ask is buried in the update.
4. By when. A specific date or milestone anchors the ask; "soon" is not a deadline.
5. Keep it to a few sentences. A status update that's long enough to require its own summary has failed at being a status update.

Worked example
"Status: at risk. The vendor integration is behind because their sandbox environment has been down for two days; no ETA from them yet. I need someone with an existing vendor contact to escalate on our side, since my usual contact hasn't responded since Monday. If we don't get sandbox access back by Thursday, this pushes our launch date by roughly a week."

Headline status stated explicitly, what changed (vendor outage) stated in one clause, a specific ask (escalate via a different contact) instead of a vague complaint, and a concrete deadline and consequence tied to it.

Trade-offs and pitfalls

• Burying "at risk" or "blocked" inside a paragraph of otherwise neutral-sounding detail is the single most common failure; a reader skimming quickly can miss it entirely if it's not the first word.
• Overusing "at risk" as a reflexive hedge, when things are actually fine, trains readers to stop trusting your status labels; reserve it for genuine risk.
• A status update isn't the place for a root-cause deep dive; that belongs in a linked doc or a follow-up conversation, not in the two sentences someone reads on their phone.

Situation: My team needs a feature that relies on another team’s unstable API which often changes and isn’t available for development.

Approach / decomposition:

1. Clarify the contract: Hold a brief alignment with the upstream team to capture expected endpoints, schemas, error codes, SLAs and versioning plan. Record as an OpenAPI/JSON Schema contract.

2. Local development with stubs and mocks:

• Create a lightweight stub server (wiremock / json-server / simple Flask) that implements the agreed OpenAPI contract and returns realistic success and error responses.
• Use mocks in unit tests to isolate business logic: mock HTTP client responses for edge cases and retries.

3. Consumer-driven contract tests:

• Define consumer expectations as CDC tests (Pact or Spring Cloud Contract). Run them in our CI to produce consumer contracts that we publish to a shared contract broker.

4. Integration / CI pipeline:

• Publish consumer contracts to the broker. Upstream team can run provider verification against their API when ready.
• Add contract verification step in our CI that runs against the stub and (later) the real provider endpoint.

5. Feature flags & incremental rollout:

• Implement the feature behind a feature flag and a configurable provider target (stub vs real).
• When upstream is available, enable the flag in a staging environment first and run end-to-end smoke tests, then progressively enable in canary production.

6. Validation plan when upstream stabilizes:

• Run provider verification from consumer contracts against the real API.
• Execute end-to-end tests in an isolated env with the real API; validate latency, error-handling, retry/backoff, and schema compatibility.
• Monitor metrics (error rate, latency), logs, and alerts during canary. If failures appear, roll back via feature flag.

Why this works:

• Stubs and mocks let our team implement and test business logic independently.
• CDC enforces compatibility and creates a clear contract to prevent integration surprises.
• Feature flags plus incremental validation minimize blast radius and give controlled rollout and quick rollback.

Notes / edge cases:

• If upstream keeps changing, automate contract verification and include versioning/mapping adapters on our side.
• Ensure stubs are maintained from the contract to avoid drift (generate stubs from OpenAPI when possible).

Direct answer

A strong 60 to 90 second project pitch has five beats, in order: a one-line hook that states the problem or its cost, your specific role, the one decision or action that mattered most, the quantified outcome, and a single closing detail that proves technical depth. Everything else gets cut, no matter how proud you are of it.

Framework: the five-beat pitch

1. Hook (1 sentence): state the problem in terms the listener already cares about ("users were dropping off before finishing setup," "a manual process took half a day every week"). Skip the project's internal codename.
2. Your role (1 sentence): "I was the [role] responsible for X." Name the scope, not just a title.
3. The pivotal action (1 to 2 sentences): the ONE decision or trade-off you made, not a chronological list of everything you did.
4. Outcome (1 sentence): a number if you have one, otherwise a concrete before/after description.
5. Proof-of-depth detail (1 sentence): one specific technique or constraint that only someone who actually did the work would mention. This is what survives a "tell me more" follow-up.

Pacing math: conversational speaking pace runs about 130 to 150 words per minute. A 60 second pitch is therefore roughly 130 to 150 words, and a 90 second pitch (1.5 minutes × 130 to 150 wpm) tops out near 195 to 225 words. Write it out, read it aloud with a timer once, and cut whichever beat is running longest, almost always beat 3.

Worked example (skeleton, adapt the specifics to your own domain)

"Our signup flow was losing about 4 in 10 people before they finished creating an account. I owned redesigning that flow end to end. The one decision that mattered: I cut the form from 7 fields to 3 up front and pushed the rest to after first use, instead of redesigning the whole flow at once. Signup completion went from roughly 60% to 78% over a month of testing. The detail that proves I did the work: the biggest single gain came from moving email verification to a background step instead of a blocking one, a trade-off you only find by watching real session recordings."

The shape holds outside product work too. A security engineer's hook might be an incident count, a data engineer's might be a pipeline failure rate, a QA engineer's might be an escaped-defect count. The hook changes; the five beats do not.

Trade-offs and pitfalls

• Lead with the problem, not the tech stack; interviewers forget stacks, they remember problems.
• Don't try to cover multiple projects in one pitch, that is what follow-ups are for.
• A memorized script falls apart the first time someone interrupts with a question; know the story well enough to survive being cut off mid-sentence.
• An over-precise number you can't defend under a follow-up reads worse than a rounded number you can defend.