Software Engineer Interview Questions and Answers
The 17 questions that come up in Software Engineer interviews, what each one tests and how to answer it, with 6 sample answers.
Most software engineer hiring runs a recruiter call, a technical screen (usually a live coding problem in a shared editor, sometimes an online assessment), then a final loop of three to five interviews: more coding, a system design round for mid-level and senior candidates, and a behavioral round. Interviewers grade how you reason out loud, test your own code and weigh trade-offs, not only whether the solution runs.
What interviewers look for
- Problem solving in code
- In the coding rounds you clarify the problem, start with a working approach, improve it, state the time and space complexity, and test with edge cases, all while talking through your reasoning.
- Code quality
- Interviewers notice clear names, small functions and handled edge cases in the code you write live, and they ask how you review other people's pull requests.
- System design
- For mid-level and senior roles you turn a vague prompt like a URL shortener into requirements, an API, a data model and a scaling plan, and you defend the trade-offs you chose.
- Debugging and operations
- Questions about outages, flaky tests and slow endpoints check whether you reason from evidence (logs, metrics, recent changes) and fix the root cause instead of the symptom.
- Collaboration and ownership
- The behavioral round asks about technical disagreements, mistakes you shipped and projects you drove, looking for someone who communicates early and follows through.
Coding round
Data-structure and algorithm problems solved live, where the process (clarify, plan, code, test) matters as much as the answer.
01
Given an array of integers and a target, return the indices of the two numbers that add up to the target.
Why they ask it: It is a common warm-up. The interviewer wants to see whether you ask clarifying questions and can improve a brute-force answer with the right data structure.
- Ask about the inputs: can there be duplicates, is there always exactly one answer, can the same element be used twice?
- State the brute force first (check every pair, O(n^2) time) so you have a working baseline.
- Improve it with a hash map from value to index: for each number, check whether target minus the number is already in the map, then insert the number. That is O(n) time and O(n) space.
- Test it out loud on a normal case and an edge case such as [3, 3] with target 6, which proves you check before inserting.
Sample answer First I'd confirm a few things: there's exactly one valid pair, I can't use the same index twice, and the array isn't sorted. The simplest approach checks every pair, which is O(n squared), so that's my fallback. Better is one pass with a hash map from value to index. For each element I compute the complement, target minus the current value. If the complement is already in the map, I return its index and the current index. Otherwise I store the current value. Checking before inserting matters: with [3, 3] and target 6, the first 3 goes into the map, the second 3 finds it, and I return 0 and 1 without ever pairing an element with itself. That's O(n) time and O(n) extra space. If memory were tight and the array were sorted, I'd use two pointers instead for O(1) space.
Avoid: Starting to type in silence. A correct solution with no explanation scores worse than a slightly slower one you reasoned through out loud.
02
Find the length of the longest substring without repeating characters.
Why they ask it: It tests the sliding-window pattern and whether you can manage two pointers without off-by-one errors.
- Name the brute force (check every substring) and why it is too slow.
- Describe a window with a left and right pointer and a map from character to its last index.
- When the right pointer hits a repeated character, move left to one past that character's last index, but never backward (take the max).
- Track the best window length as you go; it runs in O(n) time.
Avoid: Moving the left pointer backward when a repeated character's last position is already outside the window, which is the classic bug in this problem.
03
Given a grid of 1s (land) and 0s (water), count the number of islands.
Why they ask it: It checks graph traversal on a grid, marking visited cells, and whether you think about limits such as recursion depth.
- Scan every cell; when you find unvisited land, increment the count and flood-fill that island with DFS or BFS.
- Explain how you mark cells visited (a separate set, or overwriting the grid if mutation is allowed, and ask whether it is).
- Give the complexity: O(rows x columns) time.
- Mention that recursive DFS can overflow the stack on a very large island, so an iterative BFS with a queue is safer.
Avoid: Forgetting to check grid boundaries before reading a neighbor.
04
Implement an LRU cache with get and put in O(1) time.
Why they ask it: It combines two data structures and shows whether you understand why each one is needed.
- Explain the two needs: O(1) lookup by key (a hash map) and O(1) reordering by recency (a doubly linked list).
- On get, move the node to the front; on put, insert at the front and evict from the tail when over capacity.
- Mention built-ins (Python's OrderedDict with move_to_end, Java's LinkedHashMap in access order), then ask whether the interviewer wants you to build the list yourself.
- Walk through an eviction by hand to show the pointers stay consistent.
Avoid: Using a plain list for recency, which makes every update O(n).
05
How would you test the code you just wrote?
Why they ask it: Interviewers want engineers who verify their own work rather than waiting for someone else to find the bug.
- Trace one normal input through the code by hand, line by line.
- List edge cases specific to the problem: empty input, a single element, duplicates, negative numbers, very large values.
- Say which unit tests you would write and what each one proves.
- If you find a bug while tracing, say so and fix it; that counts in your favor.
Avoid: Declaring the code correct without running a single example.
System design
Open-ended design prompts, usually 45 to 60 minutes, that test how you scope a problem and reason about scale, data and failure.
06
Design a URL shortener.
Why they ask it: It is small enough to finish but touches requirements, key generation, storage, caching and analytics, so it shows how you structure a design.
- Start with requirements and rough scale: how many new links and redirects per day, whether links expire, whether clicks are counted.
- Define the API (create a short link, redirect) and the data model (short code, long URL, owner, created and expiry dates).
- Choose key generation: a counter encoded in base62, or a hash with collision checks, and say what each costs.
- Note that redirects are read-heavy, so put a cache in front of the store, and explain 301 versus 302 redirects.
- Close with failure and abuse: what happens if the cache is down, and how you block malicious links.
Sample answer I'd start by pinning down scale. Say 100 million new links a month and far more redirects than writes, so this is a read-heavy system. The API is two calls: POST a long URL and get a short code back, and GET the short code to redirect. For codes I'd use a unique ID from a counter service encoded in base62; seven characters gives about 3.5 trillion combinations, so we won't run out, and there are no collisions to check. The mapping lives in a key-value store keyed by code, with a cache in front because a small share of links gets most of the traffic. For redirects I'd return 302 rather than 301 if the product needs click counts, since browsers can cache a 301 and skip our servers. Click events go onto a queue so analytics never slows a redirect. Finally, I'd check new URLs against a malware list before issuing a code.
Avoid: Drawing boxes before asking a single question about scale or requirements.
07
How would you design a rate limiter for a public API?
Why they ask it: It tests whether you know the standard algorithms and can reason about shared state across many servers.
- Ask what is being limited (per user, per API key, per IP) and how strict it must be.
- Compare algorithms: fixed window (simple, bursty at edges), sliding window, and token bucket (allows short bursts, smooth average).
- Explain where it runs (API gateway or middleware) and that counters need a shared store such as Redis with atomic increments so every server sees the same count.
- Return HTTP 429 Too Many Requests with a Retry-After header, and decide whether to fail open or closed if the store is unreachable.
Avoid: Keeping counters in each server's memory behind a load balancer, which lets clients multiply their limit.
08
Design the home feed for a social app.
Why they ask it: It surfaces the core trade-off between doing work when content is written and doing it when the feed is read.
- Clarify: chronological or ranked, how many follows per user, how fresh the feed must be.
- Explain fan-out on write (push new posts into followers' feeds; fast reads, expensive for accounts with huge followings) versus fan-out on read (assemble at request time).
- Propose a hybrid: push for most accounts, pull for very large ones at read time.
- Cover pagination with cursors rather than page numbers, and caching of the first page.
Avoid: Picking one approach without naming the case where it breaks down.
Debugging, code review and production
Questions about the job after the code is written: finding bugs, reviewing teammates' work and handling incidents.
09
Tell me about a production incident you were part of. What happened, and what changed afterward?
Why they ask it: Incidents show how you act under pressure, whether you communicate while fixing, and whether you prevent the next one.
- Set the scene briefly: the service, the symptom, and how it was detected.
- Say what you did first to stop the damage (roll back, disable a flag) before hunting for the root cause.
- Explain the root cause plainly and how you confirmed it.
- End with the follow-up you owned: a test, an alert, a runbook change, and what it caught later if you know.
Sample answer On my last team, a release made our order-history page time out for some customers. Our latency alert fired about ten minutes after the deploy, with p99 going from roughly 300 milliseconds to over 4 seconds. I was on call, so I posted in the incident channel, confirmed the timing matched our deploy, and rolled it back; latency recovered within 15 minutes. Then I dug in. A refactor had moved a database call inside a loop, so customers with long histories triggered hundreds of queries per request. Our tests used tiny fixtures, so nobody saw it. I fixed the query to batch the lookups and added a test that fails if that endpoint issues more than a set number of queries. In the blameless postmortem, the action I pushed for was test data that looks like production, because small fixtures had hidden the problem, and we added a few large customer histories to the suite.
Avoid: Blaming a teammate or the QA team. Interviewers listen for whether you own the fix and the follow-up.
10
A test passes on your machine but fails intermittently in CI. How do you track it down?
Why they ask it: Flaky tests are a daily reality, and the answer shows whether you debug methodically or just re-run the build.
- List the usual causes: test order and shared state, time and time zones, randomness without a fixed seed, race conditions, real network calls.
- Reproduce first: run the test in a loop, in a different order, or with CI's settings.
- If it blocks the team, quarantine it with an owner and a ticket rather than deleting it.
- Fix the cause (isolate state, inject a clock, mock the network) and say how you would stop the pattern recurring.
Avoid: Adding a retry and calling it fixed.
11
Walk me through how you review a pull request.
Why they ask it: Code review is where most engineering judgment and team culture show up, and interviewers want both rigor and tact.
- Start with what the change is meant to do, then check correctness and tests before style.
- Look for the risky parts: input validation, error handling, concurrency, data migrations, secrets in code.
- Separate blocking issues from nits and say which is which.
- Phrase feedback as questions or suggestions, and approve when it is good enough rather than perfect.
Sample answer I read the description and linked ticket first so I know what the change is supposed to do. Then I check whether the tests actually exercise the new behavior, including a failure path, because a passing suite that doesn't test the change tells me nothing. Next I look at the risky areas: anything touching user input, database migrations, retries, or code that runs concurrently. Style comes last, and mostly the linter should catch it. I label comments as blocking or as a nit, and I phrase them as questions, like asking what happens if this list is empty, instead of commands. If a pull request is over a few hundred lines I'll ask whether it can be split, since big reviews get rubber-stamped. I try to review within a working day, because a slow review blocks a teammate more than a few rough edges in the code ever would.
Avoid: Describing review as hunting for style problems, or as approving anything from a senior engineer.
12
What happens when you type a URL into a browser and press Enter?
Why they ask it: It checks your grasp of networking and the web stack, and lets the interviewer probe wherever you go deepest.
- Go in order: DNS lookup (browser and OS caches, then a resolver), connection setup (TCP and TLS handshakes, or QUIC for HTTP/3), then the HTTP request.
- Describe the server side: load balancer, application server, maybe a cache or database, then the response.
- Finish in the browser: parse HTML, fetch CSS, JavaScript and images, build the page and render it.
- Offer to go deeper on whichever layer the interviewer cares about.
Avoid: Listing buzzwords without the order in which things actually happen.
Behavioral and motivation
Questions about how you work with people and decide what to build, usually answered as specific stories.
13
Tell me about a time you disagreed with a teammate on a technical decision.
Why they ask it: Engineers disagree constantly; interviewers want to know whether you settle it with evidence and still work well together afterward.
- Pick a real decision with stakes, not a tabs-versus-spaces argument.
- Show how you made the disagreement concrete: a written comparison, a prototype, a benchmark.
- Say how it was decided, including if you lost, and how you supported the outcome.
- Mention what you would do the same way next time.
Sample answer We needed to send confirmation emails after signup, and a senior teammate wanted to call the email provider directly in the request. I thought we should put the job on a queue, because the provider occasionally took several seconds and signups would hang. Instead of arguing in the thread, I wrote a one-page comparison and pulled two weeks of the provider's response times from our logs, which showed a slow tail on a small share of calls. My teammate pointed out that a queue added a new system to operate, which was fair. We agreed on a middle path: use the background job runner we already had rather than a new queue. Signup latency stayed flat afterward, and I learned to bring data to these discussions early instead of opinions.
Avoid: Telling a story where you were simply right and the other person was simply wrong.
14
Walk me through a project on your résumé in depth. What would you do differently?
Why they ask it: Interviewers dig into one project to check that you did the work you claim and understand the decisions behind it.
- Choose a project where you made real decisions, and know it well enough to answer follow-ups three levels deep.
- Explain the problem, your part (not just the team's), the main design choices and why.
- Give a measurable result: users, latency, time saved, bugs reduced.
- Name something you would change now; it shows you have grown since.
Sample answer During my internship I built a tool that let the support team look up a customer's recent errors without asking engineering. Before it, support filed about 20 tickets a week just to ask for logs. I wrote a small service that queried our log store by customer ID, stripped personal data, and showed the last 50 errors on an internal page. The main decision was whether to query logs live or copy them into a database; I chose live queries with a short cache because copying meant another pipeline to maintain. By the end of the summer those log-request tickets dropped to two or three a week. What I'd do differently is add usage tracking from day one. I had to estimate adoption from ticket counts, when I could have measured it directly.
Avoid: Saying "we" for everything so the interviewer cannot tell what you personally built.
15
Tell me about a bug you shipped or a deadline you missed.
Why they ask it: Everyone ships bugs. The question tests honesty and whether you change your process afterward.
- Pick a real mistake with real impact, and own your part plainly.
- Say how it was found and how quickly you communicated it.
- Explain the fix and the process change that prevents a repeat.
Avoid: Choosing a fake mistake, such as working too hard, or a story where the cause was entirely someone else.
16
Tell me about a time you had to learn an unfamiliar codebase or technology quickly.
Why they ask it: Most engineering jobs start with a large codebase you did not write, so ramp-up speed matters.
- Describe your method: run it locally, trace one request end to end, read tests, ask targeted questions.
- Show what you shipped and how soon.
- Mention anything you left behind for the next person, such as updated setup docs.
Avoid: Saying you read all the documentation first and only then started.
17
Why this team, and what kind of engineering work do you want to do next?
Why they ask it: Interviewers want evidence you understand what this team builds and that the work fits what you want to grow into.
- Reference the product or the team's technical problems specifically, from the job post, engineering blog or the product itself.
- Connect it to work you have done and the skills you want to deepen.
- Keep it honest; it is fine to say what you are still learning.
Avoid: A generic answer about the company being innovative that would fit any employer.
Questions to ask them
The end of the interview is yours. Each of these tells you something about the job that a posting won't.
What does on-call look like for this team, and how often do people get paged after hours?
It tells you the real operational load and how stable the systems are.
How does code get from a merged pull request to production?
The answer reveals deploy frequency, test coverage and how much manual work releases take.
What would a strong new engineer have shipped by the end of their first 90 days?
It shows how onboarding works and what is expected of you early.
How are technical decisions made and written down here?
You learn whether there are design docs and reviews, or whether decisions happen in hallways.
How is engineering performance evaluated, and what separates one level from the next?
It tells you how growth and promotion actually work on this team.
How to prepare
- Ask the recruiter for the format of every round: language choice, shared editor or your own IDE, whether code must run, and whether any AI tools are allowed.
- Practice problems from each core pattern (hash maps, two pointers, sliding window, trees, graph BFS and DFS, heaps, basic dynamic programming) on a coding platform, out loud and against a timer.
- Rehearse at least two system design prompts end to end in 45 minutes: requirements, API, data model, diagram, scaling and failure modes.
- Prepare four or five specific stories with numbers: an incident, a disagreement, a project you drove, a mistake, and learning something fast.
- Re-read your résumé and any linked code; be ready to go three levels deep on every project you list.
- Read the company's engineering blog or public docs and use the product, so you can talk about their real technical problems.
- For video interviews, test your microphone, connection and the shared-editor link the day before.
Quick answers
What's asked in a software engineer coding interview?
Usually one or two data-structure and algorithm problems in a 45 to 60 minute session: arrays and strings, hash maps, trees, graphs, and sometimes dynamic programming. Interviewers grade your communication, correctness, complexity analysis and testing, not only whether the code runs.
Do entry-level software engineers get system design questions?
Often not a full system design round. New-grad loops usually focus on coding and behavioral questions, sometimes with a lighter object-oriented or API design problem, while mid-level and senior loops almost always include system design.
Which programming language should I use in a coding interview?
The one you write most fluently, unless the job requires a specific language. Python is a common choice because it is concise, but a language you know well beats one you picked to look good.
Can I use AI tools during a coding interview?
Only if the company says so. Policies differ: some companies now run rounds designed around an AI assistant, while others treat any outside help as disqualifying, so ask your recruiter before the interview.
Sources
- Software Developers (15-1252.00), O*NET OnLine
- Software Developers, Quality Assurance Analysts, and Testers, U.S. Bureau of Labor Statistics, Occupational Outlook Handbook