A recruiter's interview with an IT candidate is not a technical interview. You are not there to check code — the team will do that. You are there to understand what the person actually did, at what level, why they want to move, and whether they will work well with this team. Below are questions by role and level, what to listen for in each answer, and a free generator that builds a question set for your next interview.
What a recruiter checks in an IT interview
Split the assessment honestly between you and the team:
- Recruiter: real experience and its scope, the candidate's own role in projects, level, motivation, salary and conditions, communication and how they work with people.
- Technical team: depth of knowledge, code quality, architecture and problem-solving — through a technical interview, a live task or a test assignment.
How to build the interview: ten questions in 30–45 minutes
A set that works for most IT roles:
- Motivation — 2 questions. What matters in the next role, and why they are looking now.
- Experience in the role — 4 questions. Real projects, the stack and why, their own contribution, quality and incidents.
- Level — 2 questions. Scope and independence: what they owned, whom they helped.
- Soft skills — 2 questions. Disagreements and feedback.
Questions by role, and what to listen for
Backend developer
- Tell me about the last service or API you built. What did it do and who used it? Listen for: a real system, its purpose, users or load.
- Which language and frameworks did you use, and why were they chosen? Listen for: reasons, not just a list of technologies.
- How did you work with the database on that project? Listen for: design decisions, performance issues they solved.
- How is your code tested before it goes to production? Listen for: unit or integration tests, code review, CI.
- Tell me about an incident in production. What happened and what did you change after it? Listen for: ownership, a calm and specific account.
- How do you agree an API with the frontend or other teams? Listen for: contracts, documentation, communication.
- Tell me about the interface you are proudest of. What problem did it solve for users? Listen for: user impact, not only visuals.
- Which framework do you work with, and what do you like and dislike about it? Listen for: a reasoned opinion.
- How do you work with designers when a design is hard to implement? Listen for: negotiation, alternatives.
- How do you make sure the interface works in different browsers and on mobile? Listen for: testing approach.
- What did you do to make a page or app faster? Listen for: a specific improvement and how they measured it.
- How do you work with the backend team on APIs? Listen for: contracts, mocks, communication.
- Walk me through how you test a new feature from the moment you get the task. Listen for: a clear process: requirements, test cases, regression.
- What is the balance between manual and automated testing on your current project? Listen for: concrete numbers or proportions, reasons.
- Tell me about a serious bug you found. How did you find it and what happened next? Listen for: curiosity, communication with developers.
- Which tools do you use for test management and automation? Listen for: real usage, not a list.
- How do you decide what to test first when there is no time to test everything? Listen for: risk-based thinking.
- How do you handle it when a developer disagrees that something is a bug? Listen for: evidence, calm communication.
- Describe the infrastructure you work with now. What runs where? Listen for: a coherent picture, their own part in it.
- How does code get from a developer's laptop to production on your project? Listen for: CI/CD pipeline they built or maintain.
- Tell me about an outage you handled. What was the cause and what did you change? Listen for: ownership, prevention.
- How do you monitor systems and get alerted about problems? Listen for: monitoring and alerting practice.
- What did you automate recently that saved the team time? Listen for: a specific result.
- How do you work with developers on infrastructure requests? Listen for: service mindset, priorities.
Data analyst / data scientist
- Tell me about an analysis or model that changed a business decision. Listen for: business impact, not only technique.
- Where did the data come from, and what problems did you find with it? Listen for: data quality awareness.
- Which tools and languages do you use for your work? Listen for: real usage, reasons.
- How do you explain your results to people without a data background? Listen for: clear storytelling.
- How do you check that your conclusions are correct? Listen for: validation, sanity checks.
- What is a project where the data did not support what the business expected? Listen for: honesty, handling pushback.
- Tell me about a product decision you made and how you made it. Listen for: data, user research, clear reasoning about what was left out.
- How do you decide what goes into the next release? Listen for: prioritisation method.
- How do you work with developers and designers day to day? Listen for: process, collaboration.
- Which metrics did you own, and how did they change? Listen for: specific metrics and results.
- Tell me about a feature that failed. What did you learn? Listen for: reflection, ownership.
- How do you talk to users? Listen for: a regular practice, not a one-off.
- Walk me through one project in your portfolio from the problem to the result. Listen for: process, not only final screens.
- How did you learn what users needed on that project? Listen for: research methods.
- How do you hand over designs to developers? Listen for: specs, design systems, communication.
- Tell me about a time a design did not work for users. What did you change? Listen for: testing, iteration.
- How do you handle feedback from a stakeholder you disagree with? Listen for: arguments, compromise.
- Which tools do you use, and how do you keep a design consistent? Listen for: design system practice.
- Tell me about the project you are running now: team, timeline, how work is planned. Listen for: a clear picture of scope and process.
- Which process do you use, and what did you change in it? Listen for: adapting the process, not following it blindly.
- Tell me about a project that was at risk of missing a deadline. What did you do? Listen for: risk management, communication.
- How do you handle a conflict between team members? Listen for: a specific case.
- How do you report progress to stakeholders? Listen for: transparency, format.
- How do you know a project went well? Listen for: outcome criteria, not only on time.
Questions that show the level: junior, middle, senior
Titles differ from company to company, so do not trust the word “Senior” on a CV. Ask about scope and independence:
- Junior — works on defined tasks with guidance. Ask: “What did you learn in the last six months, and how?” and “Tell me about a task you could not solve alone. How did you get unstuck?” Listen for learning speed and asking for help at the right time.
- Middle — owns features end to end. Ask: “Tell me about a feature or area you owned end to end” and “Have you helped a newer colleague? How?”
- Senior — makes decisions that affect the team and grows others. Ask: “Tell me about a decision you made that affected the whole team” and “How do you grow the people around you?”
Motivation questions: what IT candidates actually ask about
Good IT candidates are interviewing you as much as you are interviewing them. Prepare answers about the product, the team, the stack, how decisions are made, the work format and growth — and ask about motivation directly:
- What is important for you in your next role?
- Why are you looking for a change now?
- What would make you say no to an offer?
- What kind of team and manager do you work best with?
Red flags in an interview with an IT candidate
- Buzzwords without examples. A list of technologies, but no project where they were used.
- No clear personal contribution. Only “we did” — never “I did”.
- No interest in the product or the team. No questions at the end, or only about salary.
- Everyone else is to blame. Every failed project was the fault of the manager, the client or the team.
- The title does not match the scope. “Senior” who has never owned a decision.
Five mistakes recruiters make with IT candidates
- Pretending to be technical. Candidates see it at once; say what you assess and what the team assesses.
- Reading questions from a list without listening. The follow-up question — “what exactly did you do?” — matters more than the first one.
- Judging by the stack keywords only. The same technology on two CVs can mean very different experience.
- Not preparing to answer their questions. Know the product, the team, the process and the conditions before the call.
- Different questions for different candidates. Use one set per role and level, so you can compare.
Where to find developers, how to assess them and how to write to them so they answer is what the Hiring Developers course covers. For the wider picture — developers, product and project management, DevOps, Agile, data and ML, and how to assess IT people — see the IT Recruiter course.
