Akuaro Software Engineer Interview Guide

The 60-second brief

Reports describe Akuaro as often working as a partner to large enterprise clients, so engineers may work with or inside external teams. Candidates report that the stack varies with the client project. The role is described as hands-on development alongside product owners and other developers.

This guide is for Software Engineer candidates preparing for Akuaro. It covers the five questions candidates report (a project walkthrough, ambiguous or shifting requirements, explaining a technical issue to a non-technical stakeholder, joining a new team or codebase, and code quality), the trade-off topics they say to expect, and how to handle the recruiter and client-team side of the process. No coding exercise appears among the reported questions, so the plan centres on structured spoken answers.

Candidates report an initial screening call, then later phases that can include technical evaluations or conversations about the client projects you would support, with Akuaro leadership or the client team. No fixed round count or order is reported.

Focus areas

• Interview Process Navigation
• Technical Hiring Communication
• Feedback Incorporation

Overview

The reported questions are conversational: walk through your most challenging technical project, handle ambiguous or changing requirements, explain a complex issue to a non-technical stakeholder, integrate into a new team or codebase, and keep code maintainable. Candidates also list trade-off topics to be ready for: microservices versus monoliths, performance optimisation, and unit, integration and end-to-end testing. Two example scenarios come up in those reports: explain a time you chose one technology over another, and design a system for high concurrency. The practical consequence is that you need a small set of real projects you can retell with decisions, alternatives and outcomes, not a list of algorithms to memorise.

The work is described as client-facing: engineers collaborate with external teams, product owners and other developers, and the stack changes with the project. That makes two skills worth rehearsing deliberately. The first is a repeatable routine for getting productive in an unfamiliar codebase (build it, run the tests, trace one request end to end, read recent reviews, make a small first change). The second is the ability to describe a technical problem in terms of cost, date and risk to someone who does not read code. Candidates also report topics around coordinating between an external recruiter and the final company, so treat recruiter messages and scheduling as part of the process, not an administrative detail.

Use your own experience as the raw material. For each of the five reported questions, pick a different real project where possible, so your answers do not all lean on one story. Write each as context, your decision, the option you rejected and why, the result, and what you would change. For the technical trade-off topics, prepare one concrete example each from systems you have worked on, with a measurement or a failure behind it.

Where to focus your preparation

Candidates describe a screening call followed by phases that depend on the client project, so this guide treats the loop as one preparation block rather than a fixed sequence of numbered rounds.

Preparation focus

No numbered round list is reported for Akuaro. Candidates describe an initial screening call about your background and goals, then later phases that may include technical evaluations or deeper discussion of the client projects you would support, with Akuaro leadership or the client team. Some candidates also report limited follow-up after their initial submission, while others describe recruiters giving detailed guidance and feedback. Approach this as one block: confirm the format with your recruiter early, prepare spoken stories for the experience and communication questions, and keep a short list of trade-off examples ready in case a technical conversation is part of your loop.

What to demonstrate

• How clearly you describe your past projects and the reasoning behind your technical choices
• How you handle ambiguous or changing requirements and conflicting priorities
• How you communicate with non-technical stakeholders, project managers and client teams
• Technical trade-off reasoning on topics candidates list: architecture patterns, performance and testing

How to prepare

• Ask the recruiter which stages follow the screening call, whether any stage involves writing code, and whether the client team joins
• Prepare five different projects as stories for the project walkthrough, ambiguity, stakeholder explanation, new-codebase and code-quality questions
• Write one concrete example each for microservices versus a monolith, a performance fix with a before-and-after measurement, and a testing strategy covering unit, integration and end-to-end tests
• Outline a high-concurrency design on one page: a stateless app tier behind a load balancer, connection pooling, a cache with a stated invalidation rule, a queue to absorb write bursts, idempotency keys for retried requests, row locks versus optimistic version checks on hot rows, and the p99 latency and lock-wait metrics you would watch

Where candidates lose points

Answering the project walkthrough as a feature list and a tour of technologies

Structure it as context, the hardest constraint, the decision you made, the alternative you rejected, the result and what you would change. Spend most of the time on the decision, not on the stack inventory.

Naming a technology choice without its trade-offs, for example saying microservices scale better with no mention of operational cost

For each choice you describe, state what you gave up (deployment complexity, latency between services, test setup, team size needed) and what evidence made the trade acceptable. Prepare this for monolith versus microservices, caching, and test layers.

Treating ambiguous requirements as something to wait out, or absorbing every change silently

Tell a story where you wrote down your assumptions, asked the questions that removed the most risk, had the answers confirmed in writing, and told the stakeholder what a change would cost in scope or dates so they could choose.

Explaining a technical issue to a non-technical stakeholder with jargon, or by simplifying until the decision disappears

