An unsuccessful project can contain both defensible decisions and preventable mistakes. Assess the candidate’s specific contribution rather than treating the outcome as the verdict.
Assess a senior engineer’s work sample by examining the decisions, execution, and accountability they can substantiate, separately from the business outcome. A failed project can demonstrate sound engineering judgment. Failure itself proves nothing.
For candidates, the question is: Which project makes my contribution and judgment most verifiable? For reviewers, it is: Was this a defensible decision that turned out badly, or a preventable mistake explained away afterward?
Record three things separately: what happened, what the candidate contributed, and what the evidence supports.
Start with the outcome, then establish ownership
Name the failure plainly. State the intended result and what happened: the launch was canceled, adoption missed its target, a requirement was unmet, or costs exceeded the agreed limit.
Then establish scope:
- What did the candidate own, recommend, implement, or approve?
- What could they decide independently?
- Which constraints and decisions belonged to others?
- What did teammates contribute?
Ownership does not excuse the outcome. A missed requirement may expose weak engineering work, or an assumption that was reasonable to test and proved false. The evidence must distinguish between them.
If the candidate did not own a decision, ask: What responsibility did you have to identify, communicate, or mitigate its risks? Limited authority changes accountability. It does not eliminate it.
Separate evidence from explanation
A polished retrospective explains the candidate’s reasoning now. It does not, by itself, establish what they knew or did then.
Label the support behind each important claim:
| Evidence type | Examples | What it supports | Limitation |
|---|---|---|---|
| Contemporaneous artifact | Dated proposal, review comment, test report, decision log | What was documented or observed at the time | May be incomplete, selectively presented, or jointly authored |
| Corroborated account | Permitted reference or teammate account | Additional support for ownership, context, or behavior | Recollections can differ; corroboration is not proof |
| Retrospective explanation | Interview narrative, case study, reconstructed diagram | How the candidate now explains the work | Does not independently establish past actions or beliefs |
Do not demand confidential materials. Accept authorized redactions, sanitized summaries, or clearly labeled reconstructions. Ask what was changed or omitted and which conclusions remain verifiable.
A lack of shareable artifacts is not evidence of weak engineering. It limits what this sample can establish. Record that limit rather than rewarding disclosure or penalizing confidentiality.
Use a failed-project assessment sheet
Apply the same dimensions to successful and unsuccessful projects. Otherwise, success can become a free pass while failure receives unusually strict scrutiny.
| Dimension | Evidence to request | Counterevidence to examine | Limit on the conclusion |
|---|---|---|---|
| Decision quality at the time | Problem definition, constraints, alternatives, assumptions, and reasons for the choice | Available warnings ignored; alternatives dismissed without examination; assumptions treated as facts | A sound process does not prove the design was optimal |
| Execution quality | Implementation details, tests, reviews, rollout controls, and evidence against requirements | Untested critical paths; unresolved defects; missing checks; claimed behavior not implemented | One component does not establish quality or ownership of the whole system |
| Response to contradictory evidence | First adverse signal, when it became visible, and subsequent investigation, revision, escalation, or stop decision | Changed success criteria; unjustified continuation; unfavorable findings minimized | A strong retrospective does not prove adaptation during the project |
| Accountability for preventable mistakes | Specific mistake, why it was preventable, candidate’s role, and evidence of repair or changed practice | Vague admissions; blame shifted entirely to others; unsupported claims of fixes | Candor supports transparency, not necessarily improved execution |
For each dimension, record a rating:
- Strong: Evidence shows sound judgment or execution under the relevant constraints.
- Adequate: Evidence supports the role’s expectations, with bounded gaps.
- Concern: Specific evidence shows an avoidable weakness relevant to the role.
- Unknown: There is not enough support to judge.
Record confidence separately, with a short justification, supporting evidence, and an unresolved question. Do not average “unknown” into a numerical score. Missing evidence and demonstrated weakness are different findings.
For a senior role, ask whether the sample demonstrates the scope you need: framing an ambiguous problem, identifying risks, coordinating decisions, or setting boundaries. Do not infer these abilities from code complexity or a title.
In the hypothetical pilot, a known retry-related duplicate-write risk was deferred without a compensating check. That execution concern is separate from whether canceling the pilot was justified.
Worked example: a canceled automation pilot
Hypothetical scenario: Before an internal automation pilot, a team agrees that the workflow must remove at least half of its manual review steps to justify proceeding. The pilot removes only a quarter, and the project is canceled.
Assume the candidate provides this authorized, redacted evidence packet:
- A dated proposal identifies exception handling as the largest uncertainty and recommends a limited pilot before broader integration.
- Review records attribute the pilot design and validation plan to the candidate. A teammate owned the core processing component.
- Pilot findings show that exception cases prevented the workflow from meeting the agreed threshold.
- A decision note records the candidate’s recommendation to stop after those findings.
- A retrospective identifies a retry-related duplicate-write risk the candidate left unaddressed. A review comment had raised it before the pilot, but the candidate deferred it without a compensating check.
The candidate says they later added a regression test for duplicate writes, but offers no supporting evidence.
The assessment is mixed:
| Dimension | Finding | Reason |
|---|---|---|
| Decision quality | Strong within the pilot’s scope | Identified a material uncertainty and limited the investment needed to test it |
| Execution quality | Concern | Deferred a known correctness risk without a compensating check |
| Response to contradictory evidence | Strong | Recommended stopping after unfavorable findings, using the original threshold |
| Accountability | Acknowledgment supported; repair unknown | Identified their own preventable mistake, but did not substantiate the claimed fix |
The business outcome remains a failure. Yet the records support good uncertainty management and a justified stop decision, alongside a real execution concern.
Neither cancellation nor candor determines the verdict. Each finding rests on a distinct action and supporting record. The panel must decide how relevant the execution concern is to the role.
Review one claim before making the hiring judgment
Use this short exercise with a panel or mentor:
- Choose a consequential claim. For example: “I recognized the integration risk early.”
- Identify its support. Was it documented at the time, corroborated, or explained only afterward?
- Consider a competing explanation. Did someone else raise the risk first? Was the warning specific enough to act on?
- Write the narrowest supported conclusion. “The candidate documented the risk before implementation” is more defensible than “the candidate has excellent foresight.”
- Name the next question. What decision changed because of the warning?
Have reviewers write initial assessments independently before discussing them, so the panel can compare explicit reasons rather than start from a shared impression.
If a critical dimension remains unknown, use an additional role-relevant exercise or interview question. Do not ask the candidate to fill an evidence gap with a more persuasive narrative.
Candidate checklist: is this project ready to submit?
Choose a failed project when you can make these points clear:
- Outcome: I state the original goal and actual result plainly.
- Ownership: I distinguish my contribution from the team’s work.
- Timeline: I separate what I knew then from what I learned later.
- Tradeoff: I explain a consequential choice and a plausible alternative.
- Evidence: I have permissible support for central claims and label reconstructions honestly.
- Contradiction: I show how I responded when evidence challenged the plan.
- Mistake: I identify preventable errors fairly, including my own, without inventing a redemption story.
- Limits: I say what the sample cannot establish.
Choose the sample that best supports assessment for the role, not the one with the happiest ending. If the failed project depends mostly on unverifiable claims, a narrower sample with clearer ownership may be better.
Use this checklist to prepare your work sample, then explore Skills Tech Network.