Scale-Up Interviews

The system succeeded before it became the problem

A marketplace has grown around one order service. It owns checkout, fulfillment, refunds, seller payouts, notifications, customer email, and operational reporting. That concentration was useful when one team could ship the whole customer journey. Now several teams share its release path, refund incidents are rising, seller status updates are unreliable, and enterprise customers want better order reports. Leadership wants services split within two quarters.

This is the natural habitat of a scale-up interview. The system is neither a blank page nor an inert legacy estate. It has customers, revenue, incident history, hidden dependencies, and a roadmap that will continue while it changes. The original design probably was not foolish. The conditions that made it effective have expired.

The tempting answers are opposites: draw the clean service architecture, or argue that the roadmap leaves no time for migration. Both avoid the senior decision. The real work is to find a change small enough to survive contact with the existing system and important enough to improve it.

Make the complaint observable

“The monolith is slowing us down” is a conclusion without evidence. Before choosing a boundary, ask what people can observe. Are unrelated changes caught in the same release? Is the test suite the delay? Do teams edit the same data without a clear owner? Are incidents concentrated in refunds, or does every failure merely page the order team? Do customer reports disagree with finance? Which promised features are blocked, and by what dependency?

Suppose the investigation reveals this:

• reporting changes account for many edits to the order service and often wait behind checkout releases;
• enterprise customers need richer order history this quarter;
• the order database is the only trusted source for financial state;
• support already sees stale exports but cannot tell whether the export job or the underlying order is wrong;
• refund incidents are costly, but their workflow and reconciliation rules are not yet understood well enough to move safely;
• one team is willing to own reporting, while ownership of refunds remains divided.

Now the first step can be argued rather than announced. Reporting has customer pressure, coordination cost, a plausible owner, and a migration technique that does not require moving payment authority. Refunds may carry greater pain, but they also carry greater correctness risk and less ownership clarity. A senior answer can choose reporting first without pretending it is the final domain boundary.

This distinction matters in every scale-up prompt: the loudest symptom is not automatically the safest first slice. Choose using customer consequence, learning value, reversibility, ownership, and the ability to prove that the new path agrees with the old one.

Give the first slice a contract

The proposed change is a reporting projection. The order service remains the source of truth. It publishes versioned order-state events; a reporting system builds a tenant-scoped read model for customer history and exports. The existing reporting endpoint remains available while both outputs run in parallel.

That description is not yet a migration plan. The difficult questions sit at the boundary:

• What uniquely identifies an order event, and how are retries deduplicated?
• Can events arrive out of order, and how does the projection recognize a stale state transition?
• How are refunds and corrections represented without counting money twice?
• What does a deleted, merged, or reassigned tenant mean for historical data?
• How does a schema change remain compatible with projection versions already deployed?
• Which freshness promise will the customer see?
• Who investigates a mismatch: the producer, the projection owner, or support?

A compact decision record prevents those choices from disappearing between a design interview and a behavioral discussion:

Problem: order-platform coupling blocks reporting delivery and enlarges release risk.
First slice: build enterprise order-history projections; keep order service authoritative.
Not moving: checkout, payment, refund execution, or seller-payout authority.
Contract: versioned tenant and order identifiers, state transition, event time,
          stable event identity, refund state, and correction semantics.
Validation: shadow projection, aggregate comparison, sampled record reconciliation,
            and explicit accounting for known legacy anomalies.
Rollout: internal reads, one customer allowlist, staged traffic, then default.
Rollback: return reads to the existing endpoint; projection lag cannot block checkout.
Ownership: order team owns event truth, reporting team owns projection and exports,
           support owns the customer runbook with named escalation paths.
Success: reporting changes stop blocking order releases, mismatches stay within the
         agreed threshold, support can classify failures, and checkout does not regress.

The artifact works because it joins architecture to responsibility. “Extract reporting” is a shape on a diagram. Source of truth, correction semantics, reconciliation, rollback, and escalation make it operable.

Let parallel operation expose the hard parts

The new projection should earn authority rather than receive it on launch day. Begin by consuming production-shaped events without serving customers. Compare order counts, totals, terminal states, refund states, and freshness against the current path. Investigate mismatches by category. Some will be projection bugs; some will expose ambiguous behavior in the old system; some may be historical data that no implementation can reconstruct cleanly.

“The outputs match” is rarely an honest success criterion. Define what must match exactly, what can be delayed, how long the comparison runs, and who can accept a known discrepancy. Money movement and tenant isolation deserve a different threshold from the ordering of descriptive status text. If the report will support billing or reconciliation, finance or the accountable data owner belongs in the decision. If it is an operational convenience, a visible freshness label and a recoverable export may be sufficient.

This is where a system-design answer becomes a production answer. Include metrics for consumer lag, rejected events, duplicate event identities, reconciliation mismatches, export failures, and the age of the last complete projection. Give each alert an owner and an action. Paging on every retry would turn new visibility into old noise. A page should correspond to customer harm or a condition that will become harmful before normal working hours.

When the shadow output is trustworthy, allow internal users to query it. Then move one willing customer behind a flag. Keep the fallback path intact and make the support state visible: which path served the report, how fresh it was, which run produced it, and where failures should be escalated. Expansion follows evidence, not the calendar alone.

In an interview, this sequence shows more than knowledge of feature flags. It shows that migration is a claim you test: the new boundary is safer, clearer, and cheaper to change than the coupling it replaces.

Move ownership with the code

A service boundary without an operating boundary creates another shared queue. If the reporting team owns the projection but every event change requires an informal favor from the order team, neither team is independent. If the order team can change event meaning without noticing downstream customers, the new architecture has made drift easier.

