Technical Screening for Developers: A Practical Guide

Technical screening for developers works best as a short, structured sequence: a resume and portfolio review, a 20 to 30 minute screening call, one job-related exercise, and a scored debrief. Every candidate gets the same questions and is rated against the same written criteria. Research on hiring points the same way: structured interviews had the highest mean operational validity (r = .42) of the predictors reviewed, ahead of cognitive ability tests (r = .31).

This guide shows how to build that process, which questions to ask, which exercise formats hold up, and what U.S. employers need to check before they rely on a screening tool.

TL;DR

• Screen in stages, cheapest signal first: written review, a short call, one realistic exercise, then a scored debrief.
• Standardize everything. The same questions, the same rubric and the same scoring scale for every candidate predict performance better than free-form conversation.
• Test the work, not trivia. Exercises that mirror your codebase beat whiteboard puzzles, and a ready-to-use environment keeps setup time out of the result.
• In the U.S., any selection procedure, automated or human, must be job-related. Keep records and monitor outcomes.
• If you do not have the engineering bandwidth to run this process, a vetted-talent partner can run it for you.

Table of Contents

• What technical screening is, and what it should decide
• A four-stage screening process
• Technical screening questions that produce signal
• Choosing an exercise format
• Score with a rubric, not a gut feeling
• Legal and fairness checks for U.S. employers
• Common mistakes to avoid
• Our perspective: screening is a cost, so spend it where it counts
• When to hand screening to a partner
• FAQ
• Sources

What technical screening is, and what it should decide

Technical screening is the first filter that checks whether a developer can do the work before your senior engineers spend hours on interviews. It answers three narrow questions:

1. Does this person have the core skills the role requires, at the level you need?
2. Can they explain their own past work clearly and honestly?
3. Is it worth a full interview loop?

It does not need to decide whether to hire. That decision belongs to the later stages, where team fit, communication and seniority get a deeper look. Screening that tries to do everything ends up long, stressful for candidates and inconsistent between interviewers.

For remote and distributed hiring, the screen carries extra weight. You cannot observe someone at a desk, so how they reason, write and handle ambiguity has to show up in the process itself.

A four-stage screening process

The process below suits a growth-stage team hiring a senior engineer. Adjust the timing for your role, but keep the order.

1. Written review (10 minutes per candidate)

Define three to five must-have criteria before you open a single resume. For a senior backend role, for example: production experience with your primary language, ownership of a service in production, experience with data modeling at scale, and clear written communication. Mark each as met, partly met or not met. Do not rely on keyword matches alone, because they reward resume formatting rather than skill.

2. Screening call (20 to 30 minutes)

Keep it lightly technical. The goal is to confirm depth in their stated experience, not to run a coding test. Use the same five or six questions for everyone and take notes against a rubric as you go. The questions in the next section work well here.

3. One job-related exercise (45 to 90 minutes)

Pick one format, either a live pairing session or a short take-home, and make it resemble real work. More on formats below. One well-chosen exercise gives more signal than three shallow ones.

4. Scored debrief (same day)

Each reviewer submits scores and written evidence independently, before discussing. Then compare. Independent scoring stops the most senior or most talkative person from setting the outcome.

Technical screening questions that produce signal

Good screening questions are open enough that a strong candidate can show depth and a weak one cannot bluff for long. Ask them in the same order every time. Our own set of senior developer interview questions goes further if you want to practice and score a mock interview.

Questions about past work

• Tell me about the most complex system you have owned in production. What were its failure modes?
• What was the hardest project to get started on, and how did you work through the requirements?
• Describe a technical decision you made that you later regretted. What did you change?

Listen for specifics: names of components, trade-offs weighed, numbers, what went wrong. Vague answers about “the team” are a signal to probe, such as “What was your part in that?”

Questions about reasoning

• A page that loaded in one second now takes six. Walk me through how you would find the cause.
• You inherit a service with no tests and a release due next week. What do you do first?
• How would you review a pull request that works but is hard to read?

There is no single right answer. You are checking whether the candidate forms hypotheses, narrows them and communicates what they are doing.

Questions about the stack

