Technical Candidate Shortlist Template

A technical candidate shortlist should show why a person merits the next review step, not pretend that a CV can prove engineering ability. Use one record per candidate, preserve the role brief version, and keep source evidence separate from your interpretation. This makes an unusual background discussable without turning a job title, employer name or keyword into a conclusion.

Set the brief before the shortlist

Write the role and brief version at the top of the working document. Define three to five job-related must-haves, then list nice-to-haves separately. For each requirement, describe evidence that would count: a system, technical decision, artefact, responsibility or constraint the candidate can explain. Decide in advance what adjacent experience is worth checking.

Keep technical requirements distinct from boundaries. Location, working pattern and legally required work authorisation belong in their own fields. They should not strengthen or weaken a technical evidence label. Do not add protected or sensitive characteristics, inferred personality, "culture fit" or demographic proxies. A shortlist is for a hiring workflow, not a profile of a person's identity.

Copyable technical shortlist record

Copy this block once for every candidate. Use an internal ID when sharing the document, and include a source URL and review date so another reviewer can trace each claim. Keep the same field order for every record.

Candidate record: [name or internal ID]

Field	Record
Role and brief	Role: [role]; brief version: [v/date]; reviewer date: [date]
Source and candidate status	Source: [CV, referral, LinkedIn, GitHub or other permitted source]; candidate status: [sourced/applied/contacted/replied/opted out/closed]; contact owner: [name]
Technical must-haves	Requirement: [criterion] - evidence: [short source passage or artefact]; label: [supported/adjacent/unknown/contradicted]; source/date: [details]. Repeat for each must-have.
Technical nice-to-haves	Requirement: [criterion] - evidence: [passage, project or artefact]; label: [supported/adjacent/unknown/contradicted]; verification question: [question or none].
Technical ownership and artefacts	What did the candidate own, contribute to, review or operate? Record system scope, design or implementation decision, constraints, tests, deployment, maintenance or incident context, and the artefact to inspect: [details].
Unknowns and conflicts	Missing context, stale source, conflicting dates, unclear authorship or scope: [details]. Do not turn an unknown into a negative finding.
Work sample or interview evidence	Prompt or question: [text]; observed artefact or explanation: [evidence]; follow-up needed: [details]. Record job-related evidence, not personality impressions.
Location and authorisation	Location/time zone: [requirement and evidence]; working pattern: [requirement and evidence]; work authorisation: [required check and status]. Keep this separate from technical evidence.
Duplicate, consent and retention	Duplicate check: [stable URL or internal ID/date]; contact basis or consent/opt-out: [record]; access: [who]; retention or deletion decision/date: [record].
Reviewer and next action	Reviewer: [name]; disposition: [progress/verify/hold/revise/close]; one job-related reason; owner and due date for the next action: [details].

If a candidate has several projects, name the one that supports the criterion rather than listing every repository. Distinguish "used Kubernetes" from "owned a production migration" and "reviewed a change" from "designed and operated the service". A public repository can suggest a useful discussion, but commits, stars, language labels and activity counts do not prove authorship, production ownership or current ability. Ask the candidate to explain decisions and limits instead of treating public activity as a test result.

For the next technical step, keep the prompt tied to the role and give every candidate the same essential question. Record the constraints you gave, the artefact or explanation produced, and what the reviewer could and could not verify. Do not reuse confidential employer code or ask for unpaid production work. If an exercise is unnecessary, use a focused conversation about a named project, trade-off or incident. Keep the candidate's own materials to the minimum needed for the decision, restrict access to the review team, and record when the evidence should be deleted or revisited.

Use labels and calibrate reviewers

Apply labels consistently to each criterion:

Supported: a reliable source directly addresses the requirement in relevant context.
Adjacent: related experience may transfer, but scope, ownership or context needs checking.
Unknown: the available material does not answer the question. It is not evidence that the candidate lacks the capability.
Contradicted: reliable material conflicts with the requirement or another source; record both sides and verify.

Do not convert these labels into a 1-5 score or a percentage that implies precision. A ranking can organise attention, but it does not predict job performance, establish fairness or make the selection decision. For calibration, have two reviewers label the same three records independently, compare disagreements by criterion, and agree one definition or follow-up question. Keep the brief version and change log; revise one requirement at a time.

Where Talent Summoner fits

Talent Summoner is our product. Its Candidate Ranking tool, checked 19 August 2026, accepts up to 50 CVs in PDF, DOCX, MD or TXT format, requires no account and creates a shareable report with plain-English reasoning. Use the report to organise the records above, then inspect sources and run the technical follow-up yourself. It is not an ATS, does not manage an application pipeline and does not automatically reject candidates.

When the pool is incomplete, candidate sourcing starts with a role brief and searches LinkedIn, GitHub and other public professional sources across 200M+ profiles. It returns must-haves, nice-to-haves and plain-English reasoning; feedback can adjust a later search and weighting. Your team still owns duplicate checks, consent, contact and retention. Review pricing for current Role options before purchase.

FAQ

How many candidates should one shortlist record cover?

One. Copy the record block once per candidate so evidence, unknowns, boundaries and ownership stay traceable. A separate index can link to records, but do not combine several people into one evidence cell.

Is missing technical evidence a reason to close a candidate?

Not by itself. Mark the criterion unknown and write a specific verification question. Close only when the reviewer has a job-related reason under the agreed brief.

Should location or work authorisation affect a technical label?

No. Record those requirements in the boundary field. Apply the same technical evidence standard to candidates who meet, do not meet or still need to verify the boundary.

Does Talent Summoner's ranking decide the technical hire?

No. Talent Summoner is our sourcing and ranking product. Its output helps prioritise review; humans inspect evidence, ask technical questions, decide contact and own the hiring decision.

Choose one technical role, freeze its brief version, and create the first candidate record before reviewing names. Then use candidate-ranking for an existing CV pool or candidate-sourcing when you need more relevant profiles.

Talent Summoner product facts read from our live candidate sourcing, candidate ranking and pricing pages, verified 19 August 2026. We re-verify this page quarterly — tell us if something changed.