How to assess technical skills: a recruiter’s cheat sheet

TL;DR

• A technical recruiting cheat sheet is a role-to-evidence map, not a glossary. Knowing that React is a JavaScript library helps you read a resume; knowing what proves a candidate can use it helps you hire.
• Work the same three steps for every technical role: write the benchmark, collect evidence with a test or work sample, then confirm depth in a structured interview.
• Structured interviews and job-relevant work samples predict performance better than resume screening, and teams that overrule their own test results hire worse people.
• Most developers now build with AI assistance, so screening has shifted from "can you write this syntax" to "can you tell when the machine got it wrong".
• Every role table below pairs the skills and tools you will see on a resume with the one screening method that actually proves them.

What is a technical recruiting cheat sheet?

A technical recruiting cheat sheet is a quick-reference guide that maps each engineering role to the skills, languages, and tools that define it, plus the evidence that proves a candidate has them. It lets a recruiter who is not an engineer write a sharper job post, screen with better questions, and defend a shortlist.

The version most teams download is a vocabulary list. It tells you that Kubernetes orchestrates containers and that Django is a Python web framework. That is useful for about a week, and then it quietly goes stale. Employers expect 39% of the key skills the job market needs to change by 2030, down from 44% in the 2023 edition of the World Economic Forum Future of Jobs Report, and technology skills are the fastest-moving group in it. A cheat sheet built only on today's tool names ages with the tools.

The part that does not age is the mapping underneath: role, competency, evidence. That is the Testlify Competency-to-Evidence Matrix, which maps every role to the competencies that matter, then connects each competency to measurable evidence through assessments, simulations, interviews, references, and structured reviewer feedback. Start with the role, not with a test. A back-end hire in 2030 will be assessed on different frameworks and the same five questions.

A cheat sheet earns its place when it carries four columns for every role:

• Core competencies. What the person has to be able to do, written as work, not as keywords.
• What you will see on a resume. The languages, frameworks, and tools that signal the role, so you can read the document without guessing.
• What proves it. The screening method that turns the claim into evidence.
• What good looks like. The benchmark you set before the first application lands.

This guide is written for the team that has no engineering bench to lean on: a recruiter, an agency partner, or a founder screening engineers between everything else. Teams under a couple of hundred people rarely have a staff engineer free to sit in on first-round calls, and they are the ones who pay hardest for a wrong hire.

How do you assess technical skills as a recruiter?

Assess technical skills in three layers. Write a role benchmark with the hiring manager before you post. Collect evidence with a scored skills test or work sample that mirrors the job. Then confirm depth in a structured interview where every candidate answers the same questions and each answer is scored against the benchmark.

The order matters more than the tools. Most bad technical shortlists are not a tooling failure, they are a definition failure: nobody wrote down what "good" meant, so five people applied five private standards.

Define the role benchmark first

Sit with the hiring manager for 30 minutes and get three things on paper. First, the five competencies the role fails without. Second, the level for each one, stated as work ("can own a service in production" beats "senior"). Third, the cutoff: the score or the standard below which a candidate does not advance, agreed before anyone sees a name. A structured hiring plan makes this repeatable across a whole req list rather than a one-off conversation.

Write the benchmark as a sentence a non-engineer can check. "Can write a SQL query that joins three tables and explain why it is slow" is checkable. "Strong SQL skills" is not.

Run a skills test or work sample

Job-relevant evidence beats a credential. In the reanalysis of personnel-selection meta-analyses by Sackett and colleagues, summarized by the Society for Industrial and Organizational Psychology, structured interviews come out at a validity of .42 and general cognitive-ability tests at .31, which put job-specific methods (structured interviews, job-knowledge tests, work samples) ahead of the general measures the field had ranked first for decades.

In practice that means a scored coding task built from the actual work outperforms a puzzle, and both outperform a conversation about a resume. Keep the task inside 45 minutes for early-career roles and 90 for senior ones, and tell candidates the time cost before they start. Skills tests that shorten the interview loop only pay off if the shortlist is scored before the first call, not after it.

Confirm depth in a live interview and portfolio

