How to Conduct a Technical Interview as an Interviewer

What a good interview looks like

A technical interview answers one question: can this person do this job in this team? Not "are they as smart as me" and not "do they know my favourite trick".

Good interviews share five traits:

• a clear profile of the role, written before the first candidate;
• structured questions and tasks, the same for everyone at the same level;
• a scoring rubric that describes what weak, solid and strong answers look like;
• evidence-based feedback, written independently before discussing with other interviewers;
• a respectful experience that leaves candidates with a fair impression, even when rejected.

Step 1. Define the profile

Agree with the hiring manager on what the person will actually do in the first months. Turn it into 3-6 competencies to evaluate, for example:

• coding and code quality;
• problem solving and debugging;
• system design (for mid-level and above);
• knowledge of the main stack;
• collaboration and communication.

For each competency, define the expected level. A junior is not expected to design a distributed system; a senior is expected to discuss trade-offs without prompting.

Assign each competency to a specific interview stage so nothing is checked twice and nothing is missed.

Step 2. Design questions and tasks

Prefer tasks close to real work. Debugging a small piece of code, extending an existing function, designing an API for a familiar feature or reviewing a pull request tell you more than puzzles.

Good task properties:

• Solvable in the time slot by a candidate at the target level, with room to go deeper.
• Layered: a basic version, then follow-ups that raise complexity.
• Clear input and expected output, so the candidate does not waste time guessing the requirements.
• Tested on colleagues before using it with candidates.

Prepare follow-up questions in advance: "How would you test this?", "What changes if the data grows significantly?", "Where could this fail in production?".

Step 3. Write a scoring rubric

Without a rubric, scores reflect mood and personal taste. Describe each level with observable behaviour:

Score each competency separately, then give an overall recommendation.

Step 4. Reduce bias

• Ask everyone the same core questions for the same level.
• Take notes during the interview: what the candidate said and did, not your impressions.
• Write feedback before talking to other interviewers so opinions do not anchor each other.
• Separate signal from style: accent, confidence, the university name or similarity to you are not competencies.
• Avoid "culture fit" as a vague reason; if collaboration matters, define what you evaluate.
• Calibrate regularly: compare scores with other interviewers and review past decisions.

Step 5. Candidate experience

The candidate is evaluating your company too. Simple rules:

• Introduce yourself and the format at the start: how long, what stages, whether they may use documentation.
• Let them ask clarifying questions and treat questions as a positive signal.
• Give hints when stuck and note the hint in your feedback, instead of letting silence last for minutes.
• Leave time for their questions at the end and answer honestly.
• Do not hint at the outcome during the interview; the decision is made after all feedback is collected.
• Make sure they hear back within the time you promised.

Step 6. Write useful feedback

Feedback is for the hiring decision, so it must be specific:

Recommendation: Hire (mid-level backend)

Problem solving - 3: Clarified input format, built a working solution,
handled empty input after a prompt about edge cases.
Code quality - 4: Clear names, extracted helper functions, wrote two tests.
System design - 2: Proposed a single database without discussing load;
improved after the question about read-heavy traffic.
Concerns: Limited experience with caching; can be addressed in onboarding.

Avoid "smart", "not a fit" or "weak" without evidence.

Common mistakes

• Improvising questions for each candidate.
• Testing trivia that a developer would look up in seconds.
• Talking more than the candidate.
• Judging by the final answer only, ignoring the reasoning.
• Rushing to fill a vacancy and lowering the bar without saying so.