Assess the quality of a specific contribution separately from confidence in its attribution; neither finding establishes ownership of the team’s entire result.
To assess an engineer’s contribution to a team project, separate the team’s outcome from the candidate’s actions, collaborators’ roles, supporting evidence, and remaining uncertainty. Then assess engineering judgment separately from confidence in the claimed contribution.
The candidate does not need to claim the whole project. The question is whether the available evidence supports the capabilities required for the role.
Examine a contribution, not ownership of the result
“I led the migration to a new payment service” suggests responsibility but leaves the work unclear. Did the candidate choose the architecture, implement a component, plan the rollout, or coordinate dependencies? Several people could have led different parts.
Ask a narrower question:
“Which decision or action should we examine to understand your contribution?”
This leaves room for testing, review, incident diagnosis, and helping teammates make sound decisions. Original authorship is not the only meaningful work.
Keep three distinctions visible:
- The team’s outcome provides context.
- The candidate’s actions are the proposed evidence of capability.
- The explanation connects those actions to the outcome, without necessarily establishing a precise share of credit.
A candidate may demonstrate sound risk assessment without proving that their safeguard caused the project’s entire improvement.
Use the five-field shared-work worksheet
Complete these fields for one relevant project or project slice. Candidates can prepare them in advance; reviewers can use them as interview notes.
| Field | What to record | Useful prompt |
|---|---|---|
| Team outcome | Goal, reported result, and constraints | What changed, and how was it evaluated? |
| Candidate action | Specific decisions, implementation, analysis, review, or coordination | What did you personally propose, change, evaluate, or resolve? |
| Collaborators’ roles | Others’ responsibilities, shared decisions, and approval boundaries | Who designed, built, challenged, approved, or operated the relevant parts? |
| Permission-safe supporting evidence | Artifacts or corroboration the candidate is authorized to share | What can a reviewer inspect, and which claim does it support? |
| Remaining uncertainty | Claims, attribution, or outcomes that remain unclear | What should we avoid concluding? |
Do not skip the last field. “Authorship is unverified” and “the candidate lacks design skill” are different findings.
Attach evidence to specific claims
For each artifact, record the claim it supports, the candidate’s role, the relevant section or change, and any limitations, such as redaction or reconstruction.
A code change may support an implementation claim without establishing who chose the architecture. A review thread may show that someone identified a risk without proving its effect on the outcome.
Request only material the candidate is authorized to disclose. Redaction alone does not establish permission. Do not ask for confidential code, customer records, or credentials.
A labeled reconstruction using synthetic data can help assess present reasoning. It does not independently verify historical authorship.
Score judgment and verification separately
Record two findings, not one blended score.
Axis 1: Demonstrated engineering judgment
Agree on role-relevant dimensions before reviewing candidates.
| Dimension | What to look for |
|---|---|
| Problem framing | A clear goal, relevant constraints, and a distinction between symptoms and underlying problems |
| Tradeoff reasoning | Alternatives considered, costs accepted, and reasons the choice fit the available information |
| Execution and validation | A concrete approach, appropriate checks, and attention to failure conditions |
| Collaboration | Clear responsibility boundaries, use of others’ expertise, and handling of disagreement |
| Learning and adaptation | Recognition of limitations and evidence that would change the approach |
Rate each dimension:
- Not yet assessable: The discussion or evidence does not expose the relevant reasoning.
- Partially demonstrated: Some reasoning is visible, but important assumptions or consequences remain unexplained.
- Demonstrated: The candidate connects actions to constraints, explains alternatives, and addresses material limitations.
These labels describe what was demonstrated, not whether it meets the role’s bar. Define the required scope and complexity separately. For a senior role, that might include reasoning across dependencies or coordinating decisions across responsibility boundaries.
Axis 2: Verification confidence
Rate each material claim, not the candidate as a whole:
- Uncorroborated: Supported by the candidate’s account only.
- Partially corroborated: An artifact or permitted reference supports part of the claim, but attribution or scope remains unclear.
- Corroborated within stated limits: Available evidence supports the specific action, with explicit limits on what it establishes.
Strong evidence of authorship does not guarantee strong judgment. Sound reasoning in an interview does not verify historical attribution.
In the hypothetical migration, compatibility checks precede rollout stages and a return path represents rollback planning. These safeguards provide a concrete focus for assessing risk reasoning, without proving the reported reliability improvement.
Worked example: a migration with shared responsibility
Hypothetical example: A candidate submits a service migration for a senior engineering role. Assume they have permission to share a sanitized design excerpt and review discussion, but no production code or operational records.
The initial claim is: “I led the migration and made the service more reliable.”
| Field | Example entry |
|---|---|
| Team outcome | The team completed a staged migration. The candidate reports fewer migration-related incidents afterward, but operational records are unavailable. |
| Candidate action | Proposed a compatibility check before each rollout stage and wrote the rollback criteria. |
| Collaborators’ roles | Another engineer designed the target service. Two teammates implemented adapters. An operations colleague reviewed rollback feasibility; the technical lead approved the rollout. |
| Permission-safe supporting evidence | An authorized excerpt attributes the compatibility proposal to the candidate. A review discussion records their revisions to rollback criteria after feedback. |
| Remaining uncertainty | The packet does not establish the reliability improvement or how much any safeguard contributed to it. |
Useful follow-up questions:
- Which incompatibility was the check intended to catch?
- What could still fail after the check passed?
- Why were those rollback criteria preferable to the alternatives?
- What changed after the operations review?
- Which part should be credited to someone else?
If the answers explain these mechanisms coherently, an assessment could read:
“Demonstrated rollout-risk reasoning in the discussion. The excerpts corroborate the compatibility proposal and revisions to rollback criteria. The broader reliability outcome remains unverified.”
This identifies a capability, its supporting evidence, and the boundary of the conclusion. It neither awards credit for the whole migration nor dismisses the contribution because someone else designed the architecture.
Choose a follow-up that addresses the gap
Use the same core worksheet and role criteria across candidates, while allowing different authorized evidence formats. A public repository should not become an unstated requirement for demonstrating confidential work.
| Gap | Appropriate follow-up |
|---|---|
| Historical attribution is unclear | Request an authorized artifact or, with the candidate’s consent, a reference who can speak to that specific action. |
| Technical reasoning is unclear | Change a constraint and ask the candidate to revise the approach. |
| Relevant capability is not observable | Offer a bounded exercise using synthetic inputs and isolated test resources. |
| Team outcome cannot be verified | Keep it as reported context, not an established individual achievement. |
A new exercise can demonstrate current capability. It cannot retroactively prove historical work. If evidence remains insufficient for a role requirement, record that limitation rather than concluding the skill is absent.
Prepare a packet a reviewer can use
Before an interview, choose one project slice and complete the worksheet. Label each claim as a team outcome, personal action, collaborator contribution, or interpretation. Rewrite sentences that blur those categories.
Then ask a mentor to select one claim and challenge it: “What supports this, what else could explain the result, and what remains unknown?”
The goal is not to make every claim bigger. It is to make the strongest supportable contribution easy to inspect, without erasing the people who helped deliver it.
Use your completed worksheet to build a proof-backed profile with Skills Tech Network.