Software engineer interview questions: 22 questions and a scorecard for interviewers
The short answer
Good software engineer interview questions test how a candidate debugs, designs systems at the level the role needs, writes and reviews code, weighs trade-offs and works with product. Ask for real examples, such as the hardest bug they fixed recently or a system they helped build, and listen for the steps they took and the part that was theirs. A recruiter screen before the client’s technical round should confirm the tech stack, work arrangement, right to work, start date and pay expectations. Score every candidate against the same five criteria so the decision rests on evidence.
All 22 questions with why you ask each one, what a strong answer shows and follow-ups, plus the software engineer scorecard and rating guide. Free to download and adapt; no sign-up needed.
When to use these questions
Software engineers turn requirements into working, maintainable systems, so an interview needs to show how someone reasons through problems and makes trade-offs, not only which languages appear on their resume. The strongest evidence comes from specific bugs, designs and releases, described step by step, with a clear line between their own work and the team’s.
For agency recruiters, the screen before the client’s technical round is where to confirm the essentials: recent production experience with the client’s stack, the level of design work the role needs, how clearly the candidate communicates, and the practical facts of work arrangement, on-call, start date and pay expectations. Leave coding assessment to the client’s engineers and pass on clear notes about what you heard.
22 software engineer interview questions
Grouped by what they test. Pick the questions that match the role, ask every candidate the same ones in the same order, and score each answer against the scorecard below.
Problem solving and debugging
Ask about real bugs and real systems. How someone narrows down a problem says more than the languages they list.
Question 1: Tell me about the hardest bug you tracked down in the last year. How did you find the cause?
- Why ask it:
- Tests a systematic debugging method rather than luck.
- A strong answer shows:
- Clear steps: reproducing the issue, forming and testing hypotheses, using logs or a debugger, and confirming the fix.
- Follow-up:
- What would have caught it sooner?
Question 2: A feature that worked yesterday is failing in production today, and nobody thinks anything changed. Where do you start?
- Why ask it:
- Shows how they reason under uncertainty and pressure.
- A strong answer shows:
- Limiting user impact first, then checking recent deploys, config and dependency changes, logs and metrics before touching code.
Question 3: Walk me through the architecture of a system you worked on recently, and point to the part you built.
- Why ask it:
- Tests whether they understand how the pieces fit, and separates their contribution from the team’s.
- A strong answer shows:
- A clear sketch of components and data flow, with their own part named precisely.
- Follow-up:
- What would you change about it now?
Question 4: If you had to design [a feature at the client’s scale, such as a notification service or an order history page], how would you approach it?
- Why ask it:
- Tests system design at the level the role needs, not textbook answers.
- A strong answer shows:
- Clarifying questions about users and load first, then a simple design, with the trade-offs named and the parts they would scale later.
- Follow-up:
- What breaks first if traffic grows tenfold?
Question 5: Tell me about a technical decision you made that turned out to be wrong. How did you find out, and what did you do?
- Why ask it:
- Tests judgment and honesty about mistakes.
- A strong answer shows:
- Ownership of the decision, the signal that showed it was wrong, and how they corrected course.
Code quality, testing and review
These questions show the habits behind the code: how they test, review and keep a codebase healthy.
Question 6: How do you decide what to test, and at which level, when you build a new feature?
- Why ask it:
- Shows a practical testing approach rather than a slogan.
- A strong answer shows:
- Risk-based choices between unit, integration and end-to-end tests, with an example of a test that caught a real problem.
Question 7: Describe a code review comment you gave that changed someone’s approach. How did you phrase it?
- Why ask it:
- Tests technical standards and how they deliver feedback.
- A strong answer shows:
- A substantive issue such as correctness, security or maintainability, raised with reasons and respect.
Question 8: Tell me about review feedback on your own code that you disagreed with. What happened?
- Why ask it:
- Shows openness to feedback and how disagreements get settled.
- A strong answer shows:
- Engaging with the reasoning, changing their mind when the point was valid, and resolving it with evidence or a short conversation.
Question 9: What does a pull request from you usually look like before you ask for review?
- Why ask it:
- Reveals everyday habits around scope, testing and context for reviewers.
- A strong answer shows:
- Small, focused changes with tests, a clear description and notes on anything risky.
Question 10: When have you paid down technical debt, and how did you justify the time?
- Why ask it:
- Tests whether they connect code quality to business outcomes.
- A strong answer shows:
- A specific improvement, the cost of leaving it alone, and how they agreed the time with the team or product owner.
Delivery, trade-offs and working with product
Engineers work inside deadlines and changing requirements. Look for reasoned trade-offs and plain explanations.
Question 11: Tell me about a time you had to choose between shipping quickly and building something properly. What did you decide, and why?
- Why ask it:
- Tests pragmatic judgment about trade-offs.
- A strong answer shows:
- A reasoned choice tied to risk and user impact, with any shortcut tracked and revisited.
Question 12: How do you handle a requirement from product that you think is unclear or technically risky?
- Why ask it:
- Shows how they collaborate with product and design.
- A strong answer shows:
- Asking questions early, proposing alternatives with their costs, and agreeing a decision rather than building it silently or refusing.
Question 13: Explain a project you worked on as if I were a client with no engineering background.
- Why ask it:
- Tests communication, and a non-technical recruiter can judge it directly.
- A strong answer shows:
- Plain language, the problem it solved for users, and their own role, without hiding behind jargon.
Question 14: Tell me about a project that slipped. When did you realize it, and who did you tell?
- Why ask it:
- Tests honest estimation and early communication.
- A strong answer shows:
- Raising the risk early with a revised plan, rather than surprising stakeholders at the deadline.
Production, on-call and teamwork
Ask how they behave when something breaks and how they work alongside other engineers.
Question 15: Describe a production incident you helped resolve. What was your role, and what changed afterwards?
- Why ask it:
- Tests calm incident handling and learning from failure.
- A strong answer shows:
- Reducing impact first, clear updates during the incident, and a blameless follow-up with concrete fixes.
- Follow-up:
- What did the postmortem change in how the team works?
Question 16: What monitoring and alerts would you want in place before a new service goes live?
- Why ask it:
- Shows operational awareness beyond writing code.
- A strong answer shows:
- Specific signals such as errors, latency and key business events, with alerts that someone can act on.
Question 17: How do you help a new engineer get productive on a codebase you know well?
- Why ask it:
- Tests collaboration and, for senior roles, mentoring.
- A strong answer shows:
- Practical steps such as pairing, pointing to or writing docs, and small first tasks with real ownership.
Question 18: Which piece of work from the last two years are you proudest of, and which part of it was yours alone?
- Why ask it:
- Separates personal contribution from team achievement, which any recruiter can assess.
- A strong answer shows:
- A specific outcome, with a clear line between what they did and what the team did.
Must-haves and logistics
Ask these of every candidate before the client’s technical round, and check the answers against the resume.
Question 19: Which languages, frameworks and cloud platforms have you used in production in the last two years, and on what kind of project?
- Why ask it:
- Confirms hands-on experience with the client’s stack, not only familiarity.
- A strong answer shows:
- Specific technologies tied to real projects and recent dates, with honesty about anything used only in side projects.
Question 20: The role is [remote, hybrid or on-site, location, and any on-call rotation]. Does that work for you?
- Why ask it:
- Rules out arrangement mismatches before the client invests interview time.
- A strong answer shows:
- A clear yes, or the specific constraint.
Question 21: Are you legally authorized to work in [country] for this employer, and will you need visa sponsorship now or in the future?
- Why ask it:
- Confirms eligibility; ask every candidate the same question in the same way.
- A strong answer shows:
- A direct answer, recorded the same way for every candidate.
Question 22: What pay range are you looking for in this role, and when could you start?
- Why ask it:
- Checks fit with the client’s budget and timeline without asking about pay history.
- A strong answer shows:
- A realistic range and a firm notice period or start date.
Software engineer interview scorecard
Five criteria for this role, with what a score of 1, 3 and 5 looks like. Scores of 2 and 4 sit between them.
| Criterion | What it means | Score 1 looks like | Score 3 looks like | Score 5 looks like |
|---|---|---|---|---|
| Problem solving and debugging | Narrows down problems methodically and confirms the fix. | Describes guessing, or someone else finding the cause. | A clear, step-by-step example of finding and fixing a real bug. | Several examples where they tested hypotheses, found the root cause and added a guard against it recurring. |
| Technical depth for the level | Designs and explains systems at the scope the role needs. | Uses buzzwords but cannot explain how the components connect. | Explains a recent system clearly and proposes a sound design for the prompt. | Asks clarifying questions, weighs alternatives and names what would break first. |
| Code quality and testing | Writes maintainable, tested code and gives useful review. | No example of testing or review, or treats them as overhead. | Consistent testing habits and a constructive review example. | Raises the team’s standards, with examples of tests or reviews that prevented real problems. |
| Ownership and delivery | Owns outcomes, flags risks early and follows through. | Cannot say what they personally delivered, or blames others for slips. | A clear personal contribution and an example of raising a delay early. | Drives work end to end, including after release, and shows what they learned from incidents. |
| Communication and collaboration | Explains technical work plainly and works well with product and peers. | Jargon-heavy; cannot explain the work to a non-engineer. | A clear explanation and a constructive example of working with product. | Adapts to any audience, handles disagreement well and helps others get productive. |
The 1–5 rating scale
The same scale for every criterion and every candidate.
| Score | Level | What it means |
|---|---|---|
| 1 | Well below requirement | No relevant evidence, or an answer that contradicts the requirement. |
| 2 | Below requirement | Partial evidence with important gaps. |
| 3 | Meets requirement | Clear, relevant evidence at the level the role needs. |
| 4 | Above requirement | Strong, specific evidence beyond the expected level. |
| 5 | Exceptional | Repeated high-quality evidence with clear impact. |
How to run the interview with these software engineer interview questions
- 01
Step 01
Agree the must-haves first
Confirm the essential credentials, experience and availability with the hiring manager or client before any interviews. - 02
Step 02
Pick 8 to 12 questions
Take the must-have questions, then the questions that test what this role needs most. Use the same set, in the same order, for every candidate. - 03
Step 03
Ask for real examples
When you hear “we” or “I would”, ask what the candidate personally did, and what happened in the end. - 04
Step 04
Score before you discuss
Rate each criterion on the scorecard with the evidence behind it, then compare with other interviewers. - 05
Step 05
Verify before you submit
Check licenses, certifications and right to work against the original source before you put the candidate forward.
Red flags, and questions not to ask
- Says “we” throughout and cannot say which part of a project they built themselves.
- Lists technologies on the resume but cannot describe using them on a real project.
- Cannot explain why a technical decision was made or what the alternatives were.
- Blames other people or teams for every bug, outage or missed deadline.
- Dismisses testing, code review or documentation as things that slow them down.
- Age, marital or family status, pregnancy or plans for children, religion, ethnicity or national origin, sexual orientation or gender identity. These are protected characteristics under the UK Equality Act 2010 and US federal law, and they say nothing about whether someone can do the job.
- Health, sickness absence or disability before an offer. You can ask whether the candidate needs any adjustments for the interview, and whether they can do the essential tasks of the job.
Screen software engineer applicants before the first call
Add these questions to a Beatview AI interview and every applicant answers them on video or audio, with the same time limit. Beatview scores each answer against your criteria and shows the reasoning, and you can share the shortlist with your client through a password-protected link. AI interviews are on the Pro plan; the Free plan screens resumes for one active job.
Software engineer interview questions: frequently asked questions
Still deciding?
Bring a live vacancy and we’ll walk through where automation ends and recruiter review begins.
Ask for real examples that test debugging, system design at the right level, code quality and testing, trade-offs and how they work with product, such as the hardest bug they fixed recently or a production incident they helped resolve. Add must-have questions on the client’s tech stack, work arrangement, right to work, start date and pay expectations, and ask every candidate the same questions in the same order.
Focus on what you can judge: ask the candidate to explain a project in plain language, to name the part they built themselves, and which technologies they used in production and when. Specific answers with dates and outcomes are a good sign; vague “we” answers and buzzwords are worth probing. Leave detailed technical assessment to the client’s technical round, and pass on notes about anything you could not verify.
Usually not. Agree the split with the client: the recruiter screen confirms stack match, ownership, communication and logistics, and the client’s engineers assess coding in their own technical round. If a client wants a test earlier, use the one they choose rather than inventing your own.
Keep the same questions and change the scope you expect. A junior engineer might describe debugging a feature they built; a senior engineer should talk about designing systems, weighing trade-offs across teams, leading incidents and mentoring others.
Get the software engineer interview questions template
All 22 questions with why you ask each one, what a strong answer shows and follow-ups, plus the software engineer scorecard and rating guide.
Opens in Excel, Google Sheets or Numbers. Version 1 October 2026.