A test tells you whether someone can do the work. A structured interview tells you how they think about it, and a portfolio or repository walk-through tells you what they choose when nobody is scoring them. Ask a candidate to talk through a decision they would now make differently. The engineers worth hiring have one ready.

Then hold the line on the benchmark. Managers who overrule their own testing get worse hires: in Discretion in Hiring, a study of job testing across 15 firms (Hoffman, Kahn and Li, 2015, later published in the Quarterly Journal of Economics), a one standard deviation increase in the rate of exceptions to test recommendations was associated with about a 5% drop in job tenure. That research ran in high-turnover service roles rather than engineering, so treat the size of the effect as borrowed. The mechanism travels anyway: gut feel is not free, and it costs most on the roles you understand least.

Which skills matter for each technical role?

Ten roles cover the large majority of what a generalist recruiter screens. Each one below carries the same four columns: what the person does, what you will see on the resume, the question that separates depth from vocabulary, and the evidence that settles it.

Front-end developer

Front-end engineers own what the user touches. JavaScript is still the most used language in the 2025 Stack Overflow Developer Survey at 66%, with React used by 44.7% of respondents, so most front-end resumes rhyme. The separator is not the framework list. Ask how they made a page faster, and listen for a measurement: bundle size, render time, a number. Candidates who only name tools have used them, not owned them. Accessibility is the fastest honesty check available to a non-technical screener, because a candidate who has never shipped for screen readers cannot fake the specifics.

Back-end developer

Back-end work is data and consequences. The resume will list a language and a database, and both are easy to claim. A Python coding test with hidden test cases settles the syntax question in 40 minutes, which frees the interview for the part that matters: how they would model the data, what they would do when a query gets slow, and what happens when the third-party API they depend on goes down. Ask what they would log. Weak candidates log everything or nothing.

Full-stack developer

Treat "full-stack" as a claim to verify, not a level. Almost everyone is stronger on one side. Ask which side, and the good ones tell you plainly. The screening move is a small feature that crosses both layers, then a conversation about what they deliberately left out, because a full-stack hire lives on tradeoffs. A senior React developer test works as the front-end half of that evidence for teams hiring on a JavaScript stack.

Mobile developer

Mobile carries constraints web developers never meet: an app-store review that can block a release for days, devices with no network, and a user base that does not upgrade. Ask what they do when a release is rejected, or how they handle a screen that has to work offline. Cross-platform experience (React Native, Flutter) is not the same as native depth in Swift or Kotlin, and the difference shows up when performance matters.

DevOps or SRE

This is the role where a certification list misleads most often. The competency is judgment under pressure. Ask about the last production incident they handled: what broke, how they found it, what they changed afterwards. Specifics arrive fast from people who have carried a pager, and slowly from people who have read about it. A GCP DevOps engineer test covers the tooling layer, and the incident story covers the part a test cannot reach.

Data engineer

Data engineers get judged on other people's deadlines. SQL is the third most used language in the 2025 survey at 58.6%, and a SQL task is the cheapest high-signal screen in this whole list. Ask what they did the last time a nightly pipeline failed at 3am and finance needed the report by 9. Listen for whether they fixed the data, the pipeline, or the expectation, because all three are legitimate and knowing which to reach for is the skill.

Data scientist or ML engineer

Two different jobs share one title. A data scientist answers questions with data; an ML engineer puts a model into production and keeps it alive there. Ask which one the team actually needs before you screen anybody, then score on method rather than model names. The strongest signal in a case exercise is a candidate volunteering what their result cannot support. Overclaiming on a small sample is the single most common disqualifier here.

QA automation engineer

Good QA engineers think in failure modes, which makes them unusually easy to screen with a written exercise: hand over a one-paragraph feature spec and ask what they would test and in what order. Weak candidates list the happy path. Strong ones ask about the boundary conditions and what happens when two users do the same thing at once. Ask how they handle a test that fails one run in twenty, since tolerating flaky tests is how a suite dies.

Security engineer

