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. A useful cheat sheet should turn the job description into a clear set of hiring criteria:

• 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 these job-specific methods ahead of others.

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 resume can show that a candidate has worked with a technology, but it rarely tells you how deeply they understand it. Use the interview and portfolio to move from claimed experience to evidence.

Ask candidates to walk you through a project they personally worked on. Probe their decisions, tradeoffs, problems they encountered, and what they would change if they built it again.

The portfolio should support those answers with real examples. Look for work that shows how the candidate applies their skills, not just a list of tools or technologies they have used.

Pay close attention to ownership. Candidates who genuinely did the work should be able to explain the reasoning behind key decisions without relying on vague team-level descriptions.

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 resumes tend to look similar because candidates often list the same languages and frameworks. The better question is whether they can use those tools to solve real problems.

Ask how they improved page performance, what they measured, and what changed after the fix. Accessibility is another useful depth check because candidates with real experience should be able to explain semantic HTML, keyboard navigation, screen readers, and common accessibility tradeoffs without falling back on generic answers.

Use the frontend developer test to screen core HTML, CSS, and JavaScript skills before the interview. For React-focused roles, the React developer test adds a more targeted assessment of React, JavaScript, HTML, CSS, and related development skills.

Back-end developer

Back-end development is less about knowing a language and more about building systems that remain reliable as usage grows. A resume can show Python, Java, Node.js, or SQL experience, but it cannot tell you how well the candidate handles data, APIs, failures, or performance problems.

Start with a practical assessment, then use the interview to probe their decisions. Ask how they would model a particular data set, diagnose a slow query, handle a failing third-party API, and decide what belongs in application logs.

The backend developer test can help screen core backend programming knowledge across languages and frameworks. For Java-heavy roles, the Java backend developer test provides a more targeted assessment of Java and database skills.

Full-stack developer

Treat "full-stack" as a capability to verify rather than a title to accept at face value. Most developers have a stronger side, and a good candidate should be able to tell you where that strength sits.

Give candidates a small feature that crosses the front end and back end. Then ask what they would change if they had another day, what they deliberately left out, and where they expect the design to break.

The full-stack web developer test evaluates both front-end and back-end development. For JavaScript, HTML, CSS, Java, and SQL environments, the full-stack web developer test provides a more specific screen.

Mobile developer

Mobile development comes with constraints that do not always appear in web development. Offline behavior, device fragmentation, app store requirements, battery use, and platform-specific performance all affect how the work gets done.

Ask candidates to describe a difficult release or production issue they handled. Probe what happened when the app was offline, how they diagnosed the problem, and what they changed to prevent it from recurring.

The mobile app development (Android, iOS) test assesses programming, architecture, design patterns, and platform-specific frameworks. For Android-focused roles, the Android developer test provides a deeper screen covering the Android SDK, Java, Kotlin, Flutter, and Android functions.

DevOps or SRE

DevOps and SRE hiring should focus on judgment, not the number of tools on a resume. Someone can list Kubernetes, Docker, Jenkins, and Terraform without ever owning a production incident.

Ask about the last serious outage they handled. What broke, how did they find the cause, what did they do first, and what changed afterwards? Strong candidates can usually explain the sequence clearly because they have dealt with the consequences themselves.

Use the DevOps test to screen knowledge of tools and practices such as Jenkins, Ansible, Docker, Kubernetes, and Linux. For GCP environments, the GCP DevOps engineer test adds coverage of infrastructure automation, CI/CD, monitoring, security, and networking.

Data engineer

Data engineers are often judged by whether other teams can rely on the data they produce. That makes SQL, pipeline design, data quality, and failure recovery more useful screening areas than a long list of platforms.

Give candidates a practical data problem and ask them to explain how they would extract, transform, validate, and deliver the data. In the interview, ask what they would do if a nightly pipeline failed hours before an important report was due.

The data engineer test covers core data engineering concepts including ETL and data-related workflows. If the role is GCP focused, the GCP data engineer test assesses pipeline design, ETL/ELT, orchestration, streaming, and data reliability.

Data scientist or ML engineer

These titles can describe very different jobs, so define the work before you assess the candidate. A data scientist may spend most of their time analyzing data and building models, while an ML engineer may be responsible for deploying, monitoring, and maintaining those models in production.

Give candidates a problem that requires them to explain their methodology, not just name an algorithm. Listen for how they handle poor data, select metrics, validate results, and communicate what the model cannot prove.

For data science roles, the data scientist intermediate test covers machine learning techniques, statistical modeling, and data visualization. For ML engineering roles, the machine learning engineer test focuses on areas such as data preprocessing and model implementation.

QA automation engineer

Good QA automation engineers think about how software fails, not just whether the happy path works. That makes failure scenarios a better screening tool than asking candidates to recite testing terminology.

Give them a short feature specification and ask what they would test first. Strong candidates should move beyond the obvious path and consider edge cases, invalid inputs, concurrency, integrations, and failure recovery. Then ask how they would investigate a test that fails intermittently.

The QA test automation test assesses automation skills across Appium, Selenium, test strategy, CI/CD, problem solving, and load testing.

Security engineer

Security hiring should test how candidates think about threats rather than how many certifications they have collected. A candidate who understands the underlying risk should be able to reason through an unfamiliar system without simply reciting a checklist.

Give them a simple system such as a password reset flow and ask them to threat-model it. Probe what an attacker could exploit, which risks matter most, and how they would reduce them. Keep compliance knowledge separate from security judgment because knowing SOC 2 or ISO 27001 does not automatically demonstrate vulnerability analysis skills.

The cybersecurity engineer test assesses areas such as threat intelligence and cybersecurity knowledge. For security roles embedded in development teams, the senior security engineer (DevSecOps) test adds application security and DevSecOps coverage.

Cloud or platform engineer

Platform engineers build systems that other engineers depend on, so technical ability needs to be paired with good judgment about usability, reliability, and cost. Do not only ask what they have built. Ask what they removed, simplified, or refused to build.

Cost is a particularly useful interview test. Ask what they would investigate if the cloud bill suddenly doubled and how they would decide whether the problem was infrastructure, usage, architecture, or poor controls.

For AWS roles, the AWS cloud engineer test assesses architecture, deployment, security, and compliance. For teams running GCP, the GCP DevOps engineer test covers infrastructure automation, CI/CD, containerization, monitoring, security, and networking

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.

Campus recruitment KPI cheat sheet for software engineer hiring

Track six numbers per campus cycle. They are cheap to collect, and each one points to 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.

FAQs