Interview guide · Recruiting and HR roles
Technical recruiter interview questions
In short
Technical recruiter interview questions should test whether a candidate can understand engineering roles well enough to source and screen for them, write searches that find passive talent, run a credible first conversation with an engineer, partner with technical hiring managers and close offers in a competitive market. Below are 34 questions with what to listen for, red flags, sample answers and a scorecard.
A technical recruiter hires software engineers, data people, IT infrastructure, security, QA and similar roles. The work differs from general recruiting in three ways. Most good candidates are not applying, so sourcing and outreach matter more. Engineers judge the company by the recruiter's first message and first call, so a recruiter who confuses Java with JavaScript loses people before the hiring manager ever meets them. And technical hiring managers are often busy, skeptical of recruiters and specific about what they want, which makes intake and calibration the real job.
Nobody expects a technical recruiter to code. You are testing whether they understand roles at the level of what the person builds, with what tools, at what scale, and can tell a strong profile from a keyword match. Use the technical-literacy questions to check that, then a live sourcing exercise: give them a real role and 20 minutes to find five profiles and draft an outreach message. That exercise tells you more than any question on this page. Score every candidate on the same scorecard.
What to look for in a technical recruiter
- Technical literacyThey need to understand stacks, seniority signals and role differences (backend vs. platform, data engineer vs. data scientist) well enough to screen and to earn engineers' respect.
- Sourcing skillPassive candidates make up much of the strong tech market. Boolean search, GitHub and community sourcing, and personalized outreach are core skills.
- Hiring manager partnershipStrong tech recruiters calibrate quickly, push back on unrealistic requirements and keep engineering interviewers moving.
- Candidate experience and closingEngineers often hold several offers. Speed, honesty and knowing what each candidate cares about win offers.
- Market knowledgePay ranges, demand for specific skills and remote-work expectations shift quickly. The recruiter should advise managers with current data.
- Organization and pipeline disciplineTech processes have many stages and interviewers. Keeping the ATS current and candidates informed prevents lost hires.
Opening and background questions
What technical roles have you hired for, at what levels, and how many in the last year?
- Why ask it
- Sets the scope of their real experience.
- A strong answer
- Specific: '22 hires last year, mostly backend and data engineers from mid-level to staff, plus two engineering managers, for a 300-person SaaS company.'
- Red flags
- Vague about numbers or levels, or mostly IT support roles described as engineering.
Agency or in-house, and what changed in how you work when you moved between them?
- Why ask it
- Agency and in-house recruiting reward different habits.
- A strong answer
- Understands the trade-offs: agency speed and volume of outreach versus in-house depth, process ownership and long-term relationships with hiring teams.
- Red flags
- Dismissive of one model, or no awareness of the difference.
Which hire are you proudest of and why?
- Why ask it
- Shows what they value: difficulty, impact or relationship.
- A strong answer
- A hard search with a clear story: how they found the person, how they sold the role, what obstacles came up, how the hire is doing now.
- Red flags
- An easy hire with no specific contribution.
How do you keep up with technology trends well enough to talk to engineers?
- Why ask it
- Tests ongoing learning.
- A strong answer
- Specific habits: asking hiring managers to explain their architecture, reading engineering blogs, meetups, shadowing technical interviews, keeping a glossary.
- Red flags
- Relies only on the job description.
Technical literacy questions
Explain the difference between a frontend, backend and full-stack engineer, and what you would look for on each resume.
- Why ask it
- A basic test of role understanding.
- A strong answer
- Frontend builds the user interface (JavaScript or TypeScript, frameworks such as React), backend builds services, APIs and data logic (languages like Java, Go, Python, Node.js, plus databases), full-stack does both. Looks for what they built, scale and ownership, not keyword lists.
- Red flags
- Confuses the roles or screens by keyword only.
What is the difference between a data engineer, a data analyst and a data scientist?
- Why ask it
- These roles are often mis-sourced.
- A strong answer
- Data engineers build pipelines and infrastructure; analysts answer business questions with SQL and dashboards; data scientists build models and experiments. Names typical tools for each.
- Red flags
- Treats them as interchangeable.
How do you tell a senior engineer from a mid-level one on a resume or in a screen?
- Why ask it
- Leveling mistakes waste interviewer time.
- A strong answer
- Looks for scope and ownership: designed systems not just features, led projects, mentored others, made trade-off decisions, handled production incidents. Years alone are a weak signal.
- Red flags
- Uses years of experience only.
A hiring manager says they need someone with Kubernetes experience. What questions do you ask to understand that?
- Why ask it
- Tests ability to unpack a requirement.
- A strong answer
- Asks whether they need someone to operate clusters or just deploy to them, what cloud, how large, whether it is a must-have or learnable, and what related skills would transfer (Docker, other orchestration, infrastructure as code).
- Red flags
- Just searches the keyword.
What does DevOps or site reliability engineering involve, and how would you screen for it?
- Why ask it
- Common hard-to-fill roles.
- A strong answer
- Explains automation of deployments, infrastructure as code, monitoring, on-call and reliability targets. Screens with questions about what they automated, incidents handled, and tools used.
- Red flags
- Describes it as IT support.
How do you screen a candidate for a role where you cannot judge the technical depth yourself?
- Why ask it
- Every tech recruiter hits this limit. Honest process matters.
- A strong answer
- Uses calibrated screening questions agreed with the hiring manager, listens for specificity and ownership, and hands the depth check to an engineer early.
- Red flags
- Claims to judge everything themselves, or passes everyone through.
Sourcing and outreach questions
Write a Boolean search out loud for a senior Python backend engineer in Austin who has worked with AWS.
- Why ask it
- A practical sourcing test.
- A strong answer
- Something like ("backend engineer" OR "software engineer" OR developer) AND Python AND (AWS OR "Amazon Web Services") AND (senior OR lead OR staff) with location set separately, and notes on refining with NOT terms or company lists.
- Red flags
- Cannot construct one, or uses only a single keyword.
Where do you source engineers besides LinkedIn?
- Why ask it
- The best talent is often over-contacted on LinkedIn.
- A strong answer
- GitHub, Stack Overflow, technical community forums and meetups, conference speaker lists, open source contributors, alumni networks of strong companies, and referrals.
- Red flags
- LinkedIn only.
Read me the first outreach message you would send to a senior engineer who is not looking.
- Why ask it
- Outreach quality decides response rates.
- A strong answer
- Short, personal, mentions something real about their work, says what the team builds and why it is interesting, gives pay range if allowed, asks for a 15 minute chat.
- Red flags
- Long, generic, full of buzzwords.
What response rate do you get on cold outreach, and how have you improved it?
- Why ask it
- Tests whether they measure and iterate.
- A strong answer
- Knows their numbers by role type and describes changes that helped: personalization, shorter messages, sending from the hiring manager, better timing, follow-ups.
- Red flags
- Does not track it.
How many follow-ups do you send, and how far apart?
- Why ask it
- Persistence without spamming.
- A strong answer
- Two or three follow-ups over two to three weeks, each adding something new, then stops.
- Red flags
- No follow-up, or daily messages.
How do you build a diverse pipeline for engineering roles?
- Why ask it
- Diverse slates depend on sourcing choices.
- A strong answer
- Widens sourcing beyond the same few companies and schools, uses communities and organizations for underrepresented engineers, removes unnecessary requirements, and tracks pipeline mix by stage. Never selects or rejects on protected characteristics.
- Red flags
- Says it is not their job, or describes illegal preferences.
Hiring manager and process questions
How do you run an intake meeting for an engineering role?
- Why ask it
- Calibration drives the whole search.
- A strong answer
- Covers what the person will build in the first six months, the team and stack, must-haves vs. trainable skills, level and pay range, interview loop and timing. Asks for example profiles and calibrates on the first five candidates.
- Red flags
- Takes the job description and starts sourcing.
The hiring manager rejects the first 15 candidates without clear reasons. What do you do?
- Why ask it
- Tests calibration under friction.
- A strong answer
- Sits down for a calibration session, reviews rejected profiles together, writes down specific reasons, and adjusts the search or challenges unrealistic requirements with market data.
- Red flags
- Keeps sending similar profiles.
How do you keep a five-stage technical interview loop moving fast?
- Why ask it
- Slow loops lose engineers to faster companies.
- A strong answer
- Books interviews in blocks, has a trained interviewer pool, sets 24 hour feedback rules, combines stages when possible, and updates candidates after every step.
- Red flags
- Waits for interviewers to find time.
What is your view on take-home coding assignments?
- Why ask it
- Tests candidate-experience judgment.
- A strong answer
- Balanced: useful when short and relevant, harmful when long or unpaid for senior candidates. Suggests time limits, alternatives like pair programming, or paying for longer exercises.
- Red flags
- No opinion, or thinks longer is better.
An interviewer gives a 'no hire' with only 'not a culture fit' as the reason. What do you do?
- Why ask it
- Vague feedback hides bias and weakens hiring decisions.
- A strong answer
- Asks for specific, job-related evidence, ties feedback to the scorecard, and raises the issue with the hiring manager if it repeats.
- Red flags
- Accepts it without question.
How do you advise a hiring manager whose pay range is below market?
- Why ask it
- Tests use of market data.
- A strong answer
- Brings data from recent offers, declines and salary benchmarks, shows the impact on funnel and time to fill, and proposes options: raise the range, adjust level, broaden location.
- Red flags
- Keeps searching and hopes.
Closing and candidate experience questions
Tell me about an offer you thought you would lose and won. What did you do?
- Why ask it
- Closing is where tech recruiting wins or loses.
- A strong answer
- Knew the candidate's motivators early, kept them close through the process, partnered with the hiring manager, addressed concerns directly and moved quickly.
- Red flags
- Only talks about increasing salary.
A candidate tells you they have a competing offer with a 48 hour deadline. You are two interviews away from a decision. What do you do?
- Why ask it
- Common real-world test.
- A strong answer
- Asks about the other offer and their preferences, speeds up the remaining interviews (same day if possible), tells the hiring manager, and is honest with the candidate about timing.
- Red flags
- Asks them to stall the other company without changing anything.
How do you uncover what a candidate really wants before the offer stage?
- Why ask it
- Avoids surprise declines.
- A strong answer
- Asks early and repeatedly: why they would leave, what would make them stay, their pay expectations, remote preferences, and other processes. Revisits at every stage.
- Red flags
- First discusses this at the offer.
How do you reject a candidate who did a full onsite loop?
- Why ask it
- Candidate experience at the end of a long process matters for reputation and future hiring.
- A strong answer
- Phone call or personal email within a few days, useful job-related feedback where policy allows, and keeps the door open for future roles.
- Red flags
- Automated rejection or silence.
A candidate accepts, then calls a week before start to say they got a counteroffer. What do you do?
- Why ask it
- Counteroffers are common in tech.
- A strong answer
- Listens, revisits their original reasons for leaving, has the hiring manager reach out, and decides with leadership whether any change is justified without starting a bidding war.
- Red flags
- Panics and matches any number, or gives up immediately.
Questions for technical sourcers and senior technical recruiters
How do you hand off candidates from sourcing to recruiting without losing context?
- Why ask it
- Tests process in sourcer and recruiter pairs.
- A strong answer
- Detailed notes in the ATS, a warm introduction, shared calibration notes, and a feedback loop on conversion.
- Red flags
- Just passes a profile link.
How would you build a pipeline for a hard-to-fill role that will open in three months?
- Why ask it
- Proactive sourcing for senior or niche roles.
- A strong answer
- Builds a talent pool now, starts relationship-based outreach, maps target companies, and tracks pipeline readiness.
- Red flags
- Waits until the requisition opens.
Which metrics do you track for your own desk?
- Why ask it
- Shows ownership of performance.
- A strong answer
- Outreach response rate, screen to onsite and onsite to offer conversion, offer acceptance, time in stage and hires against target.
- Red flags
- Only number of submissions.
Sample answers
Something like: 'Hi Marcus, I saw your talk on moving payment services to event-driven architecture, especially the part about replaying failed events without double charging. Our platform team is working on almost exactly that problem at about three times the transaction volume, and the engineering lead, Priya, asked me to reach out. It's a senior backend role, mostly Go and Kafka, remote in the US, with a range of $185K to $215K base. Would you be open to a 15 minute call next week, even just to compare notes?' I keep it under 100 words, mention something real they did, say why this team specifically, and give the range up front. If there's no reply, I follow up once after five days with something new, like a link to the team's engineering blog, and once more a week later. Then I stop.
I'd stop sourcing for a day and book a 30 minute calibration session. I'd bring the 15 profiles and ask the manager to sort them into 'close', 'maybe' and 'no', and say one specific reason for each. Usually a pattern shows up quickly: maybe they want someone who has owned production systems at scale, not just written features, or they actually need distributed systems experience that was never in the job description. I write the real criteria down and confirm them. If the criteria don't exist in the market at our pay range, I show the data: how many people match, response rates so far, recent offers we lost. Then we agree on what to adjust. The next batch I send is five profiles, not 15, and I ask for feedback within 24 hours.
Interview scorecard
| Competency | Weight | Strong (4–5) | Weak (1–2) |
|---|---|---|---|
| Technical literacy | 20% | Understands roles, stacks and leveling well enough to screen credibly and unpack requirements. | Screens by keyword, confuses role types. |
| Sourcing and outreach | 25% | Strong Boolean and multi-channel sourcing, personalized outreach, measures response rates. | Relies on applicants and generic InMail. |
| Hiring manager partnership | 20% | Runs real intakes, calibrates quickly, pushes back with market data. | Order-taker who keeps sending mismatched profiles. |
| Closing and candidate experience | 20% | Knows motivators early, moves fast, closes competing offers, treats rejected candidates well. | Surprised by declines, slow updates. |
| Process and data discipline | 15% | Clean ATS records, fast loops, tracks desk metrics. | Disorganized, loses candidates between stages. |
Score each competency from 1 to 5 straight after the interview, before discussing the candidate with anyone else, then multiply by the weight.
How to structure a technical recruiter interview
A practical process has four steps and takes two to three weeks:
- Screen (30 minutes). Roles hired, volume, agency or in-house, comp and the opening questions. Ask for their desk metrics.
- Recruiting manager interview (45 to 60 minutes). Technical literacy, intake and closing questions.
- Sourcing exercise (45 minutes). Give them a real open role, 20 to 25 minutes to find five profiles and write an outreach message, then 20 minutes to walk through their choices. Watch how they search and how they explain why each profile fits.
- Engineering manager conversation (30 to 45 minutes). Have an engineering manager run a mock intake meeting. The best signal is whether the engineer would trust this person with their searches.
For broader recruiting skills, see our recruiter interview questions. If the role is mostly sourcing, the sourcer interview questions go deeper on search technique and pipeline building. It also helps the candidate's preparation and your intake to compare the role against a clear corporate recruiter job description.
Mistakes when interviewing technical recruiters
- Testing trivia instead of understanding. Asking a recruiter to define a hash map tells you little. Asking how they would unpack a vague requirement, or what separates a senior from a mid-level backend engineer, tells you whether they can do the job.
- Skipping the live exercise. Many recruiters talk well about sourcing. Watching them search for 20 minutes shows whether they can actually find people.
- Hiring on network size alone. A large network of engineers is helpful but decays quickly. Process, outreach quality and calibration skill last longer.
- Ignoring the hiring manager fit. Engineering managers who do not trust their recruiter stop engaging, and searches stall. Let one interview the candidate.
- Not checking closing ability. Tech recruiting is lost at the offer more often than anywhere else. Ask for a specific offer they won and one they lost.
IT recruiters, tech recruiters and high-volume technical hiring
The title covers different jobs. An IT recruiter at a staffing firm may fill help desk, desktop support and network roles on short contracts, with high volume and fast turnaround. A tech recruiter at a product company may fill eight senior engineering roles a quarter with long, careful searches. Weight the scorecard to match: for contract IT staffing, increase process and speed; for senior product engineering, increase sourcing, literacy and closing.
For volume technical hiring, such as a technical support center or a large IT services firm hiring 50 engineers a month, the recruiter must also run a structured, repeatable funnel. Ask how they would screen hundreds of applicants for a junior role, what they would automate (application questions, scheduling, a short skills assessment) and how they would keep hiring managers calibrated across many interviewers. Use a consistent technical screen and scorecard for every candidate so decisions are comparable and defensible. When the recruiter's work feeds into engineering interviews, share our software engineer interview questions with the panel so every candidate is assessed on the same ground.
Frequently asked questions
What are common IT recruiter interview questions?
Expect questions on the technical roles you have filled, how you source passive candidates, writing Boolean searches, screening for skills you cannot fully judge, working with technical hiring managers, and closing candidates with competing offers. Staffing firms add questions about speed, contract roles and client management.
What are good tech recruiter interview questions to test technical knowledge?
Ask candidates to explain the difference between frontend, backend and full-stack engineers, or data engineers and data scientists, how they spot seniority on a resume, and how they would unpack a requirement like 'Kubernetes experience'. Look for understanding, not memorized definitions.
What should I ask a technical sourcer?
Focus on search technique: live Boolean strings, sources beyond LinkedIn, outreach messages and response rates, follow-up cadence, building pipelines for future roles, and handing candidates to recruiters with full context. A live sourcing exercise is the best test.
Does a technical recruiter need to know how to code?
No. They need to understand what engineers build, with which tools, and how to tell strong experience from keyword matches. Coding knowledge helps but is not required; curiosity and the ability to learn from hiring managers matter more.
How do you test a technical recruiter's sourcing skills in an interview?
Give them a real or realistic open role and 20 to 25 minutes to find five matching profiles and draft an outreach message. Then ask them to explain why each profile fits and how they would refine the search.
What metrics should a technical recruiter know?
Outreach response rate, screen to interview and interview to offer conversion, offer acceptance rate, time in each stage, time to fill and hires against target. Strong candidates know their own numbers.