DoorDash Software Engineer Interview Guide - Entry Level

Direct answer

Preorder visits node, then left, then right; inorder visits left, then node, then right; postorder visits left, then right, then node; all three are depth-first traversals (DFS), following one branch as deep as possible before backtracking. Level-order (breadth-first search, BFS) instead visits every node one full depth at a time using a queue. To reconstruct a tree from a serialized form, preorder combined with explicit null markers is the natural single-pass choice, because each value tells you exactly where to place it in the recursion without needing a second array to cross-reference.

Structured elaboration

Recursive versus iterative cost. A recursive traversal uses the call stack, which costs $O(h)$ space where h is the tree's height ($O(\log n)$ for a balanced tree, $O(n)$ worst case for a completely skewed one). An iterative version with an explicit stack (for the depth-first orders) or queue (for level order) has the same asymptotic space cost, but it avoids the recursion-depth limits some language runtimes impose, which matters for very deep, skewed trees.

Level order grouped by depth. Enqueue the root, then repeatedly record the queue's current size before draining exactly that many nodes: that snapshot is what lets you know where one depth level ends and the next begins, since each drained node's children get enqueued for the following level.

Choosing preorder-with-nulls for reconstruction. Preorder plus null sentinels needs only one traversal: read a value, recursively build its left child from what follows, then its right child, treating a null marker as "no subtree here." Preorder plus inorder (without nulls) also works, but only if all values are unique, and it needs an auxiliary index map over the inorder sequence to avoid an $O(n^2)$ naive search, adding bookkeeping the null-marker approach does not need. Level order with null markers is workable too (BFS serialization), but reconstructing parent-child links across levels needs more bookkeeping than the purely recursive preorder approach.

Related extensions from the same traversal family. A BST iterator (an object that exposes a paused, resumable inorder walk) keeps the explicit stack alive across calls instead of finishing the traversal eagerly, giving amortized (averaged over a sequence of operations) $O(1)$ time per next() call. Finding all node pairs at distance k from a target reuses the same level-by-level machinery as level-order traversal, just starting the breadth-first search from the target node instead of the root. The height-balance check, maximum path sum, and invert-binary-tree problems are all further applications of the postorder shape: each recursive call computes something (a height, a best path so far, a swapped subtree) from its children and returns it up to its parent, rather than printing a value as it visits.

graph TD
  A[3] --> B[9]
  A --> C[20]
  C --> D[15]
  C --> E[7]

Worked example

from collections import deque


class TreeNode:
    def __init__(self, val=0, left=None, right=None):
        self.val = val
        self.left = left
        self.right = right


def level_order(root: TreeNode | None) -> list[list[int]]:
    if not root:
        return []
    result = []
    queue = deque([root])
    while queue:
        level_vals = []
        for _ in range(len(queue)):  # freeze this level's size before draining
            node = queue.popleft()
            level_vals.append(node.val)
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
        result.append(level_vals)
    return result


if __name__ == "__main__":
    root = TreeNode(3, TreeNode(9), TreeNode(20, TreeNode(15), TreeNode(7)))
    print(level_order(root))

Running this on the tree pictured above prints [[3], [9, 20], [15, 7]].

Complexity

Time: $O(n)$ for all four traversals (preorder, inorder, postorder, and level-order), since each one visits every node exactly once and does $O(1)$ work per visit.
Space: $O(h)$ for the three depth-first traversals, from the recursion call stack (or an explicit stack for an iterative version), where h is the tree's height, as already noted above. The level-order queue never holds more nodes than one full level of the tree, which is at most $O(n)$ in the worst case (a wide, shallow tree).

Edge cases

• Empty tree (root is None): level_order already returns [] via its explicit check; the depth-first traversals equally return immediately for a None node.
• Single-node tree: all four traversals visit just that one node and produce a single-element result.
• A skewed (essentially linear) tree: recursive depth-first traversals can hit a language's default recursion-depth limit (for example, Python's default is around 1000 frames), which is a concrete argument for the iterative forms in production code.

