sample report
What arrives the next morning.
Every session produces this document and only this document. Here is one in full, followed by how to read it.
Illustrative sample. The session, candidate, and examiner shown are invented so that no real person is described. The structure, fields, and level of detail are exactly what a client receives.
EVIDENCE REPORT
Onsite Round · San Francisco · confidential
sessionOR-2026-0142candidate████████████id checkconfirmed · government IDroleSenior backend engineerexaminerJ. ReyeslocationSan Francisco · downtown officedate2026-09-04 · 10:00–11:32 PTai toolsallowed and expected · used Claude, Copilot
problem framingAsked two clarifying questions before writing code; scoped the cache-invalidation edge case unprompted.strong
code fluencyIdiomatic Python throughout; refactored the hot path without prompting.strong
ai tool useDelegated boilerplate to the assistant, reviewed every suggestion, rejected two incorrect completions with reasons.strong
debuggingReproduced the race condition with a minimal script before reaching for the fix.solid
communicationNarrated tradeoffs unprompted; wrote a clear handoff note at the end.strong
The candidate worked the way senior engineers work: framed the problem before touching the keyboard, used AI tools as a multiplier rather than a crutch, and left the codebase better documented than they found it. The skill demonstrated in this session is real and consistent with the submitted portfolio.
J. Reyes
examiner signature · 2026-09-05 · 08:41 PT
VERIFIED
IN PERSON
SF · OR-2026-0142
Every report scores the same five things, in the same order, against the leveling rubric agreed at onboarding. Fixing the dimensions is what makes one candidate's report comparable to the next.
- problem framing
- Whether the candidate understands the problem before solving it: clarifying questions, stated assumptions, scoping of edge cases.
- code fluency
- How naturally they write in the stack you hire for. Idiom, structure, and whether the code would pass your own review.
- ai tool use
- How they work with an assistant. What they delegate, whether they read what comes back, and whether they catch its mistakes.
- debugging
- What they do when something breaks. Reproduce first, or guess? Read the error, or rewrite the function?
- communication
- Whether a teammate could pick up where they left off: narrated tradeoffs, questions asked out loud, the handoff note.
- strong
- Consistent with a senior engineer at the level you are hiring for. No prompting needed.
- solid
- Competent and complete, with one or two moments where a nudge helped.
- developing
- Got there with help, or partly. Worth a conversation with your team about the level.
- not observed
- The session did not produce evidence either way. Stated plainly rather than guessed.
No verdict. The report does not say hire or pass. Your team weighs the observations against everything else you know about the candidate.
No recording. There is no audio or video of the session. The examiner's notes and the code the candidate wrote are the record.
No copy of the ID. The header records that the check was done and what it showed. We do not scan or photograph identity documents.
No comparison to other candidates by name. Levels are calibrated against market and against your rubric, never against another person in your pipeline.