How long should a software engineer interview loop be?

For a mid-level role, a 20-minute screen plus three or four interviews of 45 to 60 minutes usually covers five competencies. Every extra round adds days and asks more of the candidate. Add one only if it assesses a competency no other round covers.

Should we use take-home assignments?

They can show real work, but they cost the candidate unpaid time and favor people with free evenings. If you use one, cap it at two to three hours, say what you will assess, and discuss it in a follow-up interview. A live, collaborative exercise or a walk through code the candidate already wrote are fair alternatives; offer a choice where you can.

Are algorithm puzzles a good test for software engineers?

Only when the job involves that kind of work. Puzzle questions mostly reward practice on puzzles. A realistic problem from your own domain, like the rate limiter above, shows how someone reasons about the code they would actually write.

Can candidates use AI coding assistants during the interview?

Decide before the loop and tell every candidate the same rule up front. If your engineers use assistants daily, allowing them and asking the candidate to explain and check the output tests a skill the job needs. If you ban them, say so in the invitation.

How do we adapt this kit for junior or senior engineers?

For a junior role, shrink the design question to a single component and weigh code quality and learning more heavily. For a senior role, widen the design scope, expect trade-offs across teams, and add influence beyond their own team to the ownership questions. Keep the anchors in writing either way.

Free interview kit

Software Engineer interview kit: questions and rubric

For hiring teams interviewing a mid-level software engineer, roughly three to six years in, who ships features end to end with light guidance. It covers a short screen, five competencies with behavioral, situational and work-sample questions, anchored ratings, the questions never to ask, and a rule for deciding.

5 competencies · 13 questions · anchored 1-to-5 scale · Updated 10 October 2026 · Written by the Itya team

Share this kitLinkedIn X WhatsApp Email

How to use this kit

Agree the competencies with the hiring manager before the job is posted.
Give each interviewer one or two competencies, so nothing is asked twice.
Ask every candidate the same core questions; follow up freely.
Rate each competency against the anchors straight after the interview, alone.
Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

What draws you to this role, and what kind of engineering work do you want more of in your next job?
Walk me through the system you know best: what it does, which part you built, and what you would change about it.
This role works mostly in the stack named in the job description. Which parts of it have you shipped production code in, and for how long?
The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

Competency 1

Problem decomposition

Most engineering work arrives as an ambiguous request. Engineers who break it into small, testable steps ship sooner and surprise their team less.

Work sample: design a rate limiter for an internal API that allows each user 100 requests a minute. Talk me through how you would approach it before writing any code.
Follow up with
- Which requirement would you clarify with the requester before starting?
- What would you build first, and how would you know it works?
- What changes if the limit must hold across five servers instead of one?
Strong answer
Restates the problem and asks clarifying questions (per user or per API key? what happens when the limit is hit?). Names edge cases, proposes a simple first version, and explains how it changes under concurrency or several servers. Thinks aloud so you can follow the reasoning.
Weak answer
Starts coding or names a library straight away, never asks what 'per user' means, and cannot say how they would test it. When the constraint changes, starts over instead of adapting the first design.
Tell me about a time you were handed a vague or underspecified task. How did you turn it into work you could start on?
Follow up with
- What questions did you ask, and of whom?
- How did you split the work, and what shipped first?
- What would you do differently now?
Strong answer
Names a specific task, the unknowns they found, who they asked, and how they cut it into increments that each delivered something. Can say what shipped first and why.
Weak answer
Describes the final solution but not how they got there, or says they 'just figured it out'. Waited for complete requirements, or built everything in one long-lived branch.
What would you do if, halfway through a two-week task, you discovered it would take six weeks?
Follow up with
- Who do you tell, and when?
- What options would you bring them?
Strong answer
Tells the lead as soon as the estimate changes, explains why, and brings options: cut scope, ship a smaller first version, or move the date. Treats the new estimate as information, not a failure to hide.
Weak answer
Plans to work longer hours and catch up quietly, or waits until the deadline to raise it. Brings the problem with no options.

Rating	What it looks like
5 · Strong	Clarifies requirements unprompted, sequences the work into small testable increments, names edge cases and failure modes, and adapts the design cleanly when a constraint changes.
3 · Mixed	Breaks the problem into reasonable steps and handles the main cases. Needs a prompt to ask clarifying questions or to consider edge cases and scale.
1 · Weak	Jumps to a solution without clarifying the problem. Cannot break the work into steps or say how to test each one. Misses obvious edge cases even when prompted.

Competency 2

Code quality and testing

Code is read far more often than it is written. A mid-level engineer is expected to leave code that teammates can change safely.

