Software Engineer Interview Questions: 25 Questions & Answers

By Rehearsa Team · 2026-09-29

Software Engineer Interview Questions: 25 Questions & Answers

Software engineer interviews test much more than whether you can write code. A strong candidate must explain technical decisions, clarify ambiguous requirements, test assumptions, discuss trade-offs, and show how they work with other people.

This guide covers 25 questions that appear across recruiter screens, hiring-manager interviews, technical rounds, system-design discussions, and behavioural interviews. Each includes what the interviewer is assessing, a model answer, and a practical preparation note. Use the answers as structures, not scripts: replace the details with your own projects, technologies, decisions, and results.

For a complete preparation sequence alongside these questions, read our software engineer interview preparation guide. If your process includes a timed test, use the coding exercise guide too.

How Software Engineer Interviews Are Usually Assessed

General and Motivation Questions

1. “Tell me about yourself.”

What they are assessing: Whether you can present a relevant, coherent career story rather than recite your CV.

Model answer: “I am a software engineer with four years of experience building backend services for transaction-heavy products. In my current role, I own services written in TypeScript and PostgreSQL, including a checkout workflow that handles about 400,000 requests a day. Over the last year I have focused on reliability: I introduced contract tests and improved alerting, which reduced failed releases by 30%. I am now looking for a role where I can take broader ownership of distributed systems while staying close to implementation, which is why this position stood out.”

Prepare: Build a 60–90 second answer around present role, relevant proof, and why this opportunity is the logical next step. Our tell me about yourself guide gives a fuller structure.

2. “Why do you want to work here?”

What they are assessing: Whether your interest is specific, informed, and connected to the actual engineering work.

Model answer: “Three things attract me. First, your public engineering articles show that the team is solving event-processing problems at a scale I have begun working with. Second, this role combines service ownership with direct product collaboration, rather than separating engineering from customer outcomes. Third, the migration described in the job post matches my recent experience decomposing a monolith. I could contribute immediately while learning from engineers who have completed that transition at greater scale.”

Prepare: Find one product fact, one engineering challenge, and one working-style detail. Avoid praise that could apply to any company.

3. “Why are you leaving your current role?”

What they are assessing: Professional judgement, motivation, and whether you are moving towards something rather than simply escaping.

Model answer: “I have learned a great deal in my current team and recently completed the service-modernisation project I was hired to support. The next step I want is end-to-end ownership of a larger product area and more exposure to system-design decisions. That scope is limited in my current structure, so I am looking for a role where it is part of the job rather than waiting for someone senior to leave.”

Prepare: Keep the answer positive, brief, and future-focused. Never criticise a manager or employer.

4. “What is your strongest technical skill?”

What they are assessing: Depth, self-awareness, and whether your strength is useful in this role.

Model answer: “My strongest skill is diagnosing reliability problems in backend systems. I combine application traces, database metrics, and user-impact data instead of optimising the first suspicious query. Recently, that approach showed that a timeout blamed on PostgreSQL was actually caused by retries multiplying traffic downstream. I changed the retry policy, added idempotency protection, and reduced p95 latency from 1.8 seconds to 620 milliseconds.”

Prepare: Choose one capability, prove it with a specific example, and explain its effect.

5. “What technical area are you improving?”

What they are assessing: Honest self-awareness and an active learning process.

Model answer: “I am improving my frontend performance knowledge. My backend background meant I could identify API latency quickly, but I was less confident distinguishing rendering, bundle, and network issues in the browser. I completed a performance course, paired with a frontend engineer on two investigations, and now use browser traces before proposing changes. I am not yet the team expert, but I can diagnose common problems independently and know when to involve someone deeper.”

Prepare: Name a real but non-fatal gap, show action already taken, and provide evidence of progress.

Projects, Code, and Technical Decisions

6. “Tell me about a project you are proud of.”

What they are assessing: Ownership, technical depth, impact, and your ability to explain complex work clearly.

Model answer: “I led the replacement of a nightly inventory sync that regularly produced stale stock levels. I mapped the failure points, proposed an event-driven design, and implemented the first producer and consumer with two other engineers. We introduced idempotency keys and a dead-letter queue because duplicate and malformed events were expected. Stock updates moved from the next morning to under two minutes, overselling incidents fell by 40%, and I documented a migration pattern reused by two teams.”

Prepare: Cover context, constraints, your decisions, implementation, measured result, and what you learned.

7. “Describe a difficult technical problem you solved.”

What they are assessing: Whether you investigate systematically instead of jumping to conclusions.