Open with the impact and the decision needed, use one plain analogy, give two options with consequences in cost, date and risk, then recommend one. Describe how you checked they understood.

Giving a vague code quality answer such as 'I write clean code' and no routine for joining an unfamiliar codebase

Name the mechanisms you actually use: review habits, test layers, linting and CI checks, documentation that travels with the code, and a step-by-step onboarding routine (build, run tests, trace a request, read recent reviews, make a small first change).

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

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?

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?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Can you walk us through your most challenging technical project?

Medium · Professional Experience & Communication

Approach

1. Pick a project where you made the central technical decision yourself. Open with two sentences on the system and the constraint that made it hard, such as request volume, latency target, data size or a fixed deadline. Use "I" for your own part and "the team" for the rest.
2. Name the hardest problem concretely, then the two or three options you weighed. For example: a separate service against a module inside the existing monolith, or synchronous calls against a queue with retries. Say which constraint ruled each option in or out.
3. Show how you found the bottleneck before fixing it: profiling, query plans (EXPLAIN ANALYZE), or p95/p99 latency and error-rate dashboards. Then show how you proved the fix with a load test or a before/after metric you can defend.
4. Cover the testing and rollout: the unit and integration tests you added, and how you shipped safely (feature flag, canary, or a backfill run in batches). Say what you would do to roll back.
5. Close with a measured result and one thing you would change now. If the right call was different in hindsight, admitting it makes the story stronger.

Follow-up

• Which alternative did you reject, and what would have had to be true for it to be the right choice?
• What breaks first if traffic or data volume grows tenfold, and what would you change?
• How did you know the improvement came from your change and not from something else that shipped at the same time?

What is your process for integrating into a new team or codebase?

Medium · Professional Experience & Communication

Approach

1. Get the project building, running and passing its tests locally on day one, and write down every setup step that was missing from the README. Then push one trivial change through the full CI and deploy path so you learn how code reaches production.
2. Trace one real request end to end, from the entry point (route or controller) through the service layer to the data store, using a debugger or logs. Read the schema or data model next, because it shows what the system actually stores.
3. Use history as documentation. Run git log and git blame on the files that change most often, and read the linked tickets and PRs to learn why the code looks the way it does before you change it.
4. Learn the team's working rules before relying on your own: formatter and linter config, branching and review norms, who approves merges, and the definition of done on tickets. In a client or partner team, also confirm environment access and who owns each area.
5. Take a small, well-scoped ticket early, such as a bug fix with a regression test. Keep a list of questions and ask them in batches, and turn what you learn into a fix for the onboarding docs.

Follow-up

• How do you get productive in a codebase with no tests and no documentation?
• You find a pattern in the existing code that you think is wrong. How do you raise it as the newest person on the team?
• In your last onboarding, how long did it take before your first change reached production, and what slowed it down?

How do you ensure code quality and maintainability in your daily work?

Medium · Technical & Process Alignment

Approach

1. Automate the cheap checks so review time goes to design. Run a formatter, a linter and a type checker (mypy, or TypeScript in strict mode) in pre-commit hooks and in CI, and block merges when they fail.
2. Describe your testing split. Use fast unit tests for pure logic, integration tests against a real database or containerised dependency for the boundaries, and a small end-to-end set for the critical user paths. For a bug, write a failing test that reproduces it before you fix it. Treat coverage as a signal, not a target.
3. Keep changes reviewable. Write small PRs with a description of what changed and why, and keep functions single-purpose with dependencies passed in so they can be tested in isolation. In review, check correctness, error handling and naming before style.
4. Candidates describe being embedded in or working with external teams, so show the client-embedded side of maintainability. Adopt the client team's existing conventions and architectural guidelines rather than your own. Write documentation and tests that let the client maintain the code after you rotate off the project. Record significant decisions in a short ADR or README section, and put risky changes behind feature flags so they can be turned off.
5. Back it with one concrete example: a defect your tests or review caught before release, or a refactor that measurably cut the time or risk of later changes.

Follow-up

• A deadline is close and skipping tests would save a day. What do you do, and what do you tell the stakeholder?
• The client's standards conflict with Akuaro's. Which do you follow?
• You are handed a 1,000-line PR to review. What do you check first, and what do you ask the author to change?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

• The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
• Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

The plan starts by confirming the format with your recruiter, then builds one spoken story per reported question, adds the architecture, performance and testing trade-offs candidates list, and ends with a full mock.

Day 1 — Confirm the format and inventory your stories

• Send your recruiter a short message asking which stages follow the screening call, whether any stage involves writing code, and whether the client team takes part
• List five real projects from your past work and note for each the decision you owned, the main constraint, and the result
• Map each project to one of the reported themes: project walkthrough, ambiguity, non-technical explanation, new codebase, code quality

