DoorDash Senior Software Engineer Interview Preparation Guide

Direct answer

The deliverable itself is what's being tested here, so the answer is to actually produce it: a first paragraph stating mission and composition with assumptions clearly flagged, a second paragraph connecting the role to product and engineering objectives, followed by naming the two or three assumptions that matter most and exactly how you'd confirm them with the hiring manager.

Structured elaboration

• Reconstructing composition from public sources: cross-reference LinkedIn's people list (filtered by title keywords) against the company page, plus phrases like "you'll report to" or "you'll work closely with" across several job postings, plus an org-chart tool if the company is large enough to appear on one. This lets you build a probable reporting structure without ever having seen an internal chart.
• Flagging assumptions honestly: use explicitly hedged language ("I'm assuming X, based on Y") instead of presenting an inference as settled fact. A hiring manager who catches an inference stated as certainty will discount the rest of what you say.
• Turning assumptions into real questions: convert each one into a short, specific question rather than a vague "tell me about the team," for example, "I saw the team grew by three people over the last two quarters on LinkedIn, is that mostly backfill or net-new headcount?"

Worked example

Paragraph 1: "Based on your careers page and recent postings, I'm assuming this team sits within the Payments organization and has roughly ten engineers split across a Core Payments pod (a small, semi-autonomous sub-team owning a specific area) and a Fraud and Risk pod, reporting to an Engineering Manager who reports to a Director of Payments Engineering. I'm inferring this from three of the last four postings listing 'Payments Engineering' as the department and two mentioning partnering with a Fraud team."

Paragraph 2: "The team's mission looks like keeping transaction success rates high while reducing fraud losses, which connects to your recently announced plan to expand into higher-risk international markets, since that expansion will put pressure on both systems at once."

Assumptions to confirm: "Two things I'd want to check directly with you: whether Fraud and Risk is really a separate pod or a shared responsibility inside Core Payments, and whether this role is a backfill or a net-new seat created specifically for the international expansion."

Trade-offs and pitfalls

Resist the urge to sound fully certain, a summary this specific will be wrong somewhere, and naming that up front, rather than being caught out later, is what turns "did some research" into "can operate with incomplete information," which is the actual thing being evaluated. Don't let the assumption list balloon into hedging on everything either, pick the two or three that would most change your approach, not every minor uncertainty you noticed.

Direct answer

