# Make every score explain itself.

Canonical: https://axiomcx.dev/guides/technical-interview-scorecard/
Publisher: Axiom Cortex / TeamStation AI
Content reviewed: 2026-09-26

A useful technical interview scorecard links each role criterion to a question, the expected evidence, and the candidate’s actual answer. Record what was supported, what remains unknown, and which follow-up would resolve the gap. Keep untested criteria separate from demonstrated weaknesses, and review the source before making a decision.

We use science to align tomorrow’s IT talent with the work ahead.

## Define the work first.

Start with the decisions the engineer will own. If your notes are messy, check the source before scoring. Connect each must-have to a question and the evidence a strong answer should show. An ideal answer is a set of relevant criteria, not a script to repeat.

### Role criterion

A job-relevant requirement, such as designing recoverable services.

### Expected evidence

Mechanisms, constraints, tradeoffs, and checks that address that requirement.

### Fair opportunity

A question and follow-up that gave the candidate room to show the evidence.

## One finding, from source to follow-up.

Synthetic system-design example. It demonstrates the review structure; no candidate evaluation engine ran and no numerical score is claimed.

A source-linked criterion review

| Field | Illustrative entry |
| --- | --- |
| Role criterion | Designs resilient services and explains recovery tradeoffs. |
| Question | How would you handle failure in a distributed service? |
| Expected evidence | Failure isolation, bounded retries, observability, and a recovery tradeoff. |
| Candidate excerpt | “We isolated the worker, bounded the retries, and watched queue depth. I added backpressure when downstream storage slowed.” |
| Source reference | Synthetic transcript, Q3, 19:12; candidate speaker. |
| Opportunity | Valid opportunity for the broad question; recovery tradeoff needs a follow-up. |
| Support | Partially supported. Mechanisms and ownership are stated; recovery tradeoff remains unresolved. |
| Follow-up | When would you stop retrying, and what would that choice mean for users? |
| Reviewer action | Inspect the source, ask the follow-up, and update the finding. |

## A gap is not a contradiction.

### Supported

The supplied interview contains relevant evidence for the criterion.

### Partially supported

The evidence addresses part of the criterion but leaves material elements unresolved.

### Contradicted

The candidate explicitly provides evidence that conflicts with the criterion.

### Not observed

The supplied interview does not contain enough relevant evidence for the criterion.

### Not evaluable

The source, attribution, opportunity, or transcript quality cannot support a responsible determination.

Keep opportunity and ownership beside support. An unasked question is an assessment gap. A team outcome doesn’t automatically prove personal contribution. Keep the source info beside the finding.

## Use the structure in your next interview.

The blank template records the question, source, support, ownership, and follow-up. It is an evaluation blueprint, not Axiom’s private scoring equations or a validated standalone assessment.

[Download the blank scorecard](/guides/technical-interview-scorecard/template.md)

### Before you assign a score

- Confirm that the criterion is relevant to the actual role.
- Check whether the candidate had a fair chance to address it.
- Read the full answer around the excerpt.
- Separate personal ownership from a team result.
- Record missing evidence before deciding what it means.
- Use the configured evaluation policy and retain human review.

- [Inspect the public evidence fields](/data/evidence-model.json)
- [Read the report contract](/knowledge/report-contract.md)

## Keep exploring

- [inspect a complete evaluation example](/evaluation/)
- [review the evaluation method](/processing-engine/)
- [prepare interview evidence](/guides/interview-transcript/)

[See the report example](/evaluation/)