Trade-offs & pitfalls

The most common bug in the level-order implementation is not snapshotting len(queue) before the inner loop starts; without that snapshot, nodes from the next level get enqueued and then immediately drained in the same pass, smearing two levels together.

Situation: We need a ranking that surfaces ADRs (architectural decision records) most likely to explain a given incident/bug report. Below is a practical set of signals, a combined heuristic/ML scoring design you can implement as a software engineer, and a validation plan.

Signals (>=5):

1. Textual similarity: semantic embedding cosine between incident text and ADR title/body (e.g., sentence-transformers).
2. File/component overlap: whether ADR references same service/module or filenames mentioned in the incident.
3. Time proximity: ADR last-modified or adopted date relative to incident time (recent ADRs more likely).
4. Change correlation: ADR linked commits/PRs that touch code changed in the failing release.
5. Severity/impact scope: ADR claimed scope (global vs. local) or tagged criticality.
6. Ownership signal: ADR author/team matches owning team of impacted component.
7. Usage frequency: how often ADR is referenced in past incidents (historical signal).
8. Confidence/explicitness: presence of “known limitation”, “workaround”, or risk keywords in ADR.

Scoring approach:

• Start with a weighted hybrid score: score = w1 * sim + w2 * comp_overlap + w3 * change_corr + w4 * recency + w5 * hist_freq + w6 * owner_match + w7 * keyword_score.
• Normalise each signal to [0,1]. Use heuristic weights initially (e.g., higher for change_corr and comp_overlap).
• Parallel ML model: train a gradient-boosted tree (XGBoost) or logistic regression using the signals as features. Label training data from historical incidents: ADR marked as true root cause (1) or not (0). Use embeddings + binary flags + numeric features.

Validation & monitoring:

• Offline: use precision@k, recall@k, MAP, and ROC-AUC on held-out incidents. Use time-based split (train on past, test on future) to avoid leakage.
• Online: small A/B test: baseline (heuristic) vs. ML ranker. Measure incident-resolution time, fraction of incidents with ADR accepted as root cause, and human satisfaction score.
• Continuous feedback loop: capture explicit confirmations (engineer marks ADR as relevant) as training labels; retrain regularly.
• Drift detection: monitor feature distributions and precision@k; trigger retrain when performance drops.
• Edge cases: cold-start ADRs have no history—bump semantic similarity and component overlap to compensate. Missing data: fallback to text-similarity.

Implementation notes:

• Precompute embeddings and component matches to serve low-latency.
• Store feature vectors for quick re-ranking.
• Log decisions and human feedback for auditing and model improvement.

Direct answer: Full-batch gradient descent computes the gradient over the ENTIRE dataset of size N before each update - O(N) work per step, but very few steps needed since each step's gradient is exact. Pure SGD (batch size 1) computes a gradient from a single example - O(1) work per step, but needs many more steps and each step's gradient is a noisy, high-variance estimate. Mini-batch SGD (batch size b) is the practical middle ground, O(b) work per step with gradient variance that decreases as $1/\sqrt{b}$, and - critically for modern hardware - the per-step work is highly PARALLELIZABLE across the batch dimension on a GPU, which is why throughput doesn't simply plateau immediately as batch size grows from 1.

Structured elaboration

