Astellas Software Engineer Interview Guide

The 60-second brief

Astellas is a pharmaceutical company. Candidates describe Software Engineers there building and maintaining applications for research, clinical trials and business operations: data infrastructure, research tools and internal operational systems, from clinical trial data management to enterprise tooling. The job covers the whole development lifecycle (design, implementation, testing and code review). Engineers also work with product managers, data scientists and other engineering teams to turn business requirements into technical specifications. Because the software runs in a regulated industry, regulatory compliance, security and data integrity come up again and again in candidates' descriptions of the role.

This guide is for engineers preparing for a Software Engineer interview at Astellas. Candidates report that three or more years of experience is typical and that mid-to-senior levels are common, depending on the team. It covers the five technical and domain questions candidates report and the collaboration topics behind the behavioral questions. It also covers the stack the requirements name: a core programming language relevant to the team, version control and software design patterns, with AWS or Azure, data security and pharmaceutical or healthcare experience as extras. Coding and SQL practice problems are included in case a technical round asks for code.

Candidates report a phone screen on background, motivation and high-level technical experience, then a series of technical and managerial rounds that dig into past projects and hypothetical problems. No fixed round count or order has been reported.

Focus areas

• Technical interview fundamentals
• Problem solving
• STAR-based behavioral interview technique

Overview

The questions candidates report from this loop are mostly conversations about work you have already done. They ask about a complex technical challenge you resolved, how you keep code maintainable as requirements change, how you debug in production, how you cope with an unfamiliar stack, and a resume concept you can explain in depth. That means most of your preparation is building a small set of project stories that hold up two or three follow-up questions deep, not memorising a long list of answers.

Candidates report that the technical discussion tests whether you understand how your tools work underneath, not just how to call their APIs. Some also report questions about technologies outside their main stack. For every technology on your resume, prepare its mechanism, a way it fails and the alternative you would weigh it against. For anything you have not used, prepare to reason from a tool you know rather than to bluff.

Security, data integrity, code review and software quality are among the topics candidates say to be ready for, which fits software that handles clinical and research data. Have at least one concrete example ready: input validation, an audit trail, least-privilege access, or a migration you reconciled row by row. Candidates also advise linking each story to its effect on end users or the business, so put the outcome and who it affected at the end of every project answer.

Candidates report that how hard the technical rounds are depends on the team's project. Some get coding challenges, and others are asked how they would design a system for a given data volume. Keep one language fluent enough for a live problem. Practise sizing a design out loud: rows per day, storage and indexes, and what changes at ten times the load.

Where to focus your preparation

Candidates have not reported a sequence beyond a phone screen followed by technical and managerial rounds, so this guide treats the loop as one preparation focus. Ask your recruiter how many rounds you will have and whether any include live coding or system design.

Preparation focus

Candidates report that the process starts with a phone screen about your background, why you want to join Astellas and your technical experience at a high level. It then moves into technical and managerial rounds. Across those stages, the reported emphasis is your professional history: what you built, why you chose that design, and how you would handle open-ended scenarios. Some candidates also report coding challenges, questions on designing a system for a given data volume, and questions about technologies they had not used. To prepare, take two projects in real depth, have a production-debugging walkthrough ready, and keep enough coding fluency to handle a live problem if one comes up.

What to demonstrate

• How clearly you explain past projects and the architectural trade-offs behind them
• Structured reasoning through open-ended scenarios and unfamiliar technologies
• Depth on the tools listed on your resume, beyond their APIs
• Communication and collaboration, covered by the managerial and cultural-fit questions

How to prepare

• Write two project deep dives (architecture, the main constraint, one trade-off you would revisit, one security or data-integrity decision) to use for the complex-challenge and resume-concept questions
• Rehearse a production-debugging walkthrough on a real incident: mitigation, change timeline, evidence, fix, regression test, write-up
• Ask the recruiter how many technical and managerial rounds there are and whether any include live coding or system design
• Solve two of the coding practice problems in your main language and explain the complexity aloud

Where candidates lose points

Telling the complex-challenge story in the team's voice, so your own decisions never appear

Rewrite each project story so the Action sentences start with 'I' and name what you designed, measured or wrote. Keep one sentence for team context, and end with a number.

Listing a technology on your resume that you cannot explain below its API

For each skill, write out the mechanism, one failure mode and one alternative, plus where it changed a decision in your work. Remove any line you cannot defend at that depth, because the resume-concept question goes straight there.

Bluffing when asked about a technology outside your stack

Candidates report these questions do come up. Say plainly that you have not used it, then reason from the closest tool you know and describe how you would get productive: documentation, a small prototype, a review from someone experienced.

Answering the production-debugging question with a list of tools instead of a sequence

Practise the order out loud: size the impact and mitigate, build the timeline of changes, narrow it with logs, metrics and traces, reproduce safely, fix with a regression test, write it up. 'I check the logs' on its own is not an approach.