Security candidates are screened badly more often than any other role on this list, usually by counting certifications. Ask them to threat-model something ordinary, a password reset flow will do, and listen for whether they reason about the attacker's incentive rather than reciting a checklist. Compliance knowledge (SOC 2, ISO 27001, GDPR) is real work and worth confirming, but it is a different competency from finding the flaw, and a resume rarely separates the two.

Cloud or platform engineer

Platform engineers build for other engineers, so the competency includes empathy for the internal user. Ask what they removed from a platform, not only what they built. A cost question works well: what would they do if the cloud bill doubled in a quarter? The answers separate people who have owned a budget from people who have only had a console login.

Pro tip: keep a single shared document with these four columns per open req, and make the hiring manager sign the "what proves it" cell before the job goes live. It takes ten minutes and it kills the two arguments that eat the most time later: whether the test was fair, and whether the bar moved.

How do you screen developers who code with AI?

Screen for judgment, not recall. In the 2025 Stack Overflow Developer Survey, 84% of respondents use or plan to use AI tools, up from 76% the year before, and 51% of professional developers use them daily. The job changed, so the screen has to change with it: the work is now reviewing, correcting, and deciding.

The same survey is blunt about why that matters. More developers distrust the accuracy of AI output (46%) than trust it (33%), and the top frustration, named by 66%, is AI solutions that are almost right but not quite, with debugging that near-miss code the next complaint at 45%. "Almost right" is exactly the failure mode a junior engineer cannot catch and a good one can.

Three screens hold up in that world:

1. Code review of generated output. Hand the candidate working-looking code with a real flaw (an off-by-one, an unhandled null, a query that will not scale) and ask what they would change before it ships. This is the closest thing to the daily job in 2026.
2. Debugging under observation. Give them something broken and watch the sequence, not the speed. Strong engineers narrow the search space; weak ones change lines and hope.
3. Explain-the-choice questions. Ask why the solution is shaped that way. Borrowed answers fall apart on the second follow-up, whether they were borrowed from a colleague or a model.

Banning AI tools in a take-home is the wrong instinct, and it is unenforceable anyway. It is more honest to set the rule explicitly and then test what the rule implies. Testlify supports this directly: alongside standard coding questions with up to 20 visible or hidden test cases and an embedded VS Code editor, it ships vibe coding questions, where candidates direct AI tools toward a working solution instead of writing syntax by hand, and an AI checker that classifies an answer as human, AI generated, or mixed. Assessments can allow AI, forbid it with AI-tool detection, or score the candidate on how well they use it.

The caveat worth stating: none of this proves intent. A flag is evidence for a human to read, not a verdict, and any screen that auto-rejects on a detection signal will throw away good candidates. Testlify's own reviewer copy says it plainly, that AI scores and insights are for guidance only and human judgment makes the final call.

Which screening method proves which skill?

Every method proves something narrow and misses something else. Picking two that overlap is the most common waste in a technical loop, and running four is how a pipeline stalls.

Two methods, chosen from different rows, beat four that crowd the same column. For most roles that is a scored test plus a structured interview, with a code review exercise replacing the test for senior hires. The main types of technical assessment differ mostly in what they can and cannot see, which is the column that should drive the choice.

Candidate time is a real cost. A four-hour take-home on a 45-minute role screen loses the people with options first, and they are usually the people you wanted. If a stage cannot name the competency it proves, cut it.

What does a technical hiring scorecard include?

A technical hiring scorecard lists every competency in the benchmark, the evidence source for each one, a numeric rating, the reviewer who gave it, and the cutoff agreed before applications opened. It converts opinions into a comparable record, which is what makes a rejection explainable and a shortlist defensible.

A workable scorecard for an engineering role has five rows and four columns. Rows: core role skill, problem-solving, code quality or system design, collaboration and communication, and role context (domain, scale, or compliance knowledge the job needs). Columns: the evidence, the score, the reviewer, and a one-line note. Weight the rows before the first candidate, because weighting them afterwards is just rationalizing a preference.

Three rules keep it honest:

• Score independently, then discuss. Reviewers who compare notes first converge on the loudest opinion in the room.
• Write the cutoff down. A cutoff nobody recorded is a cutoff that will move for the candidate everyone liked.
• Keep cutoffs local. A passing score is specific to your role, your team, and your market. Borrowing one from a vendor benchmark or another company's rubric produces confident nonsense.

