Senior Engineering Interview Handbook / Chapter 111
Select the Right Projects
A practical method for inventorying career work, rejecting unsafe or weakly owned examples, auditioning a primary deep dive, and balancing a three-project portfolio.
Page tools
Choose for the questions that come after the story
The project with the best name is often the wrong deep dive.
A visible launch may have left you with little influence over the design. A large system may have been large in ways that never affected your work. A technically difficult implementation may end at merge, with no production consequence you can defend. A successful project may be so confidential that removing the sensitive details removes the engineering problem too.
None of those projects is unimportant. They are simply poor source material for a conversation that keeps asking, “Why?”
Project selection is therefore an act of evidence design. You are choosing a small part of your career that another engineer can inspect for architecture, judgment, ownership, trade-offs, production reality, influence, and learning. The useful project is not the one that creates the grandest opening. It is the one that becomes more credible as the questions get narrower.
This choice comes before the artifacts in the rest of this part. A dossier can recover facts, but it cannot create decisions you did not shape. An architecture narrative can clarify a system, but it cannot repair vague ownership. Begin with the material that can bear the weight.
Start with more than your résumé remembers
Write down six to ten projects from the last several years. Include the obvious launches, but also search the less glamorous parts of the record: migrations, deprecations, incidents, reliability work, cost reductions, security or privacy changes, internal platforms, failed experiments, and cross-team adoption efforts. Senior judgment often appears where the work was messy enough to require a real choice.
Give each candidate five plain lines:
Project: Partner reconciliation migration
Pressure: Retries and late files created duplicate events and manual correction.
My part: I led the service boundary, idempotency model, and rollout sequence.
Consequence: Finance no longer needed the same recurring engineering handoff.
Disclosure limit: Partner names and exact volumes must be removed.
Do not polish these into interview answers. At this stage, polished language can hide a missing fact. The inventory exists to recover possibilities, including work you may have discounted because it was internal, incomplete, or shared across several teams.
Look for pressure, choice, and consequence
Evidence density is the amount of truthful follow-up a project can sustain. A dense project contains pressure, choices, alternatives, boundaries, consequences, and reflection. A thin project eventually reduces every answer to “we shipped it.”
Scale is useful evidence only when it changed something: a data model, a rollout, a failure mode, a coordination path, or the acceptable risk. A large customer count that never touched your decisions is scenery. The same is true of ambiguity. It becomes evidence when unclear requirements, ownership, or success measures forced you to frame the problem and choose a path.
Architecture evidence lets you explain boundaries, data flow, dependencies, failure behavior, and the alternatives that lost. Production ownership carries the story beyond implementation into rollout, observability, incidents, security, privacy, cost, support, or later evolution. Impact connects the work to an observable customer, business, operational, engineering, or organizational consequence. Cross-team evidence shows what changed because you clarified a decision, resolved a dependency, earned adoption, or helped other people act—not merely that meetings occurred.
Learning completes the record. A surprise, reversal, missed assumption, or changed opinion gives the project time and resistance. “It was hard, then it succeeded” does not.
No project needs to be maximal on every dimension. Your primary project does need a clear contribution boundary, inspectable system reasoning, an honest account of impact, and a version safe enough to discuss.
Apply the two vetoes first
Before comparing interesting projects, remove the ones that cannot be used honestly.
The first veto is disclosure. Ask whether you can preserve the problem, constraints, design, trade-offs, result, and lesson after removing customer names, exact private numbers, internal component names, unreleased plans, and sensitive incident details. Replacing identifiers with neutral descriptions is sanitization. Removing the mechanism until only “an internal system” remains is not. If the useful shape cannot survive, choose another project.
The second veto is contribution. For each remaining candidate, finish four sentences:
- I owned …
- I influenced …
- I supported …
- I did not own …
A senior project need not be a solo achievement. In fact, consequential work rarely is. But “we” cannot conceal whether you made a decision, implemented someone else’s design, coordinated a dependency, or inherited the result. A precise boundary makes the team’s work more believable as well as your own.
I owned the idempotency model and rollout sequencing. The data-platform team
owned the ledger service. I influenced the API boundary because partner
retries were creating duplicate settlement events. I did not own the finance
reconciliation rules.
If you cannot write that boundary without either shrinking your role to proximity or expanding it into the team’s role, do not use the project as your primary deep dive.
Audition the primary project
Do not select the primary project from memory alone. Give each serious candidate a fifteen-minute audition, without prepared prose.
Begin with the pressure. Who or what was affected, what was happening before, and why did the work need attention then? Draw the before-and-after system. Name one decision you shaped, one plausible alternative, and the constraint that made the choice difficult. Continue through rollout: what happened under real traffic, adoption, failure, or support? State the strongest outcome you can defend and the evidence behind it. End with something you would change now.
Listen for where the account loses substance. Perhaps the architecture is clear but your role is not. Perhaps the decision is interesting but the story ends at launch. Perhaps the impact sounds precise until you ask where the number came from. Those are selection findings, not speaking flaws.
Narrow an overlarge project before rejecting it. “The three-year platform modernization” may be impossible to own or explain; “the event-contract migration I led during the modernization” may have exact boundaries, alternatives, rollout failures, and consequences. A smaller truthful slice usually survives more scrutiny than a sweeping account held together by job title.
Let one portfolio take shape
Consider Mina, a modeled example with six candidates. Her executive homepage launch is recognizable, but her work was mostly UI integration after product and design had fixed the important choices. A recent database upgrade is technically legitimate but followed a known plan and offers little ambiguity. A security incident contains strong lessons, yet the facts that make it useful are too sensitive to discuss. None belongs in the prepared set.
The partner reconciliation migration behaves differently under audition. Mina can explain why retries created duplicate settlement events, why the team moved idempotency to the partner-event boundary, how a staged rollout exposed late adjustments, which finance and platform decisions she did not own, and why the operational outcome must be stated directionally rather than with private numbers. The project becomes richer, not thinner, as the questions continue. It is her primary.
Her internal observability adoption effort adds a different form of evidence: operating judgment, cross-team influence, and changed on-call behavior. A failed personalization experiment adds product measurement, a mixed outcome, and a changed opinion about counter-metrics. Those projects are not weaker copies of the primary. They make the portfolio wider.
Once you have plausible choices, a small coverage matrix earns its space. It lets you see the set at once rather than scoring each project in isolation.
| Selected project | Architecture and scale | Production | Product and impact | Influence | Failure and learning |
|---|---|---|---|---|---|
| Reconciliation migration | Strong | Strong | Strong | Supporting | Strong |
| Observability adoption | Supporting | Strong | Supporting | Strong | Supporting |
| Personalization experiment | Thin | Thin | Strong | Supporting | Strong |
“Thin” is not a defect when another project carries that evidence. The matrix is a coverage note, not a numerical rubric. Use it to notice duplication and absence. Three architecture-heavy migrations may each be good stories and still form a narrow portfolio.
Give the three projects different jobs
Prepare three projects deeply enough to retrieve their facts, but do not make them equal in size or purpose.
The primary deep dive should survive thirty to forty-five minutes of questions about the system, execution, impact, and your decisions. Choose the candidate that remained coherent during the audition, not the one whose title sounded largest.
The secondary deep dive proves that your judgment travels. It should change the terrain: another domain, operating mode, stakeholder shape, kind of scale, or leadership challenge. Its purpose is contrast, not another polished win.
The reflection project gives difficulty enough room to be examined. It may be a failed bet, incident, painful migration, conflict, missed assumption, or mixed result. Modest scale is acceptable if you can explain what the evidence changed in your later behavior.
One project may support several kinds of interview question. The roles simply prevent you from expecting one career episode to prove everything.
Finish the selection on paper
Set aside about an hour. Inventory six to ten projects, apply the disclosure and contribution vetoes, then audition the strongest two or three. Select the primary, secondary, and reflection projects and record one sentence explaining the job of each. Draw the coverage matrix only after choosing provisionally; otherwise the desire to fill every cell can promote a weak project.
Before moving on, answer these questions aloud for the primary:
- Why did the work matter at that moment?
- What did I own, influence, support, and not own?
- Which constraint made the design or delivery nontrivial?
- What alternative could a reasonable engineer have preferred?
- What happened in production or after adoption?
- What evidence supports the result, and what are its limits?
- What failed, surprised me, or changed my mind?
- Which details must be sanitized, and does the engineering shape remain?
Replace the project if ownership, disclosure safety, or system reasoning collapses. Pair it with another project if only one secondary signal is thin. Then stop ranking. Selection is complete when the portfolio contains three different sources of defensible evidence, not when every possible project has been optimized.
The next step is to build a private dossier for each choice: the facts, constraints, architecture, decisions, execution, results, failures, and later evolution that the audition exposed. That document should preserve the truth of the project before rehearsal turns it into a performance.