Work sample: here is a 60-line function from a real pull request, anonymized, with a missing null check, a misleading name and no tests. Review it as you would for a teammate.
Follow up with
- Which of your comments would block the merge, and which are suggestions?
- What tests would you ask for?
- How would you word your most important comment?
Strong answer
Finds the real defects first (the null case, the misleading name), separates blocking comments from optional ones, proposes specific tests, and explains the why behind each comment. The tone is direct and respectful.
Weak answer
Comments only on formatting or style, misses the planted defect, or rewrites the whole function without saying what was wrong. Comments read as orders or as criticism of the author.
Tell me about a bug you shipped to production. How was it found, how did you fix it, and what changed afterwards?
Follow up with
- Why did your tests not catch it?
- What did you add so it could not happen again?
Strong answer
Owns the bug plainly, explains the root cause rather than the symptom, and describes the fix plus the test or check added to prevent a repeat. Names a habit that changed.
Weak answer
Cannot recall a bug they shipped, blames QA or another team, or describes a hotfix with no follow-up test or process change.
What would you do if the module you need to change has no automated tests at all?
Follow up with
- What is the smallest test you would write first?
- How would you make the case to your product manager for the extra time?
Strong answer
Adds characterization tests around the behavior they are about to change, makes the change in small steps, and leaves the module better covered without stalling the feature. Can explain the trade-off to a non-engineer.
Weak answer
Changes the code and hopes, or insists on rewriting the module with full coverage before any feature work. Shows no sense of proportion.

Rating	What it looks like
5 · Strong	Finds the real defects first, tests edge cases and failure paths by habit, explains the reasoning behind each review comment, and improves untested code in proportion to the change.
3 · Mixed	Writes readable code with tests for the main path. Finds the obvious defects in review but misses subtler ones, or does not separate blocking from optional feedback.
1 · Weak	Misses clear defects in review, cannot describe how they test their own work, and treats testing as someone else's job.

Competency 3

System design (scaled to level)

A mid-level engineer will not design the whole platform, but they make design choices every week. Ask for the design of a component, not a global-scale system.

Work sample: design a service that sends appointment reminders by email and SMS at a time each user chooses. Start with one city's worth of users, then tell me what changes at ten times that.
Follow up with
- Where would you store the scheduled reminders, and why there?
- What happens if the SMS provider is down for an hour?
- How would you know the system is working in production?
Strong answer
Sketches the main pieces (API, store, scheduler, workers, provider), ties each choice to the stated scale, handles retries and duplicate sends, and names what they would monitor. Changes the design for the larger load only where it is needed.
Weak answer
Lists technologies without connecting them to requirements, designs for planetary scale from the start, or ignores failure: no retries, no protection against double sends, no monitoring.
Tell me about a design decision you made that you would make differently today.
Follow up with
- What did you know then, and what do you know now?
- What did the decision cost the team?
Strong answer
Describes a concrete trade-off, the information available at the time, what went wrong, and what they learned. Separates a reasonable call that met bad luck from a call they should have made differently.
Weak answer
Says they would change nothing, or offers a trivial example. Blames the requirements or other people for the outcome.

Rating	What it looks like
5 · Strong	Ties every choice to a requirement, designs for the load in front of them with a clear next step for growth, and covers failure, retries, duplicate work and monitoring without prompting.
3 · Mixed	Produces a workable design for the stated load and handles some failure cases. Needs prompting on retries, monitoring or the cost of each choice.
1 · Weak	Cannot move beyond a list of components. Ignores failure and data consistency, or designs for a scale the problem does not have.

Competency 4

Collaboration and code review

Most of an engineer's impact passes through other people: reviews, design discussions, hand-offs. How they disagree matters as much as whether they are right.

Tell me about a time you disagreed with a teammate about a technical approach. What happened?
Follow up with
- What was their strongest argument?
- How was it decided?
- What did you do once the decision was made?
Strong answer
States the other person's position fairly, describes testing the disagreement with data or a small spike, and committed to the decision once made, even when it went the other way.
Weak answer
Describes the teammate as wrong or difficult, cannot state their argument, or won by escalating. Kept reopening the question after it was decided.
Tell me about the most useful code review feedback you have received. What did you do with it?
Follow up with
- How do you handle review comments you disagree with?
- How quickly do you usually review other people's code?
Strong answer
Names specific feedback, what changed in their practice, and how they now give feedback to others. Treats review as shared ownership of the codebase.
Weak answer
Cannot recall useful feedback, or treats review as a gate to get past. Describes defending their code rather than learning from the comment.
What would you do if a new teammate kept opening very large pull requests that nobody wanted to review?
Follow up with
- What would you say to them, and where would you say it?
Strong answer
Talks to them privately and kindly, offers to pair on splitting the next one, and suggests a team norm rather than a personal rule. Focuses on the outcome: faster, safer reviews.
Weak answer
Ignores it, goes to the manager first, or leaves terse public comments. Frames it as the new person's failing rather than a team habit to fix.

