Project-Deep-Dive Readiness Gates

At minute eleven, the source of truth moved

Consider a modeled project-deep-dive mock. The candidate is explaining an entitlement migration for a subscription product. The opening is concise:

I led the entitlement boundary and rollout for a migration from a legacy billing system to a new platform. We used shadow reads, migrated partners in stages, and materially reduced entitlement-related support work.

For ten minutes, the account sounds solid. The candidate can draw the legacy service, the new billing platform, the product applications, and the migration workers. Then the reviewer asks a plain question: “During the shadow phase, where was the source of truth?”

The candidate points to the new platform. The reviewer follows the answer. If that platform denied an entitlement while the legacy service allowed it, which result reached the customer? The candidate says the legacy result did. Could the new platform change access directly? Not yet. What, then, was it the source of truth for?

The architecture has not suddenly become wrong. The description of it was wrong. The commercial ledger owned purchased plan and account status. During the shadow phase, the legacy entitlement service still had serving authority; the new service computed candidate grants and compared them without deciding access. After cutover, authority moved again. “The source of truth” concealed several facts and a change over time.

This is the work of a project-deep-dive gate. It does not ask whether a prepared account sounds senior at summary level. It asks whether the same project remains coherent as questions move through state, authority, ownership, alternatives, rollout, failure, evidence, and hindsight.

Choose for inspectability, not prestige

The best primary project is rarely just the largest item on a resume. It has a rich decision surface that you can discuss safely. There is a before-state with real pressure, a system or workflow whose behavior can be traced, choices that had credible alternatives, execution that encountered resistance, and an outcome with evidence and limits. Your own responsibility is consequential and separable from the team’s work.

A celebrated project can be unusable when its central decisions belonged to someone else, its essential mechanism cannot be disclosed, or its impact depends on a number you cannot defend. A smaller migration, incident recovery, internal platform change, or customer workflow may be stronger because every important claim has another layer underneath it.

The second project has a different job. It proves that the first is not the only setting in which your judgment appears. If the primary project is a platform migration, the secondary might show customer trade-offs, incident leadership, cost control, mentorship, or a delivery decision under severe constraints. Changing the company and component names while repeating the same migration story does not demonstrate range.

Do not demand equal depth from the two projects. The primary needs enough architecture, execution, decisions, and evidence for prolonged inspection. The secondary needs a clear two-minute path, a real mechanism or workflow, at least a couple of defensible decisions, a precise contribution boundary, and an honest result. Fifteen minutes is shorter, but it is not permission for a second polished summary.

Map authority before rehearsing language

Return to the entitlement migration. A useful preparation artifact is not a memorized script. It is a map of what could change, who could change it, and what evidence would reveal a bad change.

In this case, a plan change began in the commercial ledger. An event carried the new account state toward the entitlement services. The legacy service continued to answer product requests while the candidate service computed a shadow answer. A comparator classified disagreements: expected lag, mapping error, unsupported product rule, or unexplained mismatch. Partner rollout could proceed only when the unexplained class was understood and rollback still had a tested owner.

That trace immediately earns better questions. What happened when events arrived late or out of order? Could a refund remove access in one system but not the other? Was the comparator observing the same inputs, or could it declare agreement on stale state? Who chose the mismatch thresholds? Which partner could be rolled back independently? A box diagram without these transitions would provide component vocabulary but little evidence of architectural judgment.

Prepare the project at four resolutions, but let them describe one system. The opening gives the problem, stakes, your role, the consequential change, the bounded result, and what changed in your judgment. The architecture pass follows one real request or unit of work through state, dependencies, failure, observability, and rollout. The decision layer explains the strongest alternatives and the costs actually accepted. Cross-examination reaches attribution, disagreement, measurement, confidentiality, and what you would now change.

The interview may enter at any resolution. If “why not dual-write?” requires restarting the entire chronology, the project is not yet organized around its decisions.

Make each claim carry its boundary

The candidate in the mock says, “I led the technical side.” Inspection makes that phrase smaller and more useful. The candidate owned the entitlement contract, the shadow comparison, and the partner rollout gates. A billing team owned the commercial ledger. Product engineers owned several adapters. The candidate reviewed adapter behavior where idempotency and rollback crossed the entitlement boundary, but did not implement or direct every integration.

That account still shows senior leadership. It also tells the reviewer which decisions can reasonably be inspected as the candidate’s own. Vague “we” language erases judgment; vague “I” language erases the team. Exact verbs let both remain visible.

Impact needs the same treatment. Suppose the support queue was not classified consistently before the migration. The candidate cannot honestly turn a general improvement into a precise reduction or attribute every change to the new service. The safe claim might be:

After the staged cutover, entitlement escalations moved from routine triage to occasional exception handling. I cannot share exact support counts, and the historical categories were inconsistent. The evidence I can discuss is the rollout dashboard, the mismatch record, and the support and finance-ops review after each partner moved.