• Per-step cost: proportional to batch size b (O(b) forward+backward work), true for all three variants (full-batch is simply b=N, pure SGD is b=1).
• Gradient variance: averaging over b independent samples reduces the VARIANCE of the gradient estimate by a factor of b (standard error shrinks as $1/\sqrt{b}$) relative to a single-sample gradient - this is why larger batches give a more accurate (lower-variance) estimate of the true full-dataset gradient direction, at the cost of more compute per step.
• GPU throughput and batch size: a GPU has a large but FIXED amount of parallel compute capacity; for small batch sizes, the GPU is under-utilized (idle compute units, since there isn't enough parallel work to fill them), so increasing batch size increases THROUGHPUT (examples processed per second) roughly linearly at first. Past some batch size, the GPU's compute units are fully saturated, and further batch-size increases no longer improve throughput per unit time (you're now compute-bound, not parallelism-starved) - this is why throughput plateaus, not because the underlying O(b) per-step cost changes, but because the WALL-CLOCK cost of processing b examples stops decreasing per-example once hardware parallelism is maxed out.

Worked example

Consider a GPU with enough parallel compute to fully utilize itself at batch size 256 for a given model. At batch size 32, the GPU processes each step in roughly the SAME wall-clock time it would take at batch size 256 (both are "cheap enough" to fit within one wave of parallel execution, dominated by fixed per-step overhead like kernel launch latency, not by the actual per-example compute) - so throughput (examples/second) at batch 32 is roughly 8x lower than at batch 256, purely from underutilizing available parallelism. Increasing batch size from 256 to 1024 (4x), once the GPU is already saturated at 256, roughly QUADRUPLES the wall-clock time per step (now truly compute-bound, scaling with actual work) while processing 4x the examples - so throughput stays roughly flat past this point, confirming the plateau.

Trade-offs & pitfalls

• Very large batch sizes, beyond the GPU-saturation throughput benefit, introduce their own OPTIMIZATION-QUALITY trade-off separate from the raw throughput question: overly large batches can generalize worse (a well-documented empirical phenomenon, sometimes called the "generalization gap"), requiring learning-rate scaling and other adjustments to compensate.
• Memory, not just compute, constrains batch size in practice - larger batches need proportionally more memory for activations (as discussed in the dense-layer-complexity survivor), and can hit a hard memory ceiling well before hitting a compute-bound throughput plateau.
• The variance-reduction benefit of larger batches has DIMINISHING returns ($1/\sqrt{b}$, not $1/b$) - doubling batch size from 1024 to 2048 reduces gradient noise by only about 29% (since $1/\sqrt{2} \approx 0.71$), a much smaller relative improvement than the first doubling from 1 to 2, which is part of why very large batch sizes give diminishing optimization benefit even before hitting hardware throughput limits.

Direct answer. Separate the disagreement about the FIX from the disagreement about the RELATIONSHIP: state the specific, observable risk you're flagging, ask questions before asserting you're right, and be explicit about what would change your mind -- the goal is a better outcome for the code, not winning the exchange.

Structuring the conversation

1. Lead with the specific concern, not a verdict: 'I'm worried this fix only handles the null case but not the empty-string case -- can you walk me through why that's covered?' invites a conversation; 'this fix is wrong' invites defensiveness.
2. Separate technical disagreement from personal friction: if the other engineer becomes defensive, explicitly name that you're both trying to ship something correct, not litigating who's right: 'I want to make sure we don't ship a regression, not relitigate the whole approach.'
3. Ask for their reasoning before pushing your own further: they may have context you don't (a constraint from an earlier decision, a reason the simpler fix was deliberately avoided) -- understanding that first often resolves the disagreement faster than restating your position louder.
4. Propose a concrete, falsifiable test: 'Can we add a test for the empty-string case? If it passes, I'm satisfied; if it fails, that confirms the gap I'm flagging.' This moves the conversation from opinion to evidence both people can agree on.
5. Know when to escalate, and how: if the disagreement is genuinely unresolved after a good-faith exchange, loop in a third reviewer or a tech lead as a NEUTRAL tie-breaker, framed as 'let's get another perspective,' not 'let's prove I was right.'

The outcome

In the case I'm describing, the falsifiable test resolved it directly: we added the test for the empty-string case, watched it fail against the original fix, and the colleague agreed within minutes that the gap was real -- at that point we were looking at the same failing assertion together, not debating opinions. The fix was updated to cover both cases before merge, so nothing shipped broken, and the review thread stayed short and non-adversarial because the test carried the argument instead of either of us needing to insist we were right. A secondary, longer-term outcome was that the same colleague started adding an empty-string case to their own tests going forward without being asked, which suggested the exchange changed a habit, not just that one PR. No escalation to a third reviewer was needed in this instance; the disagreement stayed contained to the two of us and closed out the same day.

What I'd do differently in hindsight (if reflecting on a past instance)

Often the friction comes from feedback that read as a verdict rather than a question -- 'this is wrong' instead of 'walk me through this case.' The adjustment that tends to help most is leading with curiosity and a concrete, testable case rather than a general critique, since a concrete case is something both people can verify together instead of debate.

Trade-offs and pitfalls

• Over-indexing on 'always ask, never assert' can read as passive or indecisive when you ARE confident and the stakes are high (a security or correctness issue) -- calibrate directness to how confident you are and how much is at stake, not a uniform script.
• Escalating too quickly, before attempting a good-faith direct conversation, can read as going over someone's head and damage trust even if you were technically right -- reserve escalation for genuine deadlock, not the first sign of disagreement.

Direct answer
In sixty to ninety seconds, state what the work was and the concrete outcome in the first sentence, then use the remaining time to give just enough context for the outcome to make sense, without narrating the full journey.

Structured elaboration

1. Lead with outcome, not chronology. Start with what changed as a result of the work, not "so first we looked into..."; the listener's attention is highest in the first five seconds, so spend it on the punchline, not the preamble.
2. Give one sentence of context, just enough for a listener unfamiliar with the project to understand why the outcome mattered.
3. Name the concrete result. A number, a capability that now exists, or a problem that's now solved, stated plainly rather than hedged.
4. Leave a natural opening for a follow-up question, rather than trying to cram in every detail; a pitch that answers every possible question leaves nothing for the listener to ask, which can feel like a wall rather than a conversation.
5. Practice against a clock. Sixty seconds is shorter than it feels; a written script read at a natural pace is the fastest way to find out where it actually runs long.

Worked example
"I led the project to move our nightly batch reports to a real-time pipeline. Before this, finance waited until 9am for the previous day's numbers; now they're available within about five minutes of the event happening. It took about six weeks and meant migrating three internal tools onto the new pipeline, which is the part I'm happy to go deeper on if useful."

Outcome and its concrete magnitude come in the first two sentences (roughly 9am wait to about five minutes), then one sentence of scope, then an explicit invitation to go deeper rather than continuing to add detail.

Trade-offs and pitfalls

• The most common failure is starting with the setup ("so basically what happened was...") instead of the outcome, which spends the highest-attention seconds on the least important part.
• Cramming in every detail to sound thorough usually makes the pitch run long and diluted; a pitch that leaves a natural question is often more effective than one that tries to be exhaustive.
• Precision matters more than the exact wording; if you don't have a hard number, say so honestly ("noticeably faster, though I don't have an exact percentage") rather than inventing a specific-sounding figure you can't back up.

Direct answer

First diagnose why the meeting is stalling: usually it's because status-sharing and decision-making are mixed together, and no one is clearly accountable for closing a decision when people disagree. The fix separates the two (status moves async, meeting time is reserved for decisions), names a decision owner per topic, and tracks decisions in writing so they don't get relitigated the next week.

How to redesign it

Step 1: diagnose before redesigning. Ask whether people are status-updating instead of deciding, whether it's unclear whose call something is, or whether decisions do get made but aren't tracked so they resurface. Each cause has a different fix.

Step 2: separate status from decisions.

Step 3: track decisions so they don't restall. Keep a lightweight decision log: what was decided, who owns it, and the date. If an item can't close live, name a follow-up owner and a deadline instead of letting it silently carry over.

Step 4: reconsider the cadence. If most items now resolve async, a lower-frequency decision meeting paired with a written weekly status may serve the group better than a fixed weekly sync for everything.

Worked example

Situation: a cross-functional project with design, engineering, and data has a standing 60-minute weekly sync. Status updates take up 45 minutes, decisions surface in the last 15, and things 'decided' in the room get revisited the following week.
Action: introduced a pre-read posted 24 hours ahead covering status and any open decisions that need a live call; restructured the meeting to skip status entirely and spend the full time on flagged decisions, each with a named owner; started a shared decision log so a closed decision has a record to point back to.
Result: the meeting shortened from 60 to 30 minutes because status moved out of the room, and decisions stopped resurfacing because there was now a written record of what was actually agreed and by whom.

Trade-offs and pitfalls

• Cutting the meeting without giving people another outlet just moves the stalling into chat threads. Live time is still needed for genuine disagreement, don't eliminate it entirely.
• Naming a decision owner can feel like taking authority away from the group. Frame it as who is accountable if the call turns out wrong, not as a power grab.
• Async pre-reads fail without a light enforcement habit. If nobody protects the norm, it quietly reverts to status-in-the-room within a few weeks.
• Adding a decision log and a template is itself process. If it isn't paired with removing something (like the status round-robin), it just adds overhead on top of the original problem.

Direct answer

Before removing a column proposed for deletion, build an impact map from metadata, saved-query parsing, and dependency graphs to identify every dashboard, report, and downstream job that reads it, then drive a staged deprecation (not an immediate drop) so every identified consumer has a chance to migrate before the column actually disappears.

Structured elaboration

• Metadata-driven discovery: check the data catalog (if one exists) for documented lineage from this column to downstream tables and reports; even an incomplete catalog is a useful starting list, not a complete one.
• SQL parsing of saved queries: parse the SQL text of every saved dashboard query, scheduled report, and known ETL job for references to the specific table and column name, which catches consumers the catalog missed or never had recorded, especially ad hoc queries saved outside any formal cataloging process.
• Dependency graphs: for pipeline-level consumers (a downstream ETL job that reads this table and feeds yet another table), walk the full transitive dependency chain, not just direct consumers, since a job two hops downstream can still break even if it never directly queries the column itself.
• Stakeholder ownership: once the consumer list is built, map each consumer to an owning team or individual, since the goal of this whole exercise is to reach a human who can confirm "yes, we can migrate off this" or "no, we still need it," not to unilaterally decide from the data alone.

Worked example

A staged deprecation timeline once the impact map is built: (1) announce the planned removal to every identified owner with a concrete deadline; (2) mark the column deprecated in the catalog/schema documentation and, if supported, log a warning whenever a query actually reads it, to catch anyone the static analysis missed; (3) as the deadline approaches, follow up specifically with any consumer whose usage telemetry still shows active reads; (4) only after the deadline passes AND telemetry confirms zero reads for a sustained period, actually drop the column, ideally behind the same expand-contract discipline (rename to a clearly-deprecated name first, drop it fully later) used for any other breaking schema change.

Trade-offs and pitfalls

• Static SQL parsing of saved queries will miss dynamically-constructed queries (a report tool that builds SQL from user-configured filters at runtime) and ad hoc queries run outside any saved-query system entirely; runtime usage telemetry (logging actual column reads as they happen) is the necessary complement to static analysis, not a replacement for it, precisely because static analysis alone cannot see everything.
• The dependency graph needs to go beyond DIRECT consumers: a report built on top of a materialized view that itself reads the column is still broken by dropping the column, even though the report's own query never mentions it, which is why transitive, not just first-hop, dependency tracing matters.
• Rushing the communication step to save time is the most common way this process fails in practice; a technically complete impact map that isn't actually acted on by the owning teams (no deadline, no follow-up, no verification the migration actually happened) just delays the same production incident rather than preventing it.

Direct answer
A normalize_username test suite needs at least five cases: whitespace trimming, case folding, collapsing multiple internal spaces to a single underscore, an empty-string input, and a unicode input, each verifying one specific transformation the function claims to perform.

Structured elaboration and worked example (executed)

import re
import pytest

def normalize_username(s: str) -> str:
    s = s.strip().lower()
    s = re.sub(r' +', '_', s)
    return s

@pytest.mark.parametrize("input_s,expected", [
    (" Alice Smith ", "alice_smith"),        # leading/trailing whitespace + internal space
    ("", ""),                                 # empty string
    ("BOB", "bob"),                           # case-only
    ("multi internal spaces", "multi_internal_spaces"),  # consecutive spaces collapse to ONE underscore
    ("Café Müller", "café_müller"),           # unicode: accents preserved, only case+space normalized
])
def test_normalize_username(input_s, expected):
    assert normalize_username(input_s) == expected

Running pytest -v: 5 passed in 0.15s (all 5 parametrized cases PASSED).

Why each case matters

• Leading/trailing whitespace + internal space in one case: confirms .strip and the internal-space collapse both apply, and specifically that the OUTER whitespace does not itself become a leading/trailing underscore (a common bug: stripping after substitution instead of before would turn " Alice Smith " into "_alice_smith_").
• Empty string: the trivial identity case; confirms the function doesn't throw on an empty input, which a naive regex-only implementation with no length guard could plausibly do depending on the regex engine, though this simple implementation happens to handle it safely.
• Case-only: isolates the .lower behavior from the whitespace logic, so a failure here specifically points at case-folding, not spacing.
• Multiple internal spaces: this is the case most likely to be under-tested; a naive .replace(' ', '_') (not a regex with +) would produce "multi___internal___spaces" (one underscore per space) instead of the collapsed single-underscore form, so this test specifically distinguishes a regex-based collapse from a naive single-character replace.
• Unicode input: confirms accented characters are preserved through .lower (Python's .lower is unicode-aware by default, correctly lowercasing 'É' to 'é'), rather than being stripped, mangled, or requiring a separate ASCII-only code path.

Trade-offs & pitfalls
The unicode test above uses .lower, which is adequate for accented Latin characters but is a WEAKER transform than .casefold for languages with more complex case-folding rules (e.g. German 'ß', which .casefold maps to 'ss' but .lower leaves unchanged); if the real system needs to treat visually-distinct usernames as the same account across such languages, the test suite should include a .casefold-specific case (like 'ß' vs 'ss') to pin down which behavior is actually intended, since the two functions genuinely disagree on some real-world inputs.

Direct answer

Pull Flow Log records for the source and destination ENIs (Elastic Network Interfaces, the virtual network cards attached to each instance) and read the action field. A REJECT for that exact tuple means a security group or NACL (Network Access Control List, a stateless, subnet-level firewall, separate from the per-instance security group) is blocking it, while ACCEPT records with the app still timing out mean the problem is above the network layer entirely.

Structured elaboration

• Query Flow Logs (Athena or CloudWatch Insights) filtered to the incident window and the ENIs/ports involved.
• On REJECT, check both the security group and the NACL, since NACLs are stateless and can block the return leg even when the security group allows the request.
• On ACCEPT with no timely response, look at DNS resolution, the TLS handshake, or the destination process itself, none of which Flow Logs show.
• No records at all suggests routing, a missing route table entry or peering/Transit Gateway (a managed hub that routes traffic between multiple VPCs and on-premises networks over VPN or dedicated connections) misconfiguration, rather than a security rule.

Worked example

action=REJECT for 10.0.1.15:443 -> 10.0.2.20:5432 conclusively points at SG/NACL rules; action=ACCEPT for the same tuple with a client-side timeout redirects the investigation entirely toward the destination service instead.

Trade-offs and pitfalls

Flow Logs sample and aggregate rather than log every packet, so very brief issues can be underrepresented. They carry no payload detail, so ACCEPT doesn't mean the request was handled correctly.

What the interviewer probes next

Why NACLs being stateless matters for return traffic, and how you'd alert on a REJECT spike for a given path.

Situation: Our team will lose several senior engineers with critical domain knowledge within 12 months. The risk is service degradation, slower feature delivery, and firefighting during incidents.

Goal: Create a robust mentorship and knowledge-capture program that transfers tactical and tacit knowledge, creates successors who can run systems independently, and provides measurable continuity.

Plan (6–12 month phased program)

1. Define scope & objectives (weeks 0–2)

• Inventory systems, ownership, on-call runbooks, recurring incidents, and domain experts.
• Prioritize based on business impact (revenue, SLAs, technical debt).

2. Artifacts to produce (always versioned in repo/confluence)

• Architectural Decision Records (ADRs) for all major design choices.
• System maps & sequence diagrams (drawn, exported, and text-backed).
• Runbooks & playbooks: step-by-step incident recovery with commands and escalation matrix.
• Recorded walkthroughs: short 10–20 min Loom/recordings per subsystem (code walkthrough, deploy process, incident demo).
• Pair-programmed code tours: annotated code excerpts in repo README + links to relevant PRs.
• Test & CI documentation: how to run tests, common flaky tests, and test ownership.
• Knowledge checklist: "What I would do in week 1/2/4 as owner."

3. Mentorship & shadowing schedule (months 0–6)

• 1:1 pairing: each departing engineer pairs with 2 successors (primary + secondary) across 8–12 weeks, 3 half-days/week.
• Rotation: successors rotate through supporting tasks (deploys, pager duty, backlog grooming) with mentor for first 4 weeks.
• Shadow shifts: successors take observer on-call shifts with mentor handling postmortem commentary.
• Gradual handoff: weeks 6–10 successor takes lead on low-risk tasks; mentor reviews and signs off.

4. Mini-projects for successors (months 2–9)

• Ownership project 1 (4–6 weeks): refactor a small component, update ADR, add tests, and deploy—mentor acts as reviewer.
• Ownership project 2 (6–10 weeks): own a minor production incident postmortem and implement a preventive change.
• Documentation Sprint: successors produce recorded walkthroughs and update runbooks as deliverables.

5. Tools & process

• Centralized knowledge repo (Confluence/GitHub Wiki) with templates for ADRs, runbooks, recordings indexed by tag.
• Mandatory checklist completion before departure.
• Weekly “Knowledge Share” demos (brown bag) recorded and archived.

6. Long-term succession metrics (tracked monthly, baseline then targets)

• Ramp Time: average time for a successor to complete first independent production deploy — target: ≤8 weeks after pairing.
• Coverage Score: % of critical systems with current ADR + runbook + recording — target: 100% before departure.
• Incident MTTR for systems after handoff — target: ≤ baseline *1.2.
• Ticket Churn: % of reopened or re-assigned tickets due to knowledge gaps — target: ≤10%.
• On-call escalation rate: % of pages that require original expert — target: 0% within 3 months of handoff.
• Artifact Quality: % of artifacts reviewed & accepted by a peer reviewer (checklist complete).
• Successor Confidence: self-rated readiness survey (1–5) — target average ≥4.

7. Retention & knowledge reinforcement

• Keep mentors involved as advisors for 3 months post-departure (reduced load).
• Quarterly refresh sessions and reviews of ADRs/runbooks.
• Make knowledge capture part of performance goals and recognition (time allocation, bonuses).

Why this works

• Mixes documented artifacts (explicit knowledge) with hands-on pairing and projects (tacit knowledge).
• Measurement focuses on outcomes (ramp time, MTTR), not just produced documents.
• Phased approach ensures progressive responsibility transfer and reduces single-person risk.

I’d start immediately with the inventory & prioritization, assign pairs, and set bi-weekly checkpoints with engineering leadership to adapt based on metrics.