Read a Candidate Report

A report has four parts: the score, the dimensions, the evidence, and the timeline. Read them in reverse.

Start with the timeline

The timeline is the assessment replayed as a sequence of events — prompts, agent responses, edits, test runs, reverts, terminal commands. Scan it before you look at any number.

Ninety seconds in the timeline tells you whether the candidate worked in a way you would want on your team. The score tells you how it came out.

Then the evidence

Every subjective finding in a Ducker report points at something that happened. Not "the candidate seems senior" but:

The candidate independently identified a concurrency issue before the AI raised it, requested transactional protection, and added a concurrent integration test.

If a finding has no evidence behind it, it is not a finding. Click through — each one links to the moment in the timeline it came from.

Then the dimensions

Eight scores: correctness, code quality, architecture, edge cases and reliability, security, testing, AI collaboration, efficiency. See How Scoring Works.

The shape matters more than the total. A candidate at 95 correctness and 55 testing is a different hire from one at 75 across the board, even at the same overall score.

The overall score last

One number, and a recommendation. Useful for sorting a large batch. Not useful for making the decision — that is what the three sections above are for.

Strengths and concerns

Every report lists both. The concerns are the more useful half, and they are worth taking to the interview:

Did not consider observability. Some validation was added only after the AI suggested it.

Both are excellent interview questions. Neither is a reason to reject on its own.

What a report cannot tell you

Whether they will work well with your team. Whether they want the job. Whether they will still be motivated in eighteen months. Ducker measures engineering behaviour under time pressure, and nothing else.