Interview guide · Technology roles
Software engineer interview questions
In short
Strong software engineer interview questions test how a developer reasons about code, designs systems, debugs production problems, reviews others' work and collaborates under real deadlines. Below are 34 questions for junior, mid-level and senior software developers, grouped by skill, with what each reveals, what a good answer includes, red flags, sample answers and a scorecard.
Most software engineering work is not writing new algorithms. It is reading existing code, changing it safely, figuring out why something broke at 2 a.m., agreeing on trade-offs with other engineers and product managers, and shipping in small pieces that do not take the system down. Interviews built entirely around puzzle-style coding questions select for people who practiced puzzles, which is only loosely related to that work. The best loops mix a practical coding exercise with conversation about design, debugging, testing and teamwork, and they score every candidate against the same rubric.
Use the groups below to build each stage of your loop: an opener and background screen, coding and fundamentals, system design, debugging and code quality, collaboration and behavioral, and questions for senior engineers. Pick five to eight questions per interviewer, assign each interviewer a competency so the loop does not ask the same thing four times, and adjust depth by level. A new graduate should explain a hash map clearly; a senior engineer should explain when not to add a cache. Wherever possible, let candidates work in the language they know best and talk through their thinking. How they reason out loud is the signal you are paying for.
What to look for in a software engineer
- Problem decompositionGood engineers break vague problems into small, testable steps and clarify requirements before coding. Candidates who start typing immediately often build the wrong thing quickly.
- Code quality and testing habitsReadable names, small functions, sensible error handling and tests are what make code cheap to change later. Look for candidates who mention tests without being asked.
- Debugging methodProduction issues are solved by forming hypotheses, gathering evidence from logs and metrics, and narrowing down, not by guessing. A clear debugging story is one of the best predictors of on-the-job value.
- Design judgment and trade-offsAt mid and senior levels, choosing between options (a queue or a direct call, SQL or a document store, build or buy) matters more than syntax. Strong candidates name trade-offs and say what they would measure.
- Collaboration and communicationEngineers work through code review, design docs, tickets and incident channels. Clear writing and the ability to disagree without drama keep teams shipping.
- OwnershipEngineers who follow their work into production, watch the dashboards and fix what they broke create far fewer incidents than those who consider a merged pull request the end of the job.
Opening and background questions
Walk me through a project you are proud of. What was your part, and what would you do differently?
- Why ask it
- Separates personal contribution from team achievement and shows reflection.
- A strong answer
- Describes the problem, their specific role, technical decisions they made and why, the outcome in measurable terms and a genuine improvement they would make now.
- Red flags
- Says 'we' throughout and cannot name a decision they personally made.
Describe the architecture of the system you work on today, as if I were joining your team.
- Why ask it
- Shows whether the candidate understands the bigger picture beyond their own tickets.
- A strong answer
- Explains main components, data stores, how requests flow, where the pain points are and how deploys happen, at a level a new team member could follow.
- Red flags
- Only knows their own service and cannot explain how it connects to anything.
Which languages and tools are you strongest in, and how did you learn your most recent one?
- Why ask it
- Checks stack fit and learning approach.
- A strong answer
- Is honest about depth versus familiarity and describes learning through a real project, documentation and reading other people's code.
- Red flags
- Claims expert level in a long list of languages.
What does your team's path from a merged pull request to production look like?
- Why ask it
- Reveals exposure to CI/CD, testing practice and release discipline.
- A strong answer
- Describes automated tests, build pipeline, staging or canary steps, feature flags and how rollbacks work.
- Red flags
- Has no idea how their code reaches production.
Why are you looking to leave your current role?
- Why ask it
- Motivation and fit; also surfaces issues the new team might repeat.
- A strong answer
- Gives a specific, professional reason such as scope, technology, growth or product interest.
- Red flags
- Blames every former colleague or manager.
Coding and fundamentals
Write a function that returns the first non-repeating character in a string. Then tell me its time and space complexity.
- Why ask it
- A short, practical exercise that tests clarity, use of a hash map and complexity reasoning.
- A strong answer
- Asks about character set and empty input, counts with a map in one pass and finds the first count of one in a second pass, explains O(n) time and O(k) space, and tests edge cases.
- Red flags
- Nested loops without recognizing the O(n squared) cost, or no edge-case handling.
When would you choose a list, a set, a map or a queue?
- Why ask it
- Data structure choice drives performance and readability in everyday code.
- A strong answer
- Gives practical examples: a set for membership checks, a map for lookup by key, a queue for work processed in order, a list when order and index matter.
- Red flags
- Uses lists for everything or cannot explain lookup costs.
Explain what happens, at a high level, when someone types a URL into a browser and presses enter.
- Why ask it
- Classic breadth question covering DNS, TCP, TLS, HTTP and rendering.
- A strong answer
- Covers DNS resolution, connection and TLS handshake, the HTTP request and response, server processing and browser rendering, going deeper where the candidate's experience lies.
- Red flags
- Cannot describe more than 'the page loads'.
How would you refactor a 400-line function that everyone is afraid to touch?
- Why ask it
- Real codebases are full of these. Tests safe change practice.
- A strong answer
- Adds characterization tests first, extracts small pieces with clear names, commits in small steps and reviews behavior at each step.
- Red flags
- Would rewrite it from scratch in one pull request.
What is the difference between a process and a thread, and when have concurrency bugs bitten you?
- Why ask it
- Concurrency issues cause hard-to-find production bugs.
- A strong answer
- Explains shared memory versus isolation, describes a race condition or deadlock they hit and how they fixed it with locks, immutability or a queue.
- Red flags
- Treats concurrency as something that never affects them.
How do you decide what to test and at which level: unit, integration or end-to-end?
- Why ask it
- Testing strategy affects speed and confidence.
- A strong answer
- Mostly fast unit tests for logic, integration tests for boundaries such as databases and APIs, a small number of end-to-end tests for critical flows, and a view on flaky tests.
- Red flags
- Does not write tests or tests only through the UI.
Given a table of orders with customer_id, amount and created_at, write a query that returns each customer's total spend in the last 30 days.
- Why ask it
- Most application engineers touch SQL. Tests aggregation and filtering.
- A strong answer
- Uses a WHERE filter on date, GROUP BY customer_id and SUM(amount), and mentions an index on created_at or customer_id for large tables.
- Red flags
- Cannot write a basic aggregate query.
System design questions
Design a URL shortener that handles 100 million new links a month.
- Why ask it
- A well-known but useful design question covering storage, ID generation, caching and scale.
- A strong answer
- Clarifies read and write ratios, estimates storage, proposes ID generation that avoids collisions, a key-value store, caching for hot links, redirects with proper status codes, and discusses analytics and abuse.
- Red flags
- Jumps to a specific database without asking about requirements or scale.
How would you design a notification service that sends email, SMS and push messages?
- Why ask it
- Tests queues, retries, idempotency and third-party integration.
- A strong answer
- Uses a queue to decouple producers, per-channel workers, retries with backoff, idempotency keys to avoid duplicates, user preferences and rate limits, and monitoring of delivery rates.
- Red flags
- Calls each provider synchronously from the web request.
When would you add a cache, and what can go wrong?
- Why ask it
- Caching is a common answer to performance problems and a common source of bugs.
- A strong answer
- Adds caching for expensive, frequently read, rarely changing data, and discusses invalidation, stale reads, thundering herd and memory limits.
- Red flags
- Treats a cache as free speed with no downsides.
How do you choose between a relational database and a document or key-value store?
- Why ask it
- Tests data modeling judgment.
- A strong answer
- Considers relationships, transactions, query patterns, consistency needs and team familiarity; defaults to relational unless there is a clear reason.
- Red flags
- Picks a technology because it is fashionable.
An API endpoint is slow under load. How do you make it faster?
- Why ask it
- A realistic design-and-debugging hybrid.
- A strong answer
- Measures first with profiling and tracing, then checks query plans and indexes, N+1 queries, payload size, caching and pagination, and confirms the improvement with metrics.
- Red flags
- Proposes rewriting in another language before measuring anything.
Debugging, production and code quality
Tell me about the hardest bug you have tracked down. How did you find it?
- Why ask it
- Debugging stories reveal method, persistence and depth.
- A strong answer
- Describes symptoms, hypotheses, the evidence gathered from logs, metrics or a debugger, how they narrowed it down, the fix and what they did to prevent a repeat.
- Red flags
- Found it by luck or by asking someone else, with no method.
Error rates on your service jump right after a deploy. What do you do in the first ten minutes?
- Why ask it
- Tests incident instincts.
- A strong answer
- Roll back or disable the feature flag first, communicate in the incident channel, then investigate the diff and logs once users are protected.
- Red flags
- Tries to debug live while errors continue.
What do you look for when you review someone else's pull request?
- Why ask it
- Code review is daily work and shapes team quality.
- A strong answer
- Correctness, readability, tests, edge cases, security issues and fit with the existing design, with comments that are specific and kind; approves small changes quickly.
- Red flags
- Only checks style or approves without reading.
How do you handle a review comment you disagree with?
- Why ask it
- Reveals ego and collaboration.
- A strong answer
- Explains their reasoning, asks a question, accepts good points and moves bigger debates to a quick call or a team convention rather than a long thread.
- Red flags
- Ignores the comment or argues indefinitely.
What security issues do you watch for in web application code?
- Why ask it
- Every engineer contributes to security.
- A strong answer
- Mentions input validation, SQL injection, cross-site scripting, authentication and authorization checks, secrets in code and dependency vulnerabilities.
- Red flags
- Thinks security belongs to another team.
How do you approach logging and monitoring for a new feature?
- Why ask it
- Observability decides how quickly problems get found.
- A strong answer
- Adds structured logs with context, metrics for success and failure, alerts on user-facing symptoms and a dashboard before launch.
- Red flags
- Adds logging only after something breaks.
Collaboration and behavioral questions
Tell me about a time you disagreed with a technical decision. What happened?
- Why ask it
- Engineers must challenge ideas and still commit to a team decision.
- A strong answer
- Raised the concern with evidence, listened to the other side, accepted the outcome or changed minds, and kept the relationship intact.
- Red flags
- Went around the team or still holds a grudge.
Describe a time you shipped something that broke. What did you do?
- Why ask it
- Ownership and honesty under pressure.
- A strong answer
- Owned it publicly, fixed it fast, joined or wrote the post-incident review and added a test or check to prevent it.
- Red flags
- Blames QA or has never broken anything.
How do you handle a product manager asking for a feature by Friday that you think needs three weeks?
- Why ask it
- Scope negotiation is a core engineering skill.
- A strong answer
- Breaks the feature down, explains the estimate, offers a smaller version that can ship Friday and agrees the trade-off openly.
- Red flags
- Agrees and then misses the date, or refuses without offering options.
Tell me about a time you helped a teammate get unstuck.
- Why ask it
- Shows generosity and team orientation.
- A strong answer
- Specific example of pairing, explaining or reviewing, with the outcome for the teammate.
- Red flags
- Has never helped anyone or sees it as a distraction.
How do you use AI coding assistants in your work, and where do you not trust them?
- Why ask it
- Most teams use them now. Judgment about verifying generated code matters.
- A strong answer
- Uses them for boilerplate, tests and exploration, reviews every line, never pastes secrets or proprietary data where policy forbids it, and checks licensing and security of suggestions.
- Red flags
- Accepts generated code without review or cannot explain code they submitted.
Tell me about something technical you learned in the last six months.
- Why ask it
- Continuous learning keeps engineers effective.
- A strong answer
- Names a specific topic, how they learned it and how they applied it.
- Red flags
- Nothing specific.
Questions for senior and lead engineers
Tell me about a technical decision you made that you later regretted.
- Why ask it
- Senior engineers make big calls. Reflection on mistakes shows maturity.
- A strong answer
- Describes the decision, the information they had, what went wrong, how they corrected course and what they now do differently.
- Red flags
- No regrets, or the mistake was always someone else's.
How do you decide when to pay down technical debt versus build new features?
- Why ask it
- Balancing debt and delivery is a senior responsibility.
- A strong answer
- Ties debt work to measurable pain such as incident rates, slow delivery or onboarding time, makes the case in business terms and builds it into the roadmap.
- Red flags
- Wants to stop feature work for a rewrite.
How have you raised the skill level of engineers around you?
- Why ask it
- Senior impact comes through others.
- A strong answer
- Mentoring, design reviews, writing documentation, improving tooling or running knowledge sessions, with examples of people who grew.
- Red flags
- Only talks about their own output.
Walk me through a design document you wrote. Who read it, and what changed because of feedback?
- Why ask it
- Written design communication is central at senior levels.
- A strong answer
- Describes the problem statement, options considered, the decision, rollout and risks, and specific changes made after review.
- Red flags
- Has never written one or treats review as a formality.
How would you approach your first 60 days on our team?
- Why ask it
- Shows how a senior engineer builds context before changing things.
- A strong answer
- Reads code and docs, ships small changes early, joins on-call, meets stakeholders and only then proposes larger changes.
- Red flags
- Plans to change the architecture in the first month.
Sample answers
We had checkout requests failing about once in every few thousand, with a generic timeout. Nothing obvious in the logs. I added a request ID to every log line across the three services involved, and after a day of data I could see all the failures had one thing in common: they hit the same database replica during a nightly backup window. The replica's lag spiked, a read after write returned stale data, and our retry logic waited on a lock that would never clear. The fix was to route that specific read to the primary and add a timeout to the retry. I also wrote a test that reproduced the stale read and added an alert on replica lag. Failures dropped to zero, and we kept the request IDs because they made every later investigation faster.
First I'd ask what's driving Friday, because sometimes there's a demo or a customer commitment and sometimes it's just a guess. Then I'd break the feature into pieces in front of them and show where the time goes. Usually there's a version that delivers most of the value, maybe the happy path for one customer type without admin settings, that can ship by Friday behind a flag. I'd be clear about what's missing and what risk we're taking. If Friday is truly fixed and the smaller version doesn't work, I'd say so plainly and suggest what we could stop doing to make room. What I won't do is agree to Friday and quietly cut testing.
Interview scorecard
| Competency | Weight | Strong (4–5) | Weak (1–2) |
|---|---|---|---|
| Coding ability and fundamentals | 25% | Clarifies requirements, writes clean working code, handles edge cases and explains complexity. | Struggles to produce working code or ignores edge cases and complexity. |
| System design and trade-offs | 20% | Asks about scale and requirements, proposes a sensible design and names trade-offs and what to measure. | Jumps to tools without requirements or cannot discuss trade-offs. |
| Debugging and production ownership | 20% | Describes a hypothesis-driven debugging method and protects users first in incidents. | Guesses, or has no experience following code into production. |
| Code quality and testing | 15% | Tests at the right levels, refactors safely and gives specific, useful code reviews. | Rarely tests and treats review as a formality. |
| Collaboration and communication | 15% | Explains clearly, disagrees constructively and negotiates scope with options. | Unclear explanations, defensive or avoids hard conversations. |
| Learning and growth | 5% | Gives recent, specific examples of learning and applying new skills. | Nothing learned recently. |
Score each competency from 1 to 5 straight after the interview, before discussing the candidate with anyone else, then multiply by the weight.
How to structure a software engineer interview loop
A typical loop for mid-level engineers has four parts: a 30-minute recruiter or hiring manager screen, a 45 to 60 minute technical screen with a practical coding exercise, and an onsite or virtual final of three to four interviews covering coding, system design (from mid-level up), debugging or code review, and collaboration. Keep the total candidate time under five hours. Strong engineers often have several offers, and long loops lose them.
Take-home exercises work when they are small (two to three hours at most), relevant to the real job and followed by a conversation where the candidate walks through their code. Pair programming on a realistic task, such as adding a feature to a small existing codebase, tells you more about day-to-day work than an algorithm puzzle. Many teams use a structured skills assessment as the first technical step for high-volume or early-career roles, then reserve live interviews for the finalists.
Assign each interviewer one or two competencies from the scorecard, have them submit scores before the debrief, and make the hire decision against the rubric. Recruiters running these loops will find our technical recruiter interview questions useful for building their own team. For role requirements, the software engineer job description is a good starting point.
Mistakes interviewers make with developer interviews
Testing memory instead of skill is the most common one. Asking candidates to recall an obscure algorithm on a whiteboard without a compiler measures interview preparation. Practical exercises in a real editor, with access to documentation, look much more like the job.
The second mistake is unstructured debriefs, where the most senior or most confident voice decides. Written scores before discussion, tied to specific evidence, reduce this and make decisions consistent across interviewers.
Third, asking every candidate the same questions regardless of level. A new graduate should not get a distributed systems design question, and a staff engineer should not spend an hour reversing a linked list. Adjust depth while keeping the competencies the same.
Fourth, neglecting adjacent roles. If the job includes infrastructure or testing work, borrow from our DevOps engineer interview questions or QA tester interview questions rather than assuming a generalist loop covers it.
Finally, set a clear policy on AI assistants for take-homes and live exercises, and tell candidates in advance. Either is defensible; leaving it ambiguous is not. Make sure any automated coding assessments are validated for the role and offer accommodations under the ADA when candidates request them.
Hiring software engineers at volume
Campus programs, new engineering centers and large services teams may hire dozens of engineers in a quarter. At that scale, consistency matters more than any single question. Build a question bank per level with scoring guides, train interviewers with recorded examples, and calibrate monthly by comparing scores across interviewers.
Automate the steps that do not need an engineer: scheduling, knockout questions on work authorization and location, and a first technical assessment scored automatically. Spend engineer time on the interviews that need judgment, such as system design and collaboration. Track pass rates by stage, interviewer and source, and look at whether interview scores predict performance ratings after six to twelve months. If a stage passes nearly everyone or almost no one, it is not helping you decide.
Frequently asked questions
What are the most common software engineer interview questions?
Expect a practical coding problem with a discussion of time and space complexity, questions about data structures, a system design exercise for mid-level and senior roles, a debugging story, how you review code and test, and behavioral questions about disagreements, mistakes and deadlines.
What is the difference between software developer and software engineer interview questions?
In practice the titles are used interchangeably and the interview questions are the same. Some companies use engineer for roles with more design and systems responsibility, so expect more system design questions for those.
How many interview rounds does a software engineer usually have?
Commonly three or four: a recruiter or manager screen, a technical screen, and a final loop of three to four interviews covering coding, design, code quality and collaboration. Keep total candidate time under about five hours.
Should developer interviews use take-home tests or live coding?
Both can work. Take-homes should be short and job-relevant and be followed by a walkthrough. Live coding should use a real editor and allow documentation. Many teams offer candidates a choice, which also helps candidates who interview poorly under observation.
What system design questions are asked in software engineering interviews?
Common ones include designing a URL shortener, a notification service, a rate limiter, a chat system or a news feed. Interviewers care less about the final design than whether you clarify requirements, estimate scale and explain trade-offs.
How should interviewers score software engineer candidates?
Use a written rubric per competency, such as coding, design, debugging, code quality and collaboration, with a 1 to 5 scale and examples of strong and weak evidence. Interviewers should submit scores before the debrief so the group does not anchor on one opinion.