Model answer: “An API showed intermittent latency spikes that disappeared in local tests. I first segmented traces by endpoint, region, and payload size, which isolated the issue to large accounts after a deployment. Query plans showed one filter had stopped using an index because data distribution had changed. I added a targeted composite index, tested it against production-like data, and added a regression benchmark. p99 latency fell from nine seconds to under one second.”

Prepare: Make the diagnostic sequence visible. The process often matters more than how exotic the bug was.

8. “How do you approach unfamiliar code?”

What they are assessing: How quickly and safely you can become productive in an existing system.

Model answer: “I begin with the user-facing flow and trace one request through entry point, business logic, persistence, and external calls. Then I read the tests and recent changes around that path because they reveal intended behaviour and fragile areas. Before editing, I reproduce the current behaviour and write or identify a focused test. For broader changes, I ask the person closest to the system to validate my mental model rather than relying on assumptions.”

Prepare: Describe a repeatable method that balances independence with asking useful questions.

9. “How do you ensure code quality?”

What they are assessing: Whether quality is built into your process rather than delegated to reviewers or testers.

Model answer: “I start by making the change small enough to reason about. I define expected behaviour and failure cases, add tests at the cheapest reliable level, and keep naming and control flow clear for the next engineer. Before review, I inspect my own diff, remove unrelated changes, and include why the approach was chosen and what risk remains. After release, I verify the production signal rather than assuming deployment means success.”

Prepare: Discuss prevention, verification, reviewability, and production learning—not only unit tests.

10. “How do you review someone else’s code?”

What they are assessing: Technical judgement, collaboration, and whether you can improve work without creating friction.

Model answer: “I review correctness and risk before style. I first understand the intended outcome, then check data boundaries, failure behaviour, security, tests, and maintainability. I distinguish blocking concerns from suggestions and explain the reason behind each request. If a thread becomes long or subjective, I switch to a short conversation. I also call out good decisions so the review is a collaboration, not a list of faults.”

Prepare: Show that you protect standards while respecting the author.

11. “How do you decide between building and buying?”

What they are assessing: Commercial awareness and ability to reason beyond implementation preference.

Model answer: “I compare strategic differentiation, total cost, integration effort, reliability, compliance, lock-in, and the cost of operating the solution over time. For commodity email delivery, buying usually wins because deliverability is specialised and not our product advantage. For our pricing engine, we built the core rules because they changed frequently and differentiated the product, while buying supporting tax data. I would document assumptions and define a review point because the right answer can change with scale.”

Prepare: Explain a decision framework and support it with an example.

12. “Explain a technical concept to a non-technical stakeholder.”

What they are assessing: Whether you can create shared understanding without hiding behind jargon.

Model answer: “I explained rate limiting to our operations lead as a venue controlling entry during a rush: it protects service for everyone by slowing arrivals rather than letting the building become unusable. I connected that to the customer effect, showed which requests would wait or retry, and gave options with cost and risk. That let us agree on a threshold based on business priorities rather than asking them to approve an algorithm.”

Prepare: Choose a concept, use one accurate analogy, then reconnect it to the decision the listener must make.

Coding and Problem-Solving Questions

13. “How would you approach this coding problem?”

What they are assessing: Clarification, decomposition, correctness, communication, and testing.

Model answer: “Before coding, I would confirm input size, expected output, invalid inputs, duplicate handling, and whether memory or runtime is the main constraint. I would walk through a small example, state a simple solution, then improve it if the constraints require that. While implementing, I would keep the logic in testable pieces. Finally, I would test normal, empty, boundary, and adversarial cases and state time and space complexity.”

Prepare: Practise the CLEAR sequence: Clarify, Lay out examples, Explain the approach, Assemble and test, Review.

14. “What do you do when you get stuck during live coding?”

What they are assessing: Composure, coachability, and your ability to recover productively.

Model answer: “I make the blockage explicit rather than going silent. I restate what is known, reduce the problem to a smaller example, and test the assumption most likely to be wrong. If I still cannot progress, I ask for a directional hint and explain what I have considered. Once prompted, I incorporate the hint and continue rather than defending my original approach.”

Prepare: Rehearse saying: “I think my assumption about X may be wrong, so I’m going to test it with the smallest case.”

15. “How do you evaluate an algorithm?”

What they are assessing: Whether you can assess more than theoretical runtime.

Model answer: “I start with correctness against the stated constraints, then analyse time and space complexity. I also consider data distribution, expected scale, readability, mutation, numerical or concurrency risks, and operational context. An asymptotically better solution is not automatically better if the inputs are tiny and the implementation becomes difficult to maintain. I would explain which constraint makes the trade-off worthwhile.”