Testlify supports this end of the process with weighted scoring (a test can be weighted from x0 to x5 against the final score), skill-level breakdowns, multiple-reviewer scoring with aggregated results, percentile benchmarking against other candidates, and score thresholds that gate a stage change. AI-generated summaries sit alongside the human scores and can be excluded from the final average entirely, which is the setting most teams should start with.

How do you hire software engineers on campus?

Campus hiring inverts the usual problem. Volume is high, resumes are nearly identical, and almost nobody has shipped production code, so the signals that work mid-career are unavailable. Screen on aptitude and a small scored task rather than experience, and measure the funnel rather than the anecdotes.

The market context is worth carrying into that conversation with a hiring manager. The U.S. Bureau of Labor Statistics projects employment of software developers, quality assurance analysts, and testers to grow 10% from 2025 to 2035, with about 106,100 openings a year on average over the decade and a 2025 median wage of $134,040. Entry-level pipelines are competing against that number, which is why a slow campus process loses.

Campus recruitment KPI cheat sheet for software engineer hiring

Track six numbers per campus cycle. They are cheap to collect and each one points at a different fix.

That last row is the one teams skip, and it is the only one that tells you whether the rest of the cheat sheet is working. Check it once a year against the cohort you hired, and adjust the benchmark rather than the story you tell about it.

What mistakes should you avoid?

Testing trivia instead of the job

Algorithm puzzles that never appear in the work select for interview practice, not performance, and they filter out career-changers and returners first. If the role does not require balancing a binary tree, do not ask for one. Build the task from a ticket the team closed last month.

Letting one interviewer decide

A single reviewer is a single point of failure, and the research on overruling structured evidence points the same way. Two independent scorers on the same rubric catch more and argue less, because they are arguing about a number and its evidence rather than about a feeling.

Ignoring communication and collaboration

Engineers spend a large share of the week explaining decisions to other people. Score communication as its own row on the scorecard, with evidence, instead of treating it as a tiebreak when two candidates score the same on code.

Skipping the benchmark

Without a written benchmark, every stage drifts toward whoever interviewed most recently. The benchmark is also what makes a rejection explainable, which matters more every year as hiring decisions attract more scrutiny. Assessing technical skills across a whole team is mostly the discipline of writing the standard down before you need it.

Assess technical roles with confidence

Pick one open engineering req this week, write its four cheat-sheet columns with the hiring manager, and attach a scored task to the first stage. Testlify has role-based coding assessments (the front-end, back-end, and DevOps tests linked above are live examples), plus video and voice interview formats that transcribe an answer and score it for a human to review. Book a demo to see it against your own roles, or start free with Testlify and build the first assessment today.

Key takeaways

• A cheat sheet is a map from role to evidence. Tool lists age with the tools (39% of key skills are expected to change by 2030), so the durable asset is the four-column mapping of competency, resume signal, proof, and benchmark. Rebuild the tool column yearly and the rest will hold.
• Write the benchmark before the job posting. Most weak technical shortlists come from an undefined standard, not a bad test. Thirty minutes with the hiring manager, five competencies, one cutoff, and the later arguments about fairness mostly disappear.
• Job-relevant methods beat general ones. Structured interviews rate .42 for validity against .31 for general cognitive-ability tests, so build the task from real work. Run a scored test plus a structured interview, not four overlapping stages.
• Do not overrule your own evidence. A one standard deviation rise in exceptions to test recommendations tracked with about 5% shorter tenure. If the benchmark is wrong, change the benchmark on the record, rather than making a quiet exception for a candidate you liked.
• Screen for judgment now that 84% of developers work with AI tools. Code review of flawed output, observed debugging, and explain-the-choice questions test the work as it is actually done. Set the AI rule explicitly instead of pretending the tools are not there.
• Measure the campus funnel, then close the loop. Six KPIs cover it, and first-year retention of the cohort is the only one that tells you whether the screen predicted anything. Re-weight the assessment against what the people who stayed scored well on.

FAQs