Leaving security and data integrity out of project and design answers

Candidates list security and data integrity among the topics to prepare. Bring one concrete example, such as input validation, an audit trail, least-privilege access or a reconciled migration, and say what would have gone wrong without it.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Can you describe a complex technical challenge you faced in a previous role and how you resolved it?

Medium · Technical and Domain Knowledge

Approach

1. Choose a challenge where the hard part was technical and you owned the decision: a migration that could not lose records, a performance ceiling, a concurrency bug, an integration with an unreliable upstream system. Avoid stories where the only difficulty was scheduling or people.
2. Use STAR but put most of the weight on the Action. State the constraint in one or two sentences (data size, latency target, compliance requirement, deadline), then name the two or three options you considered and why you rejected the others.
3. Make your part explicit with 'I' (what I designed, measured, wrote), and keep one sentence for what the rest of the team did.
4. Say how you protected correctness: a dry run against a copy, validation checks, or a before-and-after reconciliation count.
5. Close with a measured result (error rate, run time, records reconciled, incidents since release) and one thing you would do differently now.

Follow-up

• Which option did you reject, and under what conditions would it have been the better choice?
• How did you confirm the fix worked in production, not only in testing?
• What would break first if the data volume grew tenfold?

How do you ensure your code remains maintainable and scalable as project requirements evolve?

Medium · Technical and Domain Knowledge

Approach

1. Answer with practices you have actually used, each tied to an example: module boundaries behind clear interfaces, unit and integration tests in CI, and code review against agreed standards.
2. Name design patterns where they handled a real point of change: an adapter or strategy to isolate a third-party system that kept changing, a repository layer to keep storage details out of business logic. Also say when you chose not to abstract, since early abstraction costs readability.
3. For changing requirements, describe backward-compatible changes: versioned APIs, and expand-then-contract schema migrations (add the new column, backfill, switch reads, then drop the old one), so callers never break partway through.
4. For scalability, describe measuring before optimising. Read the profiler output or the query plan, keep services stateless so they scale horizontally, paginate large reads, and make retried operations idempotent.
5. Give one trade-off between delivery speed and technical debt, and how you tracked the debt (a ticket, or a test that pins the shortcut).

Follow-up

• Tell me about a requirement change that broke your design. What did you refactor?
• How do you decide when duplicated code should become a shared abstraction?
• What do you look for first when you review someone else's pull request?

Can you explain a concept from your resume that demonstrates your depth of knowledge in [specific skill]?

Medium · Technical and Domain Knowledge

Approach

1. Before the interview, pick the two or three skills your resume relies on most and prepare each one level below its API: how it works internally, where it breaks, and what the alternatives are.
2. Use a fixed structure: a one-sentence definition, the mechanism, a failure mode or limit, then the point on your resume where that knowledge changed a decision.
3. Have examples ready. For SQL: B-tree indexes, why wrapping a column in a function stops the index being used, and transaction isolation levels. For Python: the GIL, and when to use processes rather than threads. For AWS or Azure: how identity and access policies are evaluated.
4. Anchor the concept in your own project. 'I added a composite index after the query plan showed a sequential scan' is stronger than a textbook definition.
5. Remove any skill from your resume that you cannot defend at this depth.

Follow-up

• What happens if the assumption behind that mechanism no longer holds?
• How does it compare with the alternative you did not choose?
• How would you explain the same concept to a non-technical stakeholder?

What is your approach to debugging issues in a production environment?

Medium · Technical and Domain Knowledge

Approach

1. Start with impact and mitigation. Confirm the symptom in monitoring, size the blast radius (which users, which data, since when), and restore service with a rollback, feature flag or failover before you look for the root cause.
2. Ask what changed: deploys, configuration, data volume or shape, dependency versions, infrastructure. Line that timeline up against the moment the metric moved.
3. Narrow it down with evidence: structured logs filtered by request or correlation id, metrics split by host or version, traces across services. Then reproduce it outside production with the same inputs, using masked or synthetic data where production data is sensitive.
4. Fix it with a regression test that fails before the change and passes after. Ship through normal review, and check the fix against the same metric that showed the problem.
5. Finish with a blameless write-up: the timeline, the trigger versus the root cause, and a follow-up (an alert, a validation check, a runbook entry) that prevents a repeat.

Follow-up

• How would you debug a problem you cannot reproduce outside production?
• If the bug had corrupted some records, how would you find and repair them?
• What logging or alerting would you add so the next incident is faster to diagnose?

Suggested practice checklist

Each day prepares one part of the reported loop: confirming the format, project deep dives for the challenge and resume questions, maintainability, production debugging, unfamiliar technology, coding practice in case a round includes code, and the collaboration stories behind the managerial rounds.