Keep these tied to the job. If the role is React and TypeScript, ask about state management choices and typing strategies, not about sorting algorithms. For role-specific checklists, see our guide to hiring a senior React developer.

Questions about collaboration

• How do you give a teammate feedback on code you disagree with?
• Tell me about a time requirements changed mid-sprint.
• When have you pushed back on a deadline, and what happened?

For distributed teams, add one on working across time zones: how they hand off work, document decisions and handle blocked tasks.

Choosing an exercise format

Each format tests something different. The table summarizes the trade-offs from our experience and from published engineering guidance.

Why whiteboard puzzles fall short

Practitioners at GitHub note that algorithmic puzzles are often arbitrary and unrelated to daily work. Problems that look like your real code, such as using an internal-style API or refactoring a component, tell you much more. Discussing code on screen instead of writing it from scratch also tends to feel more like a conversation and less like an exam.

Take-home exercises done respectfully

Take-homes can work if they are short, scoped and paid for in respect: tell candidates how long to spend, what you will assess and who will read it. GitHub describes its approach in how it runs take-home technical interviews, and the common thread is clear scoping and a good candidate experience. If you ask for more than two or three hours, expect your strongest candidates, who have other offers, to decline.

Remove environment friction

A frequent mistake is making candidates configure a local setup before they can touch the problem. GitHub’s engineers point out that this yields no signal about competence, and that cloud-based development environments let the interview measure engineering skill rather than troubleshooting patience. The same logic applies if your exercise needs a specific stack: prepare it in advance. Some teams provision a dedicated cloud server for the coding exercise environment so every candidate starts from an identical, working setup. Whatever you choose, test the environment yourself, with the tool versions you will actually give candidates.

Score with a rubric, not a gut feeling

Structure is the most useful thing you can add. The SIOP review of the new meta-analytic evidence notes that structured interview validity is variable, so teams need to standardize how the interview is developed, administered and scored to reach its full predictive value. The same review also found job knowledge tests (r = .40) and work sample tests (r = .33) among the stronger predictors, which supports using a realistic exercise.

A simple rubric looks like this:

1. Technical depth: 1 (surface knowledge) to 4 (explains trade-offs and failure modes unprompted).
2. Problem solving: 1 (guesses) to 4 (structured hypotheses, tests them, adjusts).
3. Code quality: 1 (works but unreadable) to 4 (clear, tested, easy to extend).
4. Communication: 1 (hard to follow) to 4 (explains decisions concisely, asks good questions).
5. Ownership: 1 (describes tasks) to 4 (describes outcomes and consequences).

Write one sentence of evidence beside every score. A “3” with no evidence is a feeling. Decide the pass threshold before you meet candidates, and apply it to all of them.

Legal and fairness checks for U.S. employers

If you hire in the U.S., your screening is a selection procedure, and it needs to be defensible. Treat the points below as a starting checklist and ask employment counsel about your specific process.

• Job-relatedness. The EEOC’s guidance on employment tests and selection procedures explains that employers are responsible for ensuring tests are job-related and do not disproportionately exclude protected groups, with validity shown under the Uniform Guidelines on Employee Selection Procedures. Tie each question and exercise to a real duty of the role.
• Adverse impact. The EEOC’s Q&A on the Uniform Guidelines explains how to identify a selection process with adverse impact. Track pass rates by stage so you can spot a problem early.
• Automated tools. If you use scoring software, testimony to the EEOC recommends testing algorithms for discrimination through disparity assessments, and notes that a model falling short of the four-fifths rule of thumb should be modified before deployment. Another witness warned that opaque models make errors hard to find and fix, and that human oversight is needed for binary advance or reject decisions.
• Candidate experience. SIOP’s research summary on applicant reactions to selection recommends that systems be job-related, that candidates have an opportunity to perform, and that procedures be consistent. If an exercise is not obviously tied to the job, explain why you use it.

Candidates based outside the U.S. may fall under different local rules, so check these before you assume the same process applies everywhere.

Common mistakes to avoid