Before your work depends on it, put a written interface contract in place (the shape of the data or API, error cases, and versioning), a single named owner on each side, and an SLA (service level agreement: the vendor's contractual uptime/response commitment) for questions and changes with a defined escalation path. Then build against a mock or stub (a fake stand-in for the real API that returns data matching the agreed contract, so your team can build and test without waiting on the real thing) that matches that contract, so a late dependency delays true integration, but doesn't block your team's progress.

Framework

Before you start building. Agree the contract explicitly (schema, error handling, versioning), name one owner per side rather than 'the team', and set an SLA for response time and change turnaround, with an escalation path if it slips.

While you wait. Build and test against a mock or stub that matches the agreed contract, so your team keeps moving. Pair it with automated contract tests, so if the mock and the real dependency drift apart, you find out at build time instead of at release.

Internal-team dependency vs external vendor dependency. The mechanics differ once the other side is a vendor rather than a team you can walk over to.

Worked example

Situation: a product depends on a vendor-managed API (for example a payments or identity provider). The vendor's contract commits to 99.5% availability, but the product's own reliability target requires 99.95%.
Quantifying the gap: a year has 8,760 hours. At 99.5% availability, permitted downtime is 0.5% of 8,760 = 43.8 hours per year. At 99.95%, permitted downtime is 0.05% of 8,760 = 4.38 hours per year. The vendor's contract therefore permits about 43.8 minus 4.38 = 39.42 hours per year more downtime than the product can actually tolerate.
Action: negotiated for a higher committed SLA where possible; where the vendor would not move the number, negotiated a compensation or credit clause tied to a downtime threshold, documented in writing. Regardless of the contract terms, added caching on the read path so a short vendor blip doesn't cascade immediately, and a fallback path that degrades the feature gracefully instead of erroring during an outage window.
Result: the contract negotiation raises the ceiling on paper, but the caching and fallback layer is what actually protects users during the gap between what the vendor promises and what the product needs, since a credit clause compensates you after an outage, it doesn't prevent one.

Trade-offs and pitfalls

• Mocks and stubs only help if kept in sync with the real contract. A stale mock creates a different kind of surprise at integration time.
• Vendor SLA credits are usually a small fraction of the real cost of downtime (lost trust, lost usage). Treat them as compensation, not as risk mitigation on their own, and pair them with technical fallbacks.
• Applying heavy contract-and-SLA process to a short, low-risk internal dependency slows down partners who need speed more than ceremony. Calibrate the rigor to the risk and duration of the dependency, not the same weight for every one.

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 would not reject it outright and I would not adopt it alone. I would adopt it as a leading signal (an early measure that tends to move before the result we care about, such as retention or revenue, so it helps steer but does not prove success on its own) only if I can pair it with measures that reveal gaming, and I would define it so that gaming it requires doing the thing we actually want. The rule of thumb behind this is Goodhart's law, popularly phrased by Marilyn Strathern as: when a measure becomes a target, it ceases to be a good measure.

Step 1: Decide whether to adopt

Ask:

1. What behaviour do we want, and how directly does this number reflect it?
2. How would a customer game it, and what would they gain? If gaming has no payoff, the risk is small.
3. Can I redefine it so the cheap trick no longer counts?

Example (illustrative): the KPI is "reports created per account", meant to show engagement. A customer can run a script that makes hundreds. Redefine it as "reports viewed by at least two different users within seven days". Now gaming means getting colleagues to read the reports, which is the outcome we wanted.

Step 2: Guardrail measures

A guardrail measure is a second number watched alongside the KPI to catch harm or distortion:

• Retention of the same accounts, not only activity.
• Support tickets and complaints per account.
• Share of the KPI that comes from the top few accounts.
• Quality indicators of what was counted (do the reports get opened?).

Also: do not tie pay or targets to the raw number, and report it with its guardrails every time.

Step 3: Detect gaming after launch

Look at distributions (the full spread of values across accounts: how many sit near 10, how many near 150) rather than the single average. Worked example with illustrative data: 1,000 accounts, of which 986 create about 10 reports (9,860 in total) and 14 create about 150 (2,100). The average looks healthy at about 12 per account, but those 14 accounts (1.4%) produce roughly 17.6% of all volume. Then check whether those 14 also have views, retention and tickets in line with the others. If their reports are never opened, that is gaming.

Other checks: sudden step changes (a jump in the number right after the KPI was announced, instead of a gradual climb), usage at odd hours or in fixed intervals, accounts with high counts and low value on every other measure. Review the segment monthly and ask customer success what they see.

Step 4: Respond

Fix the definition first, not punish customers. A message to a flagged account might read: "We noticed your account created 150 reports last week and few were opened. We changed how this measure counts so it reflects reports your colleagues read. Is something in the product making the old count hard to avoid, or can we help you get more out of the reports?" Separately, if the KPI is also part of a contract or incentive, the response differs and needs legal and sales input.

Trade-offs and pitfalls

• A KPI so guarded that it takes months to compute is useless.
• Dropping every gameable metric leaves nothing measurable.
• What would change my call: if the payoff for gaming is large (money, status) and I cannot redefine it, I would refuse to adopt it.

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

I/O amplification means the storage engine ends up reading or writing far more bytes to the physical device than the logical operation actually needed, and it is the main reason storage-engine choice matters for a write-heavy backend. B-tree engines tend to have LOW write amplification but pay for it with random-write I/O patterns and page-level fragmentation, while LSM-tree engines like RocksDB convert random writes into sequential ones, good for write throughput and SSD wear, at the cost of HIGHER write amplification from repeated background compaction.

Structured elaboration

• B-tree engines: a write updates the specific on-disk page containing that key in place, but the unit of I/O is the PAGE, not the row, so a small update still writes a whole page. A 200-byte session row on a 16 KiB InnoDB page is 16,384/200, about 82x byte-level write amplification for that page flush, and about 41x on PostgreSQL's 8 KiB page. That multiplier falls when several rows on the same page are dirtied before the page is flushed, so a workload with good page locality really can approach the "near 1x" shorthand, and it rises again once you count the write-ahead log, which records the same change a second time before the page is ever written (InnoDB's doublewrite buffer writes the page itself twice on top of that). So the honest statement is that a B-tree's write amplification is not a constant: it is set by how much page locality the write pattern has, and for scattered small updates it is one to two orders of magnitude, not 1x. On top of the byte count, the physical location is effectively RANDOM, since any leaf page across the whole tree could be the target. B-trees also typically need write-ahead logging plus periodic page splits and rebalancing that add their own I/O. Random writes are expensive on spinning disks and, to a lesser but still real degree, SSDs, where writes happen in larger physical erase-block units, so a small random write can force the drive itself to read-modify-write a whole flash block internally, a device-level amplification separate from the storage engine's own.
• LSM-tree engines: writes append sequentially to an in-memory memtable and a write-ahead log, then periodically flush as a whole sorted, immutable SSTable file to disk sequentially, so the write path itself is nearly pure sequential I/O, fast and easy on SSD wear-leveling. The cost shows up later: as SSTables accumulate, background COMPACTION repeatedly reads multiple existing SSTables and rewrites a merged, sorted replacement, so a single logical write to a key can be physically rewritten several more times as it is pulled into successive compaction passes across levels, which is exactly what write amplification measures for an LSM-tree, the ratio of total physical bytes written, including all compaction rewrites, to the bytes the application logically wrote.
• Read amplification: a B-tree read is close to O(log n) page reads, navigating root to leaf. An LSM-tree read may need to check the memtable AND multiple SSTables across multiple levels, since the key could be in any of them, so LSM-tree reads commonly cost more I/O per lookup, mitigated in practice with per-SSTable bloom filters (to skip files that definitely lack the key) and block caches, though the underlying multi-file-check structure remains real read amplification that a well-tuned B-tree does not have.
• Compaction cost and SSD wear: compaction strategy (leveled versus size-tiered) trades write amplification against read and space amplification differently. Mechanically, size-tiered compaction merges several similarly-SIZED SSTables into one larger file once enough of them accumulate, with no rule about which key ranges end up in which file, so a given key can be scattered across many overlapping files; leveled compaction instead organizes SSTables into levels of geometrically increasing size (each level roughly 10x the one above it), keeps each level's key ranges non-overlapping (aside from the newest level, L0), and merges a file down into the overlapping files of the next level as it fills, which rewrites data more often (higher write amplification) in exchange for bounding how many files a read ever has to check (lower read amplification) and reclaiming obsolete versions sooner (lower space amplification). A leveled strategy, RocksDB's common default, is commonly cited in the literature as having write amplification roughly in the 10-30x range for typical configurations, a real, non-trivial cost to both throughput headroom and SSD wear, though the exact factor depends heavily on the level-size multiplier and workload, so it should be measured on the actual workload rather than assumed.

