A good technical hiring process tests the skills the job actually needs, asks every candidate at a level the same questions, scores answers against criteria written before the first interview, and finishes in about three weeks. The written criteria matter more than which interview formats you pick.
This guide covers how to design the loop step by step: what each stage is for, how to choose between work samples, take-homes and live coding, how to build scorecards, how to treat candidates, and the legal basics every interviewer should know.
Start from the job, not the interview formats
Before choosing any interview format, list the four to six capabilities that separate someone who will do well in this role from someone who will struggle. For a backend engineer that might be:
- Writing correct, maintainable code in a production codebase
- Designing a service or data model with sensible trade-offs
- Debugging an unfamiliar system
- Communicating technical decisions in writing and in discussion
- Working with other people on a shared problem
Each stage of the loop should test one or two of these. If a stage does not map to a capability, cut it. If a capability is not tested anywhere, you are going to guess about it.
Write down, for each capability, what strong, acceptable and weak evidence looks like. That is the basis of your scorecard, and it should exist before the first candidate is scheduled.
The stages and what each is for
A typical loop for a mid-level or senior engineering role:
| Stage | Length | Purpose | Who runs it |
|---|---|---|---|
| Résumé or application review | A few minutes | Check for evidence of relevant work | Hiring manager or recruiter |
| Recruiter or manager screen | 30 minutes | Explain the role and pay range, confirm logistics, hear about one past project | Recruiter or hiring manager |
| Technical screen or work sample | 60 to 120 minutes | Test core coding or domain skill | An engineer |
| Onsite or virtual loop | 3 to 4 hours | System design, deeper technical work, collaboration | 3 to 4 interviewers |
| Debrief and decision | 30 to 60 minutes | Compare evidence against the scorecard | Interviewers and hiring manager |
| References and offer | A few days | Confirm specific points; make the offer | Hiring manager |
For junior roles, replace the system design interview with a session on learning: give them an unfamiliar piece of code and see how they figure it out. For management roles such as IT managers, weight the loop toward hiring, delivery and people decisions, with a lighter technical component.
The screen
The first call should share the pay range early. If the candidate's expectations and your range do not overlap, both sides learn it in five minutes rather than after four hours of interviews. In some states employers are also required to post the range: our guide to writing tech job descriptions covers the state rules.
Do not ask about current or past salary. California generally prohibits employers from seeking an applicant's salary history (CA Labor Commissioner), and Colorado prohibits asking about or relying on pay history (Colorado CDLE). Asking about expectations, and stating your range, is the cleaner approach everywhere.
Work samples, take-homes and live coding
These are the three main ways to test hands-on skill. Each has trade-offs.
| Format | What it shows well | Main drawbacks | Use when |
|---|---|---|---|
| Work sample (in session) | How they handle a task close to the real job, with time to think | Takes preparation to build a realistic task | Default choice for most roles |
| Take-home exercise | Code quality and structure without an audience | Costs the candidate unpaid time; hard to verify who did the work | Candidate prefers it, and you cap and ideally pay for the time |
| Live coding | How they think aloud and respond to hints | Rewards performing under observation, not just skill | Short, collaborative problems with a supportive interviewer |
| Puzzle or algorithm questions | Easy to standardize | Weak link to most product engineering work | Roles where algorithmic work is the daily job |
A few rules that make any format fairer:
- Make the task look like the job. If the role is building APIs, have them extend a small API. If it is maintaining legacy code, give them legacy code.
- Cap take-homes at about two hours and say so in writing. Grade what was asked for, not extra polish.
- Pay for longer exercises. If the exercise is a half-day or more, pay for it.
- Allow normal tools. Their own editor, language documentation and search, unless you are specifically testing recall.
- Discuss the work afterward. Ask why they made each choice and what they would change. This conversation catches copied work and shows judgement.
- Offer a choice of format where you can. Some strong engineers freeze in live coding; others hate take-homes. Both choices can be scored against the same criteria.
Structured interviews and scorecards
A structured interview means every candidate at a level gets the same core questions, and every interviewer scores against the same written criteria. It is the most important thing on this page.
A practical scorecard for each interview:
- The capability being tested. For example, "system design."
- The questions or task. Fixed for the level. Follow-up questions can vary, but the core does not.
- What strong, acceptable and weak look like. Concrete. "Identifies that the queue can grow unbounded and proposes back pressure or limits" is useful. "Good system thinking" is not.
- A rating scale. Four points works well because there is no neutral middle: strong no, lean no, lean yes, strong yes.
- Evidence. The interviewer writes what the candidate said or did that justifies the rating.
Interviewers submit scorecards before the debrief and before they see anyone else's. Otherwise the first confident voice in the room sets the outcome.
In the debrief, go capability by capability. Disagreements are useful: they usually mean two interviewers saw different evidence, and the scorecards let you look at it. The hiring manager makes the call, but should be able to explain it in terms of the scorecard, not a general impression.
Keep the scorecards. They are your record of why you made each decision, which matters if a decision is ever questioned.
Candidate experience
Candidates judge the company by the process. Strong engineers often have several processes going at once and will drop the slowest or the most disrespectful one.
What good candidate experience looks like in practice:
- Tell them the whole process at the start. Stages, length and expected timeline.
- Send prep information. What each interview covers and what tools they will use. Surprises test anxiety, not skill.
- Start on time and leave time for their questions. Five minutes at the end of each interview is the minimum.
- Give the same interviewer briefing every time. Interviewers should know the role, the level and their assigned capability before they walk in.
- Respond fast. Aim to give a decision within two business days of the final interview.
- Close the loop with everyone. A short, respectful rejection is better than silence. If someone made it to the final stage, offer a brief call or a few lines of specific feedback where your legal or HR guidance allows it.
Timelines
From first screen to offer, aim for two to three weeks. A practical schedule:
| Week | What happens |
|---|---|
| Week 1 | Screen; send and complete the technical exercise |
| Week 2 | Onsite or virtual loop; debrief within a day or two |
| Week 3 | References, offer, negotiation |
The main causes of delay are scheduling the onsite and slow debriefs. Block interviewer time in advance each week so you are not searching calendars for every candidate, and hold debriefs within one business day of the loop.
Legal basics every interviewer should know
This is not legal advice. Talk to an employment lawyer for anything specific to your company. But every interviewer should understand a few federal basics from the US Equal Employment Opportunity Commission.
Federal law prohibits employment discrimination based on race, color, religion, sex, national origin, age (40 or older), disability or genetic information, and that includes recruiting, interviewing and hiring decisions (EEOC). Practical consequences for interviewers:
- Ask only what relates to the job. The EEOC says pre-employment inquiries should be limited to what is needed to decide whether a person is qualified. Do not ask about age, family plans, religion, national origin or similar topics, even as small talk.
- No disability questions before an offer. The EEOC states that employers are prohibited from asking about disability before making a job offer.
- Tests must relate to the job. If a test or selection procedure disproportionately excludes people based on race, color, religion, sex or national origin, the employer must show it is job-related and consistent with business necessity (EEOC guidance on employment tests). Work samples built from the real job are easier to justify than abstract puzzles.
- Provide reasonable accommodations. The same EEOC guidance notes that the ADA requires reasonable accommodations in how tests are administered, unless that causes undue hardship. Ask every candidate whether they need any adjustment, and have a plan for common requests such as extra time.
Structured interviews help here too. When every candidate gets the same questions and is scored against written, job-related criteria, decisions are easier to explain and less likely to rest on personal impressions.
Where to start
If you have an existing process, take your last three hires and your last three rejections and ask: could we explain each decision using written criteria? If not, the first change is to write the capability list and scorecards for your most common role, and use them for the next five candidates. Formats and timing are easier to fix once the criteria exist.