Senior Engineering Interview Handbook / Chapter 112
The Project Dossier
A practical chapter for turning scattered project memory into a truthful, sanitized source of evidence for project-deep-dive interviews.
Page tools
Build the record before you build the story
You have chosen a project that can bear sustained questioning. Now resist the urge to turn it into a polished answer.
Project memory tends to preserve a clean chronology: there was a problem, the team built something, and the result was good. Interviews disturb that chronology. An interviewer may jump from architecture to personal contribution, from a claimed result to its source, or from the launch to an incident six months later. A rehearsed story often breaks under those jumps because it has compressed away the facts that connect them.
A project dossier is a private record of those facts. It holds the context, users, constraints, baseline, team boundaries, architecture, decisions, execution, results, failures, lessons, and later evolution of one project. It is not a script and normally is not something to send to an interviewer. Its value is that several different answers can be recovered from the same honest source.
The following pages build one dossier around a modeled project: a migration of a partner-reconciliation workflow. The example is fictional but technically representative; use its method, not its facts.
Recover the project from its traces
Begin with recollection, then look for the traces that can correct it. Depending on what you are still permitted to access, those traces may include design documents, pull requests, issue histories, calendars, incident reviews, rollout plans, dashboards, support themes, or feedback from people who worked on the project. Do not remove confidential material from an employer or retain records you are not entitled to keep. Often the safe act is simply to use an accessible record to refresh your memory, then write a sanitized note in your own words.
At this stage, fragments are useful:
Partner retries -> duplicate exception work during close
Old flow was nightly batch; late adjustments arrived after comparison
I proposed event-boundary idempotency; platform team owned ledger service
First rollout group exposed adjustment schema gap; ramp paused
Finance ops later triaged from dashboard without engineering log searches
Exact volumes, partner names, and finance totals cannot be shared
This is not yet an interview answer. It is better than one because each line can be challenged. Was the baseline measured or merely remembered? What did “proposed” involve? Who paused the ramp? Did the dashboard cause the support change, or merely coincide with it? Write down uncertainty while you can still see it.
Do not begin by filling every field in a template. Templates reward completion, and completion can turn weak memory into confident prose. Begin with the project’s traces and let the important questions emerge from them.
Find the spine
Once the fragments are visible, compress them into a project spine. The spine is the shortest account that still preserves causality:
Finance operations reconciled partner events through a nightly batch process.
Retries and late adjustment files created duplicate exceptions and manual work
during month-end close. Our team moved ingestion behind an idempotent event
boundary and wrote auditable checkpoints to a ledger service owned by another
team. I led the service boundary, idempotency model, and rollout sequence; I did
not own the finance rules or the ledger implementation. A staged rollout reduced
recurring correction work, although the exact totals are confidential and a
triage-process change also contributed. Late adjustments exposed a schema gap,
so we paused the ramp, added an adjustment path, and brought finance operations
into later schema reviews.
That paragraph contains the before-state, affected users, constraint, system change, team boundary, personal role, result, caveat, failure, response, and lesson. It does not contain every fact. It tells you which facts belong together.
Test your own spine by removing its impressive nouns. If the project only sounds difficult because it mentions a large customer, a famous product, a high event count, or a senior title, the pressure and choices are still missing. The spine should remain intelligible after proper nouns and sensitive numbers have gone.
Then ask where the account jumps. “We introduced streaming and manual work fell” jumps over both the decision and the evidence. “I led the migration” jumps over contribution boundaries. “The launch succeeded” jumps over production behavior and time. Mark each jump; those are the parts of the dossier that need depth.
Keep claims attached to evidence
For every claim that could carry an answer, record how you know it. A compact line is enough:
Claim: retries were a major source of duplicate exceptions
Basis: exception categories reviewed during rollout
Quality: observed directly, but only for the rollout period
Disclosure: partner names and counts are confidential
Claim: engineering support work fell after migration
Basis: fewer escalation threads and fewer requests to inspect logs
Quality: inferred; finance also changed its triage process
Disclosure: describe direction, not internal totals
The useful distinctions are ordinary ones. You may have observed something directly. You may be inferring it from several signals. A number may be rounded or estimated. A detail may be accurate but confidential. Keep those qualifications beside the claim instead of trusting yourself to remember them under pressure.
Use the strongest wording the evidence can carry. If you know only the direction of change, say that manual review fell. If you can safely bound the change, describe the recurring burden before and the smaller class of exceptions afterward. Use an exact figure only when it is accurate, attributable, and appropriate to disclose. A caveat is not an apology; it shows that you understand what the measurement does and does not establish.
Not every worthwhile result is a metric. A project may produce a safer failure mode, an auditable trail, a reversible rollout, faster diagnosis, clearer ownership, or less dependence on a particular team. Record the observable change and its limits rather than inventing a number for it.
Draw the boundary around your contribution
Private notes should be stricter about ownership than spoken answers need to be. For each substantial piece of work, choose an accurate verb:
- Owned: you drove the decision or work and were accountable for its result.
- Influenced: your analysis, review, or alignment changed the direction, but another person or group owned the decision.
- Implemented: you built the work, whether or not you chose the design.
- Observed or inherited: you know the consequence but did not create the original choice.
In the modeled migration, “I led the migration” is too broad to be useful. The dossier should say more:
Owned: ingestion boundary, idempotency model, rollout sequencing
Influenced: exception taxonomy and dashboard through finance review
Implemented: replay harness and two partner adapters with the service team
Depended on: platform team's ledger API and finance-owned matching rules
Did not own: partner contracts, finance policy, ledger storage design
This does not diminish the candidate. It reveals the shape of the senior work: making decisions across boundaries while leaving colleagues’ ownership intact. It also prevents a common failure under follow-up, where “I” expands during success and contracts to “we” when a mistake appears.
Record architecture as behavior
The architecture section exists so you can redraw the system and explain how it kept its promise. A component inventory is not enough. Follow one consequential path from trigger to outcome and annotate the places where behavior could change:
partner event
-> authenticate and normalize at ingestion
-> claim idempotency key before downstream work
-> write auditable ledger checkpoint
-> route unmatched or late adjustments to exception handling
-> expose lag, duplicates, and exception categories to operators
Beside that path, note who owns each boundary, where durable state lives, what may be retried, what must remain ordered, how failure is detected, how work is recovered, and how rollout can be paused or reversed. Include security, privacy, cost, or compliance constraints when they materially shaped the system.
The next chapter develops the spoken architecture narrative. Here, keep the unattractive details it will need: the dependency that timed out, the manual fallback, the inconsistent partner key, the alert that fired too late. Those details often prove that the architecture was operated rather than memorized.
Preserve decisions as live forks
A useful decision note begins before the choice became obvious. Record the decision, the plausible alternatives, the constraint that separated them, the downside you accepted, your role, and what later evidence showed.
For the reconciliation project:
Decision: claim idempotency at the partner-event boundary
Alternative: deduplicate only inside the nightly batch
Why the alternative was plausible: smaller change, reused existing batch
ownership, and could ship sooner
Binding constraint: duplicate work had to stop before it reached finance's
exception queue, not merely be discovered at the next batch comparison
Accepted cost: partner-specific keys, replay tests, and migration state
Later evidence: retry attempts became visible at ingestion; late adjustments
still exposed a separate schema gap
My role: owned the model and drove the review; the service team implemented it
The late-adjustment sentence matters. It prevents the decision from becoming a victory story. Boundary idempotency addressed duplicates; it did not solve every kind of temporal correctness. Mature decision records retain the problem that the chosen design left behind.
Three to five consequential forks usually teach you more about a project than twenty technology notes. Include technical design, rollout, sequencing, scope, staffing, risk acceptance, and decisions not to build when they changed the outcome. The later chapter on decision and trade-off logs will help you deepen them.
Let execution disturb the design
Architecture describes intended behavior. The execution record shows what the work encountered. Build a spare chronology around changes of understanding, not every milestone:
Shadowed two partner groups and compared batch and event outputs.
Late adjustments produced mismatched checkpoints in the first group.
Paused the ramp; finance and engineering separated corrections from new events.
Added an adjustment path, replay cases, and a visible exception category.
Resumed one group before widening rollout.
Operators later used the categories without asking engineering to inspect logs.
Capture design dissent, dependency trouble, scope changes, rollout controls, incidents, adoption work, support handoff, and reversals. These are not debris around the architecture. They often contain the clearest evidence of planning, influence, risk judgment, and production ownership.
Continue past launch. What happened after the first release? Perhaps users adopted an unexpected workflow, another team extended the system, an incident invalidated an assumption, or the architecture was later simplified. If you left before learning the outcome, say so. “I do not know what happened after I changed teams” is a legitimate boundary; invented closure is not.
Sanitize the telling, not the engineering
Sanitization should replace identity while preserving mechanism. Remove company, customer, partner, and internal service names. Generalize exact volumes, financial figures, contract terms, unreleased plans, security-sensitive details, and incident identifiers. Do not reproduce source code, screenshots, credentials, customer data, or internal documents in the dossier.
Then check whether the safe version still contains the affected user, system class, constraint, choice, rejected alternative, failure behavior, result, and your contribution. “We improved an internal system for a stakeholder” is safe but empty. “We moved a partner-reconciliation workflow behind an idempotent event boundary because retries were creating duplicate finance exceptions” preserves the engineering without naming the company or partners.
If the mechanism itself is sensitive, choose another project. A dossier cannot make unsuitable material safe through clever phrasing.
Close the dossier and try to retrieve from it
The first test of the artifact happens with the document closed. Explain the project in two minutes. Draw the main architecture path. Defend one decision against its best alternative. State your part and the team’s part. Describe the result with its measurement limit. Explain one failure and what changed after it.
Reopen the dossier only after the attempt. Add facts you could not retrieve, correct claims that became larger when spoken, and remove notes that never helped you reason. If your answer collapsed into chronology, strengthen the spine and decision forks. If your ownership became vague, sharpen the boundary. If sanitization erased the difficulty, determine whether the project can be used at all.
Repeat this for the primary, secondary, and reflection projects selected in the previous chapter, but let the dossiers differ. A migration may need a rich execution record. A product experiment may need careful measurement and counter-metrics. An influence project may need stakeholder boundaries and the sequence by which a decision changed. The artifact should take the shape of the work.
Use Appendix G: Project Dossier Template as a capture aid if a blank page is slowing you down. Do not confuse a filled worksheet with a finished dossier. The work is complete when the document can return you to the truth of the project quickly—and when that truth still holds after the interviewer chooses where to probe.