Worked example

A write-heavy workload writing 1 GB of new or updated data per hour. B-tree engine: the answer depends on page locality, so state both ends. If the 1 GB of logical row changes is scattered so that each 16 KiB page is flushed after only one or two small rows on it were touched, the physical volume is easily 10 GB/hour or more once whole-page writes and the write-ahead log are counted, which is the same ballpark as the LSM figure below, and it arrives as effectively-RANDOM page writes that gain nothing from sequential-write optimizations. If instead updates cluster well, several rows per page per flush, the same 1 GB can land nearer 2-3 GB physical. Either way the RANDOMNESS of the I/O pattern is a cost on top of the byte multiplier, not a substitute for it. LSM-tree engine with leveled compaction: the same 1 GB/hour logical write, at a typical leveled write amplification factor in the commonly-cited 10-30x range, could correspond to roughly 10-30 GB/hour of actual physical writes once all compaction is accounted for, all of it sequential, which a modern SSD handles far better per byte than random writes of the same size, but which still consumes real write bandwidth and wear-leveling budget the application's 1 GB/hour figure alone would not reveal.

Trade-offs and pitfalls

It is easy to compare amplification factors alone and conclude the B-tree is strictly better because its number sounds smaller, missing two things: the B-tree's number is only small when page locality is good, and RANDOM I/O at a low amplification factor can still be slower and harder on a device than SEQUENTIAL I/O at a much higher amplification factor, exactly why LSM-trees dominate for write-heavy workloads on SSDs despite the higher write-amplification number. A common mistake is tuning compaction purely to minimize write amplification without checking the effect on READ and SPACE amplification, a genuine three-way trade-off, not two independent knobs, and picking a compaction strategy, size-tiered favoring write throughput at the cost of read and space amplification, leveled the reverse, without first knowing whether the workload is read-heavy or write-heavy in practice.

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.