This answer does not apologize for lacking a percentage. It names the direction, the evidence sources, the measurement weakness, and the disclosure limit. A measured result, an observed change, an estimate, and an inference are different kinds of claim. Labeling them before the mock prevents an exact number from appearing only because the room has gone quiet.

Sanitization also belongs in the dossier, not in improvisation. Choose safe names for systems and customers. Decide which quantities can be rounded without changing the engineering conclusion. Replace a private topology with the public class of dependency that created the constraint. Know which security, commercial, and personnel details must remain absent. The safe version must preserve causality; otherwise the project may be too confidential to use.

Let interruption find the first unstable joint

Run the primary gate for the full 30 to 45 minutes. Give the reviewer the project name and target role, not a script of questions to recite. In the first few minutes, establish the spine. By roughly ten minutes, the reviewer should be able to inspect a state transition or workflow. The middle of the session should follow alternatives, failure, rollout, and a decision that did not work cleanly. Use the remaining time for contribution, evidence, confidentiality, changed judgment, and transfer to a nearby constraint.

The reviewer should interrupt wherever the answer creates an opening:

1. Which fact did each store own at that moment?
2. What exactly could you approve, change, or stop?
3. What was the strongest alternative, and why was it still reasonable?
4. Show me one failure from cause to detection, mitigation, and repair.
5. What evidence supports that outcome, and what does it fail to prove?
6. Which detail are you withholding, and can the technical explanation remain intact without it?
7. What did you believe at the start that you would reject now?

These are starting points, not a mandatory sequence. A useful reviewer follows the candidate’s nouns and claims. If the candidate mentions a rollout gate, ask what it measured, who could override it, and what happened after a breach. If the candidate says “we chose,” ask for the candidate’s recommendation, the decision owner, and the disagreement. The purpose is sustained inspection, not surprise for its own sake.

Record the first place the account changes shape. In the modeled migration, the first defect is the source-of-truth claim. Later defects may matter, but a page of feedback can hide the next action. Repair the earliest unstable joint, then ask a neighboring question that requires the same correction.

Repair the project, then retest its neighbor

The source-of-truth repair is not a better phrase. It is an authority timeline:

Commercial fact: billing ledger owns purchased plan and account status.
Before cutover: legacy entitlement service decides access.
Shadow phase: candidate service computes; comparator observes; legacy decides.
After partner cutover: candidate entitlement service decides for that partner.
Rollback: named owner can return serving authority to the legacy path.
My ownership: entitlement contract, comparison policy, partner rollout gates.
Did not own: billing ledger or every product adapter.

Now retest. Ask what happens when a cancellation event is delayed, then what happens when one partner rolls back while another stays cut over. If the candidate can follow authority through both cases without moving ownership or inventing guarantees, the correction has travelled. Repeating “the source of truth depended on the phase” would only prove that a sentence was memorized.

Other failures require equally narrow repairs. Architecture fog needs one request traced through state and failure, not another diagram rehearsal. Chronology drift needs the hard decision brought forward. Inflated impact needs an evidence source and a limit, or the claim removed. A generic lesson needs the later operating rule and a case where it changed behavior. Sudden redaction needs a safe substitute prepared before the next live attempt.

Then run the secondary project for at least 15 minutes. Its pressure should match the signal it is meant to add. A workflow redesign chosen to show customer judgment should still contain a real product or operational trade-off and a result that can be inspected. If it collapses into stakeholder meetings and an unmeasured claim of efficiency, it has not earned its place merely by being different from the migration.

Decide without averaging away a serious defect

An average score is dangerous here. Fluent delivery cannot cancel a confidentiality leak. A strong architecture explanation cannot cancel taking credit for another engineer’s decision. One severe defect can make a project unsafe even when everything around it sounds polished.

Call the primary ready when a recent interrupted attempt sustains the full time with stable system behavior, decision logic, contribution, evidence, and safe detail. Call the secondary ready when it sustains at least 15 minutes and adds a genuinely different senior signal.

Use repair when the first unstable joint is known and can be corrected in the dossier. Use retest when the correction is honest on paper but has not survived adjacent questioning. Replace or narrow the project when the central work belonged elsewhere, its necessary mechanism cannot be discussed safely, or its outcome has no support beyond assertion.

After both mocks, reduce the evidence to a two-project decision note:

Primary project and target signal:
Secondary project and distinct signal:
System or workflow trace:
Decisions and strongest alternatives:
Owned, led, influenced, reviewed, supported, and did not own:
Measured, observed, estimated, inferred, or confidential results:
Safe substitutes and forbidden details:
First probe that changed the account:
Narrow repair:
Adjacent retest:
Decision: ready | repair | retest | replace

When both projects remain coherent under pressure, preserve them with light practice. The next question is where any remaining risks belong: a 14-day salvage plan, a longer campaign, or an explicit risk carried into the loop.

Related links

• Select the Right Projects
• The Project Dossier
• Architecture Narrative
• Decision and Trade-Off Log
• Complete Project-Deep-Dive Mock
• The 14-Day Emergency Plan