Day 1 — Confirm the format and audit your resume

• Ask your recruiter how many technical and managerial rounds follow the phone screen and whether any include live coding or system design.
• List every technology on your resume and mark the ones you can explain internally, with a failure mode for each.
• Choose the two projects you will use for deep dives, preferably one involving data integrity or security.

Deliverable: The recruiter's answer on format, a marked-up technology list, and two chosen projects with one-line summaries.

Day 2 — Project deep dives for the complex-challenge question

• For each chosen project, write the architecture, the main constraint, the options you considered, your choice and the measured result.
• Answer the complex-technical-challenge question aloud using one project, then again using the other.
• Write down one trade-off from each project that you would make differently today, and why.

Deliverable: Two written project deep dives, two recorded answers, and two trade-offs you would revisit.

Day 3 — Resume depth and maintainability

• For your three strongest resume skills, write the definition, mechanism, failure mode and the decision it informed in your work.
• Answer the resume-concept question aloud for each skill and cut anything you could not defend.
• Prepare the maintainability answer with one design-pattern example and one backward-compatible schema or API change you shipped.

Deliverable: Three skill sheets, a trimmed resume if needed, and a maintainability answer built on two concrete examples.

Day 4 — Production debugging and data integrity

• Write a walkthrough of a real incident in order: mitigation, change timeline, evidence, reproduction, fix with regression test, write-up.
• Rehearse the outage narrative with your numbers: error rate, users or records affected, time to mitigate, time to resolve.
• Solve the SQL practice problem on detecting a concurrent edit during an update and explain how it prevents lost updates.

Deliverable: An incident walkthrough, a spoken outage narrative with numbers, and a working optimistic-concurrency update query.

Day 5 — Unfamiliar technology and estimating unknown work

• Write your story about working in a stack outside your expertise, including how long it took you to ship your first change.
• Pick a tool you have never used (for example, whichever of AWS or Azure you know less), map its core services onto ones you know, and explain the mapping aloud.
• Practise estimating work you have never done, giving a range and the assumptions behind it.

Deliverable: An unfamiliar-stack story, a written concept mapping for a new tool, and one estimate with stated assumptions.

Day 6 — Coding and data-volume practice

• Solve the resource-graph archiving problem without recursion and state its time and space complexity.
• Solve the heaviest-tenants-in-a-window problem under a memory limit and explain the data structure you chose.
• Rewrite offset paging as keyset paging in the SQL practice problem and explain why it stays fast on deep pages.

Deliverable: Three working solutions, each with its complexity or query-plan reasoning written next to it.

Day 7 — Collaboration stories and a full mock

• Write STAR stories for cross-team coordination, a disagreement over technical direction, and explaining a technical risk to a non-technical stakeholder.
• Run a mock with a friend: a phone-screen introduction, then all five reported technical and domain questions with follow-ups.
• Write two questions for your interviewers about the team's current technical challenges or how it measures success.

Deliverable: Three collaboration stories, notes from the mock on answers to tighten, and two questions for your interviewers.

Behavioural preparation

Candidates report that the managerial and cultural-fit questions focus on collaboration: coordinating across teams, handling disagreement over technical direction, and explaining complex ideas to non-technical stakeholders. Candidates also report being asked for examples of integrity, collaboration and a focus on the patient. Build each story around a specific situation, the action you took yourself and a result you can measure.

1. Can you describe a complex technical challenge you faced in a previous role and how you resolved it?
2. Describe a time you coordinated a change across teams. What did you do when their priorities conflicted with yours?
3. Tell me about a disagreement over technical direction. What evidence did you bring, and how was it resolved?
4. Give an example of explaining a technical constraint or risk to a non-technical stakeholder. What did they decide, and what happened next?
5. Describe a time you raised a data-integrity, security or quality concern that slowed delivery. How did you make the case?

How do you handle situations where you are asked to work with a technology stack outside your primary expertis

Medium · Technical and Domain Knowledge

How do you handle situations where you are asked to work with a technology stack outside your primary expertise?

Approach

1. Candidates report questions about technologies outside their main stack, so prepare both a real story and a general method. In the story, name the stack, why you had to use it and what deadline you were working to.
2. Show the method. Map the new tool onto concepts you already know (a new ORM against the SQL it generates, a new cloud provider against the equivalent services on one you know), read the official documentation, build a small throwaway prototype, and ask an experienced colleague to review your first change.
3. Quantify how quickly you became productive: when you shipped your first change and what you delivered in the new stack.
4. Be honest about your limits and say what you still would not claim expertise in. Claiming fluency you do not have is what sinks this answer, especially when the next question tests it.

Follow-up

• Which concept was hardest to carry over from your main stack, and why?
• How did you make sure your code in the new stack met the team's quality bar?
• If I asked about a tool you have never used, how would you reason about it?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?