Software Engineer Interview Guide
A structured software engineer interview guide — the competencies that matter at this seniority, questions that test real engineering judgement rather than interview performance, evidence to look for and a practical scorecard.
Published 2026-08-26 · Reviewed 2026-08-26
Hiring a software engineer is hard because the interview rarely matches the job. Abstract whiteboard puzzles can over-emphasise performance under interview conditions and may not reflect day-to-day engineering work. Where practical exercises are used, they should resemble the decisions and problems the role actually involves. This guide gives you a structured framework for the interview: the competencies to assess, evidence to look for, questions to ask with follow-up probes, and a practical scorecard.
These indicators are prompts for structured evaluation, not model answers. Candidates may demonstrate competence through different examples or approaches. An unfamiliar answer is not automatically a weak answer — use follow-up questions before reaching a conclusion. "Not enough evidence" is a valid scorecard outcome. The final decision remains with the human hiring team.
Who this guide is for
This guide is for hiring managers, engineering leads, founders and recruiters interviewing software engineers, including those who are not themselves senior engineers and need a structured way to assess technical depth.
Role overview
A software engineer designs, builds and maintains the systems that run a business. The role ranges from front-end work on user interfaces to back-end services and data infrastructure. At senior levels, engineers make architectural decisions, mentor juniors and influence technical strategy. The interview should test practical engineering judgement, not just coding speed.
How the role varies
The role varies widely: a startup engineer may own delivery end-to-end including deployment and on-call, while an engineer in a large enterprise may work within a narrowly defined service boundary. Seniority shifts the balance from implementation toward architecture, mentoring and technical strategy. B2C teams often emphasise scale and reliability under variable load, B2B teams may focus on integration and contractual SLAs, and regulated industries add testing, audit and compliance expectations.
Written and maintained by Kippler. Published — not individually expert-reviewed.
What the interviewer should assess
A software engineering interview should test four areas: technical depth and problem-solving, system design and architectural thinking, collaboration and communication, and engineering maturity. Each matters — a brilliant coder who cannot work in a team can be as risky as a great communicator who cannot write maintainable code.
Role-specific competencies
Technical depth
Do they understand the tools and languages they claim? Can they explain trade-offs, not just syntax?
System design
Can they design a system that handles scale, failure and change? Do they think about data models, APIs and boundaries?
Code quality and maintainability
Do they write code that others can read? Do they test their work? Do they care about the code that exists, not just the code they write?
Collaboration and communication
Can they explain technical decisions to non-technical colleagues? Do they review others’ code constructively? Do they document their work?
Engineering maturity
Do they understand deployment, monitoring and incident response? Do they think about the operational consequences of their code?
Recommended interview structure
A 60–90 minute interview is a useful starting point for this role, but the appropriate length depends on the interview stage, number of competencies, use of practical exercises and whether the assessment is split across interviewers. Structure it in four parts: a brief career discussion (10 minutes), a system design or architecture discussion (25 minutes), a practical problem-solving discussion (20 minutes), and the candidate’s questions for you (10 minutes). Consider avoiding live coding exercises unless they reflect the actual day-to-day work.
Adapt this guide to your role
Adjust the depth expected according to seniority. A junior candidate should not be marked down for lacking architecture ownership or production-incident experience if those responsibilities have not yet been part of their role. Beyond seniority, the role varies considerably by company stage and shape. In a startup or scale-up, expect broader ownership — deployment, on-call, infrastructure and product judgement may all fall to the engineer; weight questions toward end-to-end delivery and pragmatism under constraint. In an SME, probe breadth and the ability to wear several hats, while in a large enterprise focus on depth within a service boundary, cross-team collaboration and working within established standards. IC roles call for deeper technical questions on the individual’s own work, while leadership or staff roles shift toward architecture, mentoring, technical strategy and influence without authority. B2C products often stress scale, reliability and latency under variable load, whereas B2B products bring integration, contractual SLAs and longer-running data correctness questions to the fore. Regulated industries (finance, health, safety-critical) add testing rigour, audit trails and compliance expectations, so probe those areas more heavily; non-regulated businesses may afford more latitude on process. Finally, calibrate for the tech stack and whether the role is primarily greenfield, maintaining a legacy codebase, or a mix of both.
Interview questions
Ask the same core questions to every candidate for this role. Use the follow-up probes to clarify vague answers and gather more evidence before scoring.
1. Tell me about a system you designed or significantly shaped. What were the key trade-offs you made?
What this is assessing: Whether they have made real architectural decisions, not just implemented someone else’s design. Whether they understand trade-offs rather than having a single default approach.
Follow-up probes
- What would you change about that design if you rebuilt it today?
- Which trade-off did the team disagree on most, and how did you resolve it?
- How did the system behave under failure, and what surprised you?
Evidence that may indicate strength
- Evidence of a specific system with concrete trade-offs
- Signals they can explain why they chose one approach over another
- Evidence they mention what they would do differently with hindsight
- Signals they consider non-technical factors such as team skills, timeline or maintenance
Points that may require further probing
- Points that may require further probing: they describe a system without explaining their own decisions
- An absence of any trade-offs — everything was obvious — may suggest limited ownership
- A focus on tool choice rather than architecture is worth probing
- An inability to describe what the system does at a high level may indicate limited involvement
2. A service’s traffic is expected to increase by 100 times and become significantly more variable. What would you want to understand before changing the architecture, and what areas would you review first?
What this is assessing: Whether they understand what changes at scale. Whether they think about failure modes, not just throughput.
Follow-up probes
- What would you measure first to confirm where the real bottleneck is?
- Which failure mode would concern you most, and why?
- How would you decide between re-architecting and incrementally scaling what exists?
Evidence that may indicate strength
- Evidence they clarify workload, latency and availability requirements before proposing changes
- Signals they talk about measuring likely bottlenecks before acting
- Evidence they consider failure modes and observability
- Signals they mention data consistency
- Evidence they weigh cost and operational complexity
- Signals they explain trade-offs rather than naming techniques without justification
Points that may require further probing
- Points that may require further probing: they suggest simply scaling the servers
- No mention of failure modes may suggest limited production experience
- A focus only on performance, not on correctness, is worth probing
- An absence of any concept of operational complexity at scale may indicate limited exposure
3. Describe a time you had to debug a production incident. What was the root cause and how did you find it?
What this is assessing: Whether they have owned production systems. Whether they approach debugging methodically rather than guessing. Whether they learn from incidents.
Follow-up probes
- How did you decide what to fix immediately versus what to address afterwards?
- What did you change to stop it happening again?
- How did you communicate with stakeholders while it was unresolved?
Evidence that may indicate strength
- Evidence of a specific incident and their role in resolving it
- Signals they followed a methodical process: reproduce, isolate, fix
- Evidence they mention post-incident follow-up such as prevention or monitoring
- Signals they are honest about mistakes — theirs or the team’s
Points that may require further probing
- For candidates without direct incident ownership, consider asking how they have diagnosed difficult defects, supported users, investigated failures or learned from mistakes in development or test environments
- Points that may require further probing: they approached debugging by guessing
- Blaming others or "the system" may suggest limited accountability
- No mention of preventing recurrence is worth probing
4. How do you decide when to write tests, and what to test?
What this is assessing: Engineering maturity. Whether they see testing as a pragmatic tool rather than a religious practice or a box-ticking exercise.
Follow-up probes
- Can you give an example of something you deliberately chose not to test?
- How do you decide when an integration test is worth the cost over a unit test?
- How do you handle testing when the team is under delivery pressure?
Evidence that may indicate strength
- Evidence they test the things that matter: business logic, edge cases, contracts
- Signals they understand the difference between unit and integration tests
- Evidence they talk about the cost of testing, not just the benefit
- Signals they have opinions about what not to test
Points that may require further probing
- Points that may require further probing: they suggest testing everything without thinking about cost
- An absence of any testing strategy may indicate limited engineering maturity
- An inability to distinguish between types of test is worth probing
- Seeing testing as someone else’s job may suggest limited ownership of quality
5. Tell me about a time you disagreed with a technical decision your team made. What did you do?
What this is assessing: Collaboration and maturity. Whether they can disagree without being toxic. Whether they can commit to a decision they did not make.
Follow-up probes
- How did you make sure your concerns were on the record without undermining the team?
- Looking back, were you right — and how did you find out?
- What would have changed your mind at the time?
Evidence that may indicate strength
- Evidence of a specific example with a real disagreement
- Signals they made their case with evidence
- Evidence they committed to the team’s decision once made
- Signals they can reflect on whether they were right in hindsight
Points that may require further probing
- Points that may require further probing: they claim not to have disagreed
- Quietly undermining a decision afterwards may indicate limited collaboration maturity
- A combative, win/lose framing of disagreement is worth probing
- An inability to describe how they made their case may suggest limited influencing experience
6. How do you approach reviewing a colleague’s pull request?
What this is assessing: Whether they review code constructively. Whether they care about the codebase as a shared resource. Whether they mentor through reviews.
Follow-up probes
- How do you decide what to block on versus what to leave as a suggestion?
- How do you review code in an area you are less familiar with?
- Can you describe a review where you learned something significant from the author?
Evidence that may indicate strength
- Evidence they read the code in context, not just the diff
- Signals they distinguish between blocking issues and suggestions
- Evidence they explain the reasoning behind their comments
- Signals they mention positive feedback, not just criticism
Points that may require further probing
- Points that may require further probing: they focus on style nits
- Approving everything without reading it may indicate limited engagement
- Blocking on personal preferences rather than team standards is worth probing
- An absence of any code review activity may suggest limited collaboration experience
Practical scorecard
Score each competency separately and record concise evidence supporting your score. Do not allow one impressive answer to inflate unrelated competencies.
Scoring scale
| Competency | Score |
|---|---|
| Technical depth Do they understand their tools and languages deeply? Can they explain trade-offs? | |
| System design Can they design for scale, failure and change? Do they think about data and boundaries? | |
| Code quality and maintainability Do they write readable, tested code? Do they care about the existing codebase? | |
| Collaboration and communication Can they explain technical decisions to non-technical colleagues? Do they review constructively? | |
| Engineering maturity Do they understand deployment, monitoring and incidents? Do they think operationally? |
How to use this scorecard
- Score each competency separately.
- Record concise evidence supporting the score.
- Do not allow one impressive answer to inflate unrelated competencies.
- Do not average away a material role-critical concern.
- Discuss scores only after each interviewer has recorded their independent judgement.
- Use the scorecard to support — not replace — the final human decision.
How to run the debrief
Hold the debrief promptly after the interview and have each interviewer record independent scores before any group discussion. Compare evidence competency by competency, and be explicit about what was not tested — for example, if no practical exercise was used, acknowledge that coding depth is inferred rather than demonstrated. Watch for halo effects from an articulate candidate; anchor the discussion in the specific examples they gave. Where interviewers disagree on technical depth, defer to the most senior engineer present and ask them to cite the evidence behind their reading.
Fairness and reasonable adjustments
Ask the same core questions of every candidate for this role. Use follow-up questions to clarify evidence rather than to catch candidates out. Make reasonable adjustments to format and timing where needed — for example, extra time, alternative formats, or breaks. Score evidence against the role requirements, not against your impression of the candidate's personality or communication style. Keep notes factual and job-relevant. Separate "not enough evidence" from "candidate lacks the skill" — the first may warrant a focused follow-up, the second is a scoring decision. The final hiring decision remains with the human hiring team.
Candidate experience: Explain the interview format at the beginning. Leave time for the candidate to ask questions. Avoid misleading candidates about the role or the team. Tell them what happens next and the expected timeline. Follow the agreed timing as closely as practical. Avoid repeatedly asking for information already covered in earlier stages.
Questions candidates may ask
Strong candidates will ask questions that reveal their priorities and how they think about the role. Be prepared to answer honestly — misleading a candidate about the role or the team risks a bad hire who leaves quickly.
- What does the team’s on-call and incident response look like?
- How are technical decisions made and escalated when people disagree?
- What does the codebase and deployment process look like day to day?
- How much of this role is greenfield work versus maintaining existing systems?
- What would I be expected to own in the first six months?
Frequently asked questions
Should I include a live coding exercise?
Only if it reflects the actual day-to-day work. A live algorithm puzzle on a whiteboard tends to test performance under observation, not engineering judgement. A discussion about system design or a take-home exercise that mirrors real work is often more informative.
How do I assess technical depth without being a senior engineer myself?
Focus on how they explain things. A strong engineer can usually explain a trade-off to someone less technical. If they hide behind jargon or cannot explain why they made a choice, that tells you something regardless of your own technical knowledge.
What if the candidate is self-taught with no formal qualifications?
Qualifications are a weak signal for software engineering. Use the interview to test practical judgement, system design and engineering maturity. A self-taught engineer who has shipped and maintained production systems may be stronger than a computer science graduate who has not.
How many interview rounds should I run?
One structured interview of 60 to 90 minutes is usually enough for a first round. If you need a second round, focus it on a specific gap — system design, team fit or a practical exercise — rather than repeating the same questions.
Interviewing someone now? Turn their CV — and, when you have one, the job description — into a tailored candidate assessment and interview plan.
Try 1 Candidate Free