Prepare: Connect Big O to actual input sizes and system needs.

16. “How would you test this function or service?”

What they are assessing: Risk awareness and whether your test strategy fits the behaviour.

Model answer: “I would identify the contract first: expected outputs, side effects, and failure behaviour. For a function, I would cover representative, boundary, empty, invalid, and property-based cases where useful. For a service, I would add focused integration tests around storage and external contracts, plus a small number of end-to-end tests for critical user journeys. I would also verify observability and one realistic production-like scenario, because tests cannot cover every deployment condition.”

Prepare: Match the test level to the risk; do not answer “100% coverage.”

17. “What is the difference between concurrency and parallelism?”

What they are assessing: Fundamentals and whether you can explain them practically.

Model answer: “Concurrency means multiple tasks can make progress during overlapping periods; parallelism means tasks execute at the same instant, usually on different cores or workers. A single-threaded event loop can handle concurrent network requests by switching while they wait, but it does not execute CPU-heavy JavaScript in parallel. For CPU-bound work, I would use workers or separate processes and then manage coordination and shared-state risks.”

Prepare: Give a definition, a concrete example, and one engineering implication.

18. “When would you use a relational database rather than NoSQL?”

What they are assessing: Data-modelling judgement rather than allegiance to a tool.

Model answer: “I prefer a relational database when the domain has meaningful relationships, transactions, consistency requirements, and queries that benefit from joins and constraints—for example orders, payments, and inventory. I would consider a document or key-value store when access patterns are simple, schema flexibility or horizontal distribution is central, and cross-record transactions are limited. I would start from data and access requirements, not anticipated fashion or scale.”

Prepare: Discuss consistency, query patterns, constraints, operations, and team experience.

System Design Questions

19. “How would you design a URL shortener?”

What they are assessing: Requirements gathering, decomposition, data design, scale, and trade-offs.

Model answer: “I would first clarify expected traffic, custom aliases, expiry, analytics, and availability needs. The core path is a write API that creates a unique code and a highly available read path that redirects codes to long URLs. I would store the mapping in a durable key-value-friendly database, cache popular codes, and use a generated or encoded unique ID while handling custom-code collisions. I would then discuss abuse prevention, replication, cache invalidation, and how analytics stay off the latency-critical redirect path.”

Prepare: Use the SCALE structure: Scope, Constraints, Architecture, Limits and trade-offs, Evolve.

20. “How would you design a notification system?”

What they are assessing: Event flow, reliability, user preferences, and multi-channel complexity.

Model answer: “I would clarify channels, urgency, volume, ordering, delivery guarantees, and user preferences. Producers publish notification events to a durable queue. A service validates preferences, renders channel-specific content, and dispatches through email, push, or SMS providers. I would use idempotency keys, retries with backoff, dead-letter handling, provider failover for critical messages, and status tracking. Rate limits and digesting protect users, while metrics distinguish accepted, delivered, and engaged notifications.”

Prepare: Include failure handling and user control, not just boxes and arrows.

21. “How would you improve a slow API?”

What they are assessing: Measurement, diagnosis, and prioritisation.

Model answer: “I would define which latency percentile and user journey are slow, then trace the request to separate application, database, network, and downstream time. I would compare recent changes and segment by payload, customer, and region. The fix might be a query index, reduced payload, parallel independent calls, caching, or removal of repeated work, but I would choose only after measuring. I would load-test the change and monitor latency, errors, saturation, and cost after release.”

Prepare: Never begin with “add a cache.” Begin with evidence.

Behavioural and Collaboration Questions

22. “Tell me about a disagreement with another engineer.”

What they are assessing: Constructive conflict, listening, and commitment after a decision.

Model answer: “A colleague wanted to rewrite a reporting service before adding a major feature; I believed an incremental change was safer. I asked us to list the failure modes, delivery deadline, and maintenance cost rather than debate preferences. A short spike showed the current design could support the feature but needed one boundary extracted. We agreed on that smaller refactor, delivered on time, and documented triggers for a later rewrite. I learned to turn technical disagreement into testable criteria earlier.”

Prepare: Show respect, evidence, resolution, and learning. Do not make the other person look foolish.

23. “Tell me about a production incident you handled.”

What they are assessing: Composure, prioritisation, communication, and learning after failure.