Rating	What it looks like
5 · Strong	States opposing views fairly, settles disagreements with evidence, commits once a decision is made, and gives specific, kind, timely feedback that improves the team's habits.
3 · Mixed	Works well with others in the examples given and accepts feedback. Handles disagreement politely but relies on someone else to resolve it.
1 · Weak	Describes conflict as other people's fault, cannot state an opposing view, and gives or receives feedback defensively.

Competency 5

Ownership and delivery

Engineers who own outcomes, not just tickets, find the problems nobody assigned to them. It shows in how they ship, monitor and follow through.

Tell me about something you shipped that you are proud of. Take me from the first conversation to the week after release.
Follow up with
- How did you know it worked once it was live?
- What did you do after release that nobody asked you to?
- What would you have cut to ship it in half the time?
Strong answer
Gives a specific project, separates their own part from the team's, says how success was measured, what they watched after release, and one follow-up they did unprompted.
Weak answer
Says 'we' throughout with no clear personal contribution, stops the story at merge, or cannot say whether the work achieved its goal.
What would you do if you were paged at 2 a.m. for an outage in a service another team owns?
Follow up with
- What do you do the next morning?
- What would you write down, and for whom?
Strong answer
Stabilizes first with the runbook or a rollback, keeps people informed, brings in the owning team, and follows up with a blameless write-up and a fix. Separates mitigation from root cause.
Weak answer
Waits for the owning team without acting, or makes risky changes alone without telling anyone. Treats the incident as closed once the alert stops.

Rating	What it looks like
5 · Strong	Defines success before starting, checks it after release, follows through on problems nobody assigned, and keeps others informed without being asked.
3 · Mixed	Delivers assigned work reliably and checks it after release. Takes initiative when asked, but rarely beyond their own tickets.
1 · Weak	Describes work only at the ticket level, cannot say whether their work achieved its goal, and stops caring at merge.

Never ask

Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about engineering skill, and age-based decisions are unlawful in many places.
Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region, language and community. If location matters, ask whether the candidate can work from the job's location.
Don't ask about health conditions, disabilities or past medical leave. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
Don't ask for salary history where the law restricts it, as many US states and cities do. Why: it carries past pay gaps into the new offer. Ask for the expected compensation range, and where current pay is customary, as in India, still set the offer from the role's band.
Don't screen or score on college tier, entrance-exam rank or a university's name as a proxy for skill. Why: it measures access more than ability and filters out able engineers who learned elsewhere. Assess the work instead.

Making the decision

Each interviewer rates their competencies alone, against the anchors, before the debrief. Any competency rated 1 by two interviewers is a no. A hire needs an average of 3.5 or higher, with no 1 on problem decomposition, code quality and testing, or ownership and delivery. The hiring manager decides after the debrief and records the quotes and work-sample evidence behind the decision.

Questions people ask

How long should a software engineer interview loop be?: For a mid-level role, a 20-minute screen plus three or four interviews of 45 to 60 minutes usually covers five competencies. Every extra round adds days and asks more of the candidate. Add one only if it assesses a competency no other round covers.
Should we use take-home assignments?: They can show real work, but they cost the candidate unpaid time and favor people with free evenings. If you use one, cap it at two to three hours, say what you will assess, and discuss it in a follow-up interview. A live, collaborative exercise or a walk through code the candidate already wrote are fair alternatives; offer a choice where you can.
Are algorithm puzzles a good test for software engineers?: Only when the job involves that kind of work. Puzzle questions mostly reward practice on puzzles. A realistic problem from your own domain, like the rate limiter above, shows how someone reasons about the code they would actually write.
Can candidates use AI coding assistants during the interview?: Decide before the loop and tell every candidate the same rule up front. If your engineers use assistants daily, allowing them and asking the candidate to explain and check the output tests a skill the job needs. If you ban them, say so in the invitation.
How do we adapt this kit for junior or senior engineers?: For a junior role, shrink the design question to a single component and weigh code quality and learning more heavily. For a senior role, widen the design scope, expect trade-offs across teams, and add influence beyond their own team to the ownership questions. Keep the anchors in writing either way.

A kit is step one.

Itya holds every interviewer to the same rubric, records the interview, and drafts the scorecard with the quotes behind each rating. The AI drafts; your team decides. Free plan, unlimited teammates.

Run this kit in Itya All interview kits