A technical screen is a short, early check that a candidate can do the core technical work of a role, run before the full interview loop is scheduled. Formats vary: a live coding exercise, a systems or architecture discussion, or a walkthrough of code and projects the candidate already owns. It verifies a floor rather than deciding a hire.
It decides one thing: whether there is enough technical substance here to justify several people's time in a full loop. That is a floor test, set at the level of the job rather than at the level of the strongest person on the team. Leave everything else alone. Seniority, design depth, collaboration and ownership belong in the loop, where there is time to explore them and more than one observer. Screens that try to do everything become ninety-minute marathons that reject people on nerves. Keep it to forty-five minutes or an hour, ask two or three things tied closely to daily work, and write a recommendation supported by evidence. The output should read as advance or do not advance, plus a note on what the loop ought to probe next.
Different person, different question, different failure mode. A recruiter phone screen confirms interest, availability, location and compensation range, and takes a first read on communication and motivation. A technical screen is run by somebody who does the work and tests whether the candidate can do it too. Running them in the wrong order wastes everyone: technically screening a candidate whose compensation expectations sit outside the band burns an engineer's hour for nothing. Run the recruiter screen first, always. Where recruiter screens go wrong is trying to judge technical depth from a keyword checklist, which rejects strong people who describe their work in unfamiliar vocabulary. Give recruiters a short list of qualifying questions written by the hiring team, and route judgement calls onward instead of resolving them alone.
Match the format to what the job actually demands. Live coding suits roles where implementation speed and correctness matter daily, though the problem should stay small and candidates should use their own editor and documentation. A systems or architecture discussion suits senior and infrastructure roles where the work is judgement under constraints rather than typing. A repository or portfolio walkthrough suits people with substantial previous or public work, and it is the kindest option for candidates who interview badly against a timer. Data and analytics roles often screen better with a short query exercise against a realistic schema. Whichever you pick, use the same format for every candidate on that requisition, or results are not comparable. Publish it in the [job description](/job-descriptions) so nobody arrives surprised.
Use a fixed problem set and a written rubric, and rotate problems in batches so a whole cohort of candidates meets the same bar. Two or three approved problems per role is plenty; more variety produces more variance. Every screener submits a score against the same criteria plus written evidence, on the same day. Review pass rates per screener each quarter, because the screener who passes almost nobody and the one who passes almost everyone are both feeding the loop bad input. Train screeners before they run solo, and track which problems are in circulation so a returning candidate does not receive the same task twice. Holding all of this against the requisition in your [hiring software](/hiring-software) beats a spreadsheet only one engineer maintains.
Pitch N Hire unifies sourcing, screening and hiring decisions on one AI-native platform. Book a quick demo on your real roles.
Prefer to talk? Book a demo · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