Direct answer

A relational managed database (Amazon RDS, Cloud SQL) is a transactional (OLTP, online transaction processing) engine built for an application's live read and write traffic with strong consistency and referential integrity. A NoSQL or document store (DynamoDB, Firestore) trades some of that structure and consistency strictness for horizontal scale and flexible schema, while still serving live application traffic. A cloud data warehouse (Redshift, BigQuery) is an analytical (OLAP, online analytical processing) engine built for scanning and aggregating huge historical datasets, not for serving a single user's request in milliseconds.

Structured elaboration

The OLTP-versus-OLAP split is the real dividing line. OLTP means many small, fast reads and writes, each touching a few rows, driven by a live application; both RDS/Cloud SQL and DynamoDB/Firestore live here, differing mainly in schema rigidity and horizontal-scale model. OLAP means a small number of large, long-running queries that scan and aggregate millions to billions of rows, driven by analysts or pipelines rather than end-user requests; Redshift and BigQuery live here, using columnar storage (reading only the columns a query touches, instead of whole rows) and massively parallel query execution.

Typical data-engineering tasks per store.

• Relational managed database: the SOURCE system a pipeline extracts FROM, for example change-data-capture (CDC: streaming every insert, update, and delete off a source table as it happens, instead of re-querying the whole table on a schedule) off a production order-management database, or the destination for a small, highly structured operational reporting table that needs transactional guarantees.
• NoSQL/document store: another common EXTRACT source, for example event or clickstream data landing in DynamoDB from a mobile app, and occasionally a pipeline TARGET when output needs to be served back to an application at low latency, for example a nightly batch job writing precomputed recommendation results into DynamoDB for the app to read.
• Cloud warehouse: the load-and-aggregate destination for an extract-load-transform (ELT) pipeline, extracting from RDS and DynamoDB, loading raw or lightly transformed data into the warehouse, and transforming with SQL once it is there; also where data engineers point BI dashboards and scheduled aggregation jobs.

Worked example

A production RDS orders table feeds a change-data-capture stream that lands the raw rows in BigQuery or Redshift as raw_orders; a scheduled SQL transform builds a daily_revenue_by_region table from that; a BI dashboard reads only the warehouse table, never the production database, specifically to avoid competing with live application traffic for the same rows.

Trade-offs & pitfalls

Running analytical aggregation queries (multi-table joins over millions of historical rows) directly against the OLTP database that is also serving live application traffic is the most common mistake this split guards against: it steals I/O and lock resources from a paying customer's request path for a report that could have run against a warehouse copy instead.

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.