The software engineer onsite interview questions you will face usually fall into four rounds: two or three coding sessions, one system design session for mid-level and senior roles, one behavioral session, and often a conversation with the hiring manager. Below are 30 example questions we wrote, grouped by round, with what a strong answer shows for each, so you can practice the way the loop is actually run.
These are representative of common practice, not a list of questions asked at any particular company. Loops vary by company, team and level, so ask your recruiter for your own agenda. For the full picture of prep timing and logistics, start with our guide on how to prepare for an onsite interview.
What does a typical software engineer onsite loop look like?
Most software engineering loops are a set of back-to-back sessions of about 45 to 60 minutes each, run in one day or split across two. Each interviewer is usually assigned one area, so together they cover the whole job. As of October 2026, Amazon's candidate page says you meet individually with current employees, each assessing different aspects of your skills and experience (Amazon's interview loop page). Our full loop interview guide explains the format and the debrief that follows.
| Round | How many | What it tests | Who often runs it |
|---|---|---|---|
| Coding | 2–3 | Problem solving, data structures, clean code, testing | Engineers on or near the team |
| System design | 0–1 for juniors, 1–2 for mid-level and up | Scoping, scale, components, trade-offs | Senior or staff engineers |
| Behavioral | 1 | Ownership, collaboration, conflict, learning | An engineer or manager trained for it |
| Hiring manager | 0–1 | Motivation, team fit, past projects, working style | The manager you would report to |
Junior and new-grad loops often replace system design with an extra coding round; if that is you, our list of entry-level software engineer interview questions is a better starting point. Senior loops tend to add a project deep dive and weight design more heavily; see our senior software engineer onsite guide for how the bar changes.
What do interviewers expect in every coding answer?
Getting to a working solution matters, but most coding interviewers are also writing down how you got there. The same five steps show up in almost every rubric, whatever the problem.
| Step | What to do | What it shows the interviewer |
|---|---|---|
| Clarify | Restate the problem, ask about input size, duplicates, empty input and the expected output | You don't build the wrong thing |
| Approach | Name a brute-force idea, then a better one, before typing | Structured problem solving |
| Complexity | State time and space cost for your chosen approach | You understand the cost of your code |
| Tests | Walk through a normal case and two edge cases by hand | You verify instead of hoping |
| Trade-offs | Explain what you would change for more data, less memory or a stream | Engineering judgement beyond the puzzle |
If complexity analysis is rusty, the Big-O complexity visualizer is a quick refresher, and our guide to LeetCode patterns for interviews maps common problems to the techniques below.
Software engineer onsite interview questions: coding round (1–12)
These example questions we wrote cover the patterns that come up most in coding rounds: hashing, sorting, two pointers, sliding windows, trees, graphs and heaps. For each one, the note says what separates a strong answer from a passing one.
- Given an array of integers and a target, return the indices of two numbers that add up to the target. A strong answer mentions the O(n²) nested loop, then moves to a hash map for O(n) time, and asks what to return when there is no pair or several pairs.
- Merge all overlapping intervals in a list. Sort by start time, then sweep once. Strong candidates state O(n log n) for the sort and ask whether intervals that only touch, like [1,3] and [3,5], should merge.
- Return the k most frequent words in a log file. Count with a hash map, then use a heap of size k or bucket sort. A strong answer settles the tie-breaking rule before coding and compares O(n log k) with O(n).
- Return the values visible from the right side of a binary tree. Breadth-first search by level, keeping the last node of each level. Strong answers handle the empty tree and explain why depth-first search with a depth counter also works.
- Implement an LRU cache with get and put in O(1) time. A hash map plus a doubly linked list. Interviewers look for clean pointer handling, a sensible capacity-zero case and code you can test line by line.
- Count the islands in a grid of land and water cells. Flood fill with DFS or BFS. A strong answer asks whether it may modify the input, and mentions recursion depth on very large grids.
- Find the length of the longest substring without repeating characters. A sliding window with a map of last-seen positions. Strong candidates explain why the left pointer never moves backward, which is what keeps it O(n).
- Given courses and their prerequisites, decide whether all courses can be finished. Model it as a graph and detect a cycle with topological sort. A strong answer explains the in-degree method in plain words before writing it.
- Return the running median of a stream of numbers. Two heaps, one for each half. Interviewers listen for how you keep the heaps balanced and what each operation costs.
- Find the minimum number of meeting rooms needed for a list of meetings. Sort by start and track end times in a min-heap, or sweep through sorted start and end times. Strong answers test back-to-back meetings that end and start at the same minute.
- Serialize a binary tree to a string and rebuild it. Choose a traversal and a marker for empty children. A strong answer explains why the format is unambiguous and tests it on a skewed tree.
- Follow-up: your input no longer fits in memory. What changes? This is how many interviewers extend a solved problem. Talk about streaming, chunking, external sort or approximate counting, and say which part of your earlier code breaks first.
On a remote loop the coding happens in a shared editor while you talk on a video call. Our live coding tips for Zoom and Teams cover the setup.
System design questions (13–19)
System design usually appears from mid-level up. There is no single right answer: you are scored on how you scope the problem, size it, choose components and defend trade-offs. A reliable order is requirements, rough numbers, API, data model, high-level design, one deep dive, then bottlenecks. Our explainer on what a system design interview is walks through that structure.
- Design a URL shortener. Strong answers separate the write path from the much heavier read path, pick an ID scheme and explain collisions, then add caching for popular links.
- Design a rate limiter for a public API. Compare token bucket with sliding window, decide where the limiter sits, and explain how counts stay consistent across many servers.
- Design a news feed. The key trade-off is building feeds when posts are written versus when they are read. A strong answer handles accounts with very large follower counts differently.
- Design a chat service with one-to-one and group messages. Cover persistent connections, message ordering, delivery receipts and what happens when a user is offline.
- Design a notification system for email, SMS and push. Look for queues, retries with backoff, user preferences, rate limits and how you avoid sending duplicates.
- Design a file storage and sync service. Strong candidates split files into chunks, store metadata separately from content, and explain conflict handling when two devices edit the same file.
- Design a web crawler. Cover the URL frontier, politeness per domain, duplicate detection and how the system recovers when a worker dies mid-crawl.
For a one-page refresher on caching, sharding and queues, use the system design cheat sheet.
Behavioral questions (20–26)
The behavioral round checks how you work with people and handle setbacks. Answers are usually expected in a Situation, Task, Action, Result shape, with your own actions and a measurable result. Expect the interviewer to dig into what you personally did rather than what the team did.
- Tell me about the project you are most proud of. Strong answers name the problem, your specific contribution, one hard decision and a result in numbers, such as latency, revenue, incidents or hours saved.
- Tell me about a time you disagreed with a teammate on a technical decision. Show that you argued with evidence, listened, and committed once a decision was made.
- Tell me about an outage or serious bug you were involved in. Own your part, describe how you limited the damage, and finish with the fix that stopped it happening again.
- Tell me about a time requirements were unclear. Interviewers want to hear how you clarified, made reasonable assumptions, and checked back before building too much.
- Tell me about critical feedback on your code and what you changed. A strong answer shows a specific change in how you work, not a defense of the original code.
- Tell me about a time you helped a teammate get unblocked. Show the help you gave and how they became more independent afterward.
- Tell me about a time you chose between shipping fast and doing it properly. Name the trade-off, who you consulted, and how you paid down any shortcut you took.
For full sample stories, see our behavioral interview STAR examples.
Hiring manager and project questions (27–30)
When the hiring manager has a slot, it is usually less about puzzles and more about whether you would do well on this team. Some loops fold these questions into the behavioral round instead.
- Walk me through the architecture of something you built. Why those choices? Draw or describe the main components, then explain one decision you would make differently today. Keep it to about five minutes before inviting questions.
- What kind of work and team do you want next? Tie your answer to this team's actual work. Vague answers like "a fast-paced environment" tell the manager nothing.
- How do you decide when code is ready to ship? Mention tests, review, monitoring, feature flags and rollback plans, and how the answer changes with risk.
- What questions do you have for me? Ask about the team's current biggest problem, how success is measured in the first six months, and how decisions get made. Two specific questions beat five generic ones.
Our guide to the engineering manager round in a software engineer interview goes deeper on this session, and how onsite interviews are scored explains what happens to your answers afterward.
Practice it
Reading questions helps you recognize them. Answering them out loud, under time, is what changes your performance on the day. A practical routine for the final week:
- Do two coding problems back to back, talking the whole time, then one design prompt the next day.
- Rehearse your behavioral stories out loud with an AI mock interview built from your résumé and the job description, so the questions match the role.
- Get each spoken answer scored out of 10 with what to fix, and redo the weakest one the same day.
You can run this with an AI interview assistant you can rehearse with: it is free for 15 minutes a day, with no account needed. Follow each employer's rules on AI tools, and use AI to prepare beforehand.
Rehearse your onsite before the real one
Answer coding, design and behavioral questions out loud, and get each answer scored out of 10 with what to fix. Free for 15 minutes every day.
Try a free AI mock interviewFAQ
How many rounds are in a software engineer onsite interview?
Commonly four to six sessions of about 45 to 60 minutes: two or three coding rounds, one system design round for mid-level and above, one behavioral round and often a hiring manager conversation. Your recruiter can confirm your exact agenda.
Are onsite coding questions harder than phone screen questions?
Often they are similar in difficulty but come with more follow-ups, such as handling larger inputs or a changed requirement. The bigger difference is volume: you solve several problems in one day, so stamina matters.
Do junior software engineers get system design questions?
Many entry-level loops skip system design or replace it with a lighter object-oriented design question. Mid-level and senior loops usually include at least one full system design round.
What language should I use in the coding rounds?
Use the language you write most fluently, unless the job requires a specific one. Most interviewers care more about clear logic, testing and complexity than the language itself.
How many behavioral stories should I prepare for a SWE onsite?
Six to eight stories usually cover the common themes: a proud project, a conflict, a failure or outage, unclear requirements, feedback and helping others. Each story can often answer more than one question.
What if I cannot solve a coding question completely?
Keep talking through your approach, write the parts you can, test what you have and state the complexity. Many interviewers score reasoning and communication alongside correctness, and one weak round does not always decide the outcome.