Deliverable: A sent recruiter message and a one-page table of five projects mapped to the five reported question themes.

Day 2 — Walk through your most challenging project

• Write an outline for your hardest project: context, constraint, decision, rejected alternative, result, what you would change
• Rehearse it aloud twice, cutting every detail that does not support the decision
• Add a short version that fits a screening-call answer and a longer one for a technical discussion

Deliverable: A written outline plus a short and a long spoken version of the project walkthrough.

Day 3 — Architecture, performance and concurrency trade-offs

• Write a one-paragraph comparison of a monolith and a service-based design using a system you know, with what you gave up in each
• Write up one performance problem you fixed: what you measured, the change, and the measurement after

Deliverable: A trade-off paragraph, a measured performance write-up, a concurrency outline, and a written lock diagnosis with a safer migration plan from the practice exercise.

Day 4 — Ambiguous requirements and conflicting priorities

• Write the story of a project where requirements were unclear or changed: assumptions you wrote down, questions you asked, how the answer was confirmed
• Add a second story about conflicting priorities between two stakeholders and how the decision was made

Deliverable: Two written stories (ambiguity and conflicting priorities) and an estimate with stated assumptions.

Day 5 — Explain a technical issue to a non-technical stakeholder

• Pick one real issue and write a plain-language explanation: impact, decision needed, two options, your recommendation
• Read it aloud to someone outside engineering and note where they ask what a word means
• Rewrite the explanation, replacing every term they stumbled on, and add how you confirmed understanding

Deliverable: A revised plain-language explanation and a list of the terms you replaced.

Day 6 — Joining a codebase and keeping code maintainable

• Write your onboarding routine as ordered steps: build and run, read tests, trace one request, read recent reviews, ask the owners, make a small first change
• Write down the concrete quality mechanisms you use: review habits, test layers (unit, integration, end-to-end), lint and CI checks, documentation
• Attach one real example to each mechanism, including one time a check caught a defect

Deliverable: A step-by-step onboarding routine and a quality checklist with one real example per item.

Day 7 — Full mock and questions to ask

• Run a spoken mock covering all five reported questions plus the choose-one-technology-over-another scenario, recorded if you can
• Listen back and mark answers that lack a decision, a trade-off or a result, then fix the two weakest
• Write two questions to ask about the team structure and how professional development is supported

Deliverable: A recorded mock, two fixed answers and two written questions for your interviewers.

Experience and stakeholder communication

Candidates describe the experience and communication questions as a check on how you explain your past work and whether you fit a consultative engineering setting. For this role that means stories where you owned a decision, worked with people outside engineering, and adjusted when requirements moved. Use STAR (Situation, Task, Action, Result) and spend most of the time on the action and the reasoning.

1. Can you walk us through your most challenging technical project?
2. What is your process for integrating into a new team or codebase?
3. Explain a time you chose one technology over another and why.

How do you handle situations where requirements are ambiguous or change frequently?

Medium · Professional Experience & Communication

Approach

1. Choose a real case where a requirement was unclear or moved after work began, and name what was unclear: scope, acceptance criteria, data, or a client dependency. A generic statement of principle will not carry this question; a specific project will.
2. Show your sequence. I wrote down the assumptions I was working under, asked the two or three questions that removed the most risk, and had the answers confirmed in a ticket or email with the product owner or client contact so the decision had a record.
3. Describe how you kept work safe while waiting: building a thin slice first, keeping interfaces stable, putting uncertain behaviour behind a flag, and deferring decisions that were hard to reverse.
4. When requirements changed, say how you handled it: re-estimated, told the stakeholder the cost in scope or dates, and let them choose. Close with the result and one thing you would do differently.

Follow-up

• What did you do when a stakeholder contradicted an earlier decision?
• How did you decide what to build before the answer arrived?
• When do you push back on a change instead of absorbing it?

Describe a time you had to explain a complex technical issue to a non-technical stakeholder.

Medium · Professional Experience & Communication

Approach

1. Pick a case where the stakeholder had to make a decision based on your explanation, such as accepting a delay, funding a fix, or choosing between two approaches. An explanation with no decision attached makes a weak story.
2. Lead with what they care about: the impact and the decision needed, in terms of cost, date and risk, before any mechanism. Then give one plain analogy, define any term you cannot avoid, and present two options with consequences.
3. Say how you checked understanding: asking them to restate the trade-off in their words, watching for questions, and following up in writing so the decision was recorded.
4. Finish with the outcome and what you took from it. The mistake that sinks this answer is describing the stakeholder as slow, or reciting the technical detail you simplified instead of how you chose what to leave out.

Follow-up

• How did you know they had understood?
• What did you leave out, and why?
• What would you have done if they had disagreed with your recommendation?

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?