1. Changing the questions per candidate. It feels flexible but makes comparison impossible.
2. Letting seniority bias the score. Collect written scores before the group discussion.
3. Over-weighting speed. A fast typist is not necessarily a better engineer.
4. Screening for a stack, not the job. Strong engineers learn new frameworks. Test the fundamentals your role needs.
5. Ignoring the candidate’s time. A five-stage process for a contract role loses senior people. Keep screening under about three hours of candidate effort in total.
6. Skipping the reference step. A short call with a former colleague often confirms what the exercise only suggests.

Teams that struggle here often struggle later too. Our write-up on why remote developer hiring fails covers the patterns we see most.

Our perspective: screening is a cost, so spend it where it counts

We work with growth-stage companies that need senior engineers and cannot afford to pull their own lead developers into dozens of screening calls. From that vantage point, three things stand out.

First, the cost of screening falls mostly on your best engineers. Every hour a senior developer spends on a weak candidate is an hour not spent shipping. That argues for stricter early filters and a smaller number of well-run exercises, rather than long loops for everyone.

Second, a technical screen only tells you part of the story. A candidate who passes the exercise can still be a poor fit for your team’s communication style, time zone overlap or product stage. That is why our model has the founder speak directly with each client to understand the team and the role before matching, and why we work with pre-vetted senior engineers from Eastern Europe rather than sending a stack of resumes.

Third, retention matters as much as the screen. A hire who leaves after six months wastes the whole process. We design engagements around long-term fit, and we stand behind engineer retention.

If your team has the bandwidth, build your own structured process using the steps above. If it does not, outsourcing the first filter is a reasonable choice, as long as you still meet the final candidates yourself.

— Editorial Team

When to hand screening to a partner

Running a proper screen takes calendar time and senior attention. If you need a developer in weeks, not months, we can take that off your plate.

• Staff augmentation: pre-vetted senior engineers who join your team, from $45 per hour.
• Tech recruitment: we find and vet the candidate, and you hire directly, at $7,999 one-off per successful hire.

Not sure which model suits you? Our comparison of staff augmentation and recruitment walks through the decision, and you can start a conversation from the Odesa homepage.

FAQ

How do you screen developers if you are not technical yourself?

Focus on what you can judge: clarity of communication, specificity of past examples and reliability in the process. Bring in a trusted senior engineer, an advisor or a vetted-talent partner to run the technical exercise and score it against your rubric. Meet the finalists yourself for the final decision.

How long should a technical screening take?

A screening call should take 20 to 30 minutes, and one exercise should add 45 to 90 minutes. Across all stages, aim to keep total candidate effort to roughly three hours or less for a senior role. Longer processes tend to lose strong candidates who have other options.

Are take-home tests better than live coding?

Neither is better in every case. Live pairing shows reasoning and collaboration, while a short take-home shows how someone writes and structures code without pressure. Choose one, keep it realistic and scoped to the job, and offer the other as an accommodation if a candidate asks.

Is it legal to use automated coding tests in the U.S.?

Yes, but they are selection procedures like any other. The EEOC expects them to be job-related, and employers remain responsible for adverse impact. Monitor pass rates by group, keep a human involved in reject decisions, and ask employment counsel to review your setup.

Sources

• Is Cognitive Ability the Best Predictor of Job Performance? (SIOP)
• Employment Tests and Selection Procedures (EEOC)
• Questions and Answers on the Uniform Guidelines on Employee Selection Procedures (EEOC)
• Testimony of Manish Raghavan (EEOC)
• Testimony of Suresh Venkatasubramanian (EEOC)
• What We Know About Applicant Reactions to Selection (SIOP)
• Making technical interviews better for everyone (GitHub Blog)
• How GitHub does take home technical interviews (GitHub Blog)
• Technical interviews via Codespaces (GitHub Blog)

Recommended

• Senior Developer Interview Questions: Practice, Then Score Your Mock
• Hiring a Senior React Developer: A Founder’s Checklist
• How to Hire Remote Developers: A Practical Guide
• In-House vs Outsourcing Developers: The Hidden Cost of Speed

This article may have used AI tools in the writing process. Facts, figures, and recommendations can be wrong or out of date. Do not treat this as professional advice.