The smallest useful mechanisms are specific to those risks. Give the event contract a compatibility policy and an owner. Record which team handles producer defects, projection defects, and customer export failures. Add a runbook for lag, reconciliation mismatch, and replay. Let teams propose new order states through a lightweight review that includes affected consumers. Review incidents and contract violations while the boundary is young; reduce the cadence when it becomes routine.

None of this proves maturity merely because it creates documents. A design review earns its cost when it catches incompatible state changes. An ownership page earns its cost when an incident reaches the right team. A runbook earns its cost when support can distinguish stale data from incorrect data without opening the production database. If a mechanism does not change a decision or shorten recovery, improve it or remove it.

The same standard applies to platform work. The event tooling might eventually become a paved road for other teams, with schema checks, replay support, idempotent consumer templates, dashboards, and sensible alert defaults. Do not begin by declaring a platform. First make the reporting migration easier. Then observe what another team would otherwise duplicate. Product teams adopt a paved road because it removes work and risk on day one, not because a central team won a naming argument.

An escape hatch belongs in the design. A low-volume internal workflow may not need the full event path. A latency-sensitive feature may need a different contract. Make deviations visible and owned without forcing every problem through the same machinery.

Keep product pressure inside the decision

The enterprise reporting commitment does not disappear while engineering learns. Nor should the migration hide inside feature work as if it were free. Name the bargain.

The first customer may receive a narrower set of fields while reconciliation and access boundaries harden. Some planned reporting filters may move to a later release. The order team must spend time producing trustworthy events. Support needs a runbook before the allowlist opens. Leadership can then choose with the actual consequences visible: reduce scope, move the date, add capacity, or accept a bounded residual risk through the appropriate owner.

Avoid presenting technical debt as a moral debt owed to engineers. In this case the coupling delays a customer commitment, hides reporting failures, enlarges release risk, and keeps ownership ambiguous. Those consequences make the work discussable alongside product work. “The architecture is messy” does not.

Scale-up interviewers may push: why not move refunds first, since refund incidents hurt more? A useful answer does not defend the original plan at all costs:

I would revisit the slice if incident evidence showed refund correctness was the dominant customer risk. I still would not make refund execution the first extraction merely because it is painful. I would first clarify its state model, reconciliation path, and owner. We can improve alerts, rollback, and incident ownership in the existing service while that work makes a safe boundary possible. Reporting remains a good first migration only if it gives us meaningful risk reduction and learning without distracting from a more urgent reliability failure.

That answer is decisive without becoming attached to a diagram. It protects the reasoning that justified the plan, not the plan itself.

Turn the case into interview evidence

One substantial project can support several parts of a scale-up loop. In a system-design round, trace the reporting boundary, event contract, parallel run, fallback, and failure modes. In a project deep dive, explain the evidence that selected the slice, the disagreement it created, and what changed after launch. In a behavioral round, stay with the adoption problem: perhaps the order team feared losing control while the reporting team feared inheriting bad data. In practical coding, the same judgment appears in smaller form—add tests around existing behavior, make retries safe, preserve compatibility, and leave the code easier to migrate than you found it.

Prepare your own evidence with that continuity. Choose a live-system change you know well and recover the details that resist a polished summary:

• the old choice and why it once worked;
• the observable change that made it expensive;
• the first slice you chose and the attractive slice you rejected;
• the compatibility, validation, and rollback mechanics;
• the product work that continued and the work that moved;
• the people who owned the old and new paths;
• the failure or disagreement that altered the plan;
• the customer, operational, delivery, or developer-experience evidence after the change.

Use numbers only when you can defend them. Concrete operational evidence is also credible: a support engineer could identify the failing path; teams no longer shared a release; rollback became routine; an on-call rotation gained a real owner; new consumers adopted the contract without private coordination.

Do not blame the engineers who built the original system. Explain the constraints they faced and the constraint that changed. Do not make yourself the permanent hero of the new system either. The senior contribution is often the contract, rollout, ownership, or mechanism that lets other people operate without you.

Test whether the company permits the work

A scale-up may ask for controlled evolution while rewarding only immediate feature output. It may ask for platform leadership while keeping every architectural decision with a small founding group. The interview is also your chance to test the job.

Ask which growth pains are most expensive now and what evidence supports that view. Ask how migrations are funded against roadmap work, who owns reliability for customer-critical journeys, and how incident learning changes priorities. Ask where a platform effort gained adoption—or became a queue. Ask how team boundaries and decision authority are changing as the company grows. Finally, ask what this role must make visibly better in its first six months and what authority accompanies that expectation.

Listen for operating detail rather than the preferred vocabulary. “We value ownership” is weaker evidence than a clear account of who can stop a rollout, who resolves a cross-team contract dispute, and how reliability work reaches the roadmap.

Before the loop, rehearse the marketplace case or one of your own from start to finish. Have a partner change one condition: the first customer date moves forward, refund incidents worsen, event reconciliation fails, the proposed owner refuses the service, or the platform team has no capacity. Keep the customer consequence, technical boundary, delivery bargain, and ownership model connected as the answer changes.

The strongest scale-up answer does not promise a painless transformation. It shows why the current system deserves respect, where its old bargain expired, and how one carefully chosen change can improve the software and the organization without breaking the present to reach the future.

Related links

• Reliability and Failure Engineering
• Evolution and Migration
• Migrations and Backward Compatibility
• Technical Debt and Refactoring Strategy
• Execution and Prioritization