Model answer: “After a release, checkout errors rose from under 1% to 12%. As incident lead, I assigned one engineer to rollback while I confirmed scope and updated support every 15 minutes. The rollback restored service in nine minutes. We traced the issue to an untested configuration combination, added validation at startup and a deployment check, and changed the release checklist. My main learning was to designate communication ownership immediately so diagnosis is not constantly interrupted.”

Prepare: Cover detection, immediate protection, your role, communication, root cause, and prevention.

24. “Tell me about a mistake or failed project.”

What they are assessing: Accountability and whether experience changes your behaviour.

Model answer: “I estimated a migration from the visible code changes and failed to account for partner testing. We missed the target by two weeks, which delayed a customer rollout. I told the product lead as soon as the dependency became clear, re-planned with the partner, and took responsibility for the estimate. Since then, I map external dependencies and add explicit validation milestones before committing. The next comparable migration finished within the agreed window.”

Prepare: Choose a genuine mistake. Spend less time defending it and more time on changed behaviour.

25. “How do you balance speed and technical debt?”

What they are assessing: Pragmatism, risk judgement, and ability to communicate trade-offs.

Model answer: “I treat technical debt as a deliberate trade-off only when its cost and exit plan are visible. For a time-sensitive experiment, I may accept duplication or a manual process if security, data integrity, and reversibility are protected. I record the limitation, define the signal that requires repayment, and estimate the follow-up. For core payment logic, I set a much higher bar because defects are expensive and shortcuts become structural. Speed is contextual, not permission to ignore consequences.”

Prepare: Explain which quality attributes are negotiable and which are not.

Questions to Ask the Interviewer

Choose questions that help you evaluate the role and reveal engineering expectations:

• “What distinguishes an engineer who performs well here after six months?”
• “How are technical decisions made when the team disagrees?”
• “What is the most important reliability or architecture challenge this team is addressing?”
• “How much ownership does this role have from problem definition through production?”
• “How do code review, testing, deployment, and on-call work in practice?”
• “What changed on the engineering team in the last year, and why?”

For the people-management stage, see our hiring manager interview questions. For values and collaboration rounds, review the culture fit interview questions.

A Seven-Day Preparation Plan

Day 1: Map the role

Highlight the required languages, systems, behaviours, and business outcomes. Match each to evidence from your experience and identify the highest-risk gaps.

Day 2: Build your project evidence

Prepare two project stories with architecture, constraints, your decisions, measurable outcomes, and lessons. Make your personal contribution unmistakable.

Day 3: Practise coding aloud

Complete two realistic problems while clarifying requirements, narrating decisions, testing edge cases, and reviewing complexity. Do not optimise before you have a correct baseline.

Day 4: Refresh system design

Practise one design with the SCALE framework. Include requirements, rough scale, APIs, data model, core components, failure modes, and trade-offs.

Day 5: Prepare behavioural stories

Build STAR examples for conflict, failure, feedback, leadership, ambiguity, prioritisation, and a production incident. Use our STAR method guide to make them specific.

Day 6: Run a realistic practice interview

Answer a mixed set under time pressure and review clarity, structure, evidence, and delivery. Practise with Rehearsa to receive feedback on your answers and communication before the real interview.

Day 7: Review and recover

Do a light review, test your equipment, confirm the format and rules, and prepare questions for each interviewer. Avoid cramming new topics.

Common Mistakes to Avoid

• Memorising polished scripts: It makes follow-up questions harder and sounds less credible.
• Starting code before clarifying: You may solve the wrong problem efficiently.
• Naming technologies without trade-offs: Tools are not evidence of judgement.
• Using “we” without defining “I”: Team context matters, but interviewers need your contribution.
• Ignoring tests and failure cases: A working happy path is not production-ready engineering.
• Hiding uncertainty: State assumptions and show how you would validate them.
• Treating hints as failure: Using a prompt well demonstrates collaboration and coachability.
• Using unapproved assistance: Never use AI, copied solutions, or outside help unless the recruiter explicitly permits it.

Final Checklist

Before the interview, confirm that you can:

• Explain why this role and company fit your next step.
• Present two projects with clear personal ownership and measurable impact.
• Solve a coding problem while making your reasoning visible.
• Discuss time, space, testing, and edge cases.
• Structure a system design from requirements through trade-offs.
• Give concise STAR examples for conflict, failure, and feedback.
• Explain one technical concept to a non-technical person.
• Ask informed questions about the team and role.

The best answers are not the most complicated. They are specific, structured, technically sound, and honest about constraints. If you want a realistic rehearsal before the interview, start a free Rehearsa trial, or compare the available plans to choose the right level of practice and feedback.

More Interview Questions guides · Start free trial