The short version. A software engineer interview isn't one test — it's three or four different ones bundled into a loop. Coding rounds score how you turn a vague problem into clean, correct code while thinking out loud. The system-design round (mid-level and up) scores your judgment on trade-offs at scale. The behavioral round scores collaboration, ownership, and how you handle disagreement and failure. Below are 14 real questions across all three, each with why the interviewer asks it and a strong sample answer — plus a preparation plan, the red flags that sink strong coders, and the questions you should ask back.
What a software engineer interview really tests
The software engineer interview is not a test of how many algorithms you've memorized. What an experienced interviewer is actually evaluating is narrower and more revealing: can you take an underspecified problem, ask the right clarifying questions, reason about trade-offs out loud, write code another human could maintain, and stay collaborative while someone watches you think. The algorithm is just the vehicle. Two candidates can both reach a correct solution and score wildly differently, because one narrated a clear plan, named the complexity, and tested their own edge cases, while the other coded in silence and shrugged when asked why they chose a hash map.
So treat the interview as a set of competencies, not a pile of puzzles. Coding rounds probe problem decomposition and code quality. System design probes judgment at scale — no single right answer, only defensible trade-offs. Behavioral rounds probe whether you're someone a team actually wants on call with them during an incident. Knowing which competency a question really measures tells you what to emphasize when you answer.
How the rounds are structured
A modern software engineer loop is fairly standardized across large product companies and Series-B startups alike. The names vary, but the shape rarely does. Understanding the sequence lets you allocate prep time where it counts and walk in knowing exactly what each interviewer is scoring.
| Round | Format | What it scores |
|---|---|---|
| Recruiter screen | 20–30 min call | Motivation, level fit, comp range, logistics |
| Technical phone screen | 45–60 min, shared editor | One or two coding problems; can you code and communicate |
| Coding onsite (×2–3) | 45–60 min each | Data-structure fluency, correctness, complexity, clean code |
| System design | 45–60 min, whiteboard/doc | Architecture judgment, trade-offs, scale (mid-level & up) |
| Behavioral / values | 45 min | Collaboration, ownership, conflict, growth |
| Hiring-manager / bar-raiser | 30–45 min | Overall signal, team fit, leveling decision |
For new grads and junior roles, system design is usually dropped or replaced with a lighter "design a class / model these objects" exercise. For staff and above, the balance flips: design and behavioral leadership rounds carry more weight than raw coding speed. Match your preparation to the level you're targeting — over-indexing on hard algorithm puzzles when you're interviewing for a senior role with a design-heavy loop is a common and costly misallocation.
Coding & data-structures questions
Coding rounds are where most candidates feel the pressure, but the interviewer's rubric is more forgiving than it feels — and more demanding in ways you might not expect. They want to see you clarify before coding, state a brute-force baseline, optimize deliberately, narrate complexity, and test your own code. A working solution delivered in silence scores below a slightly-incomplete one delivered with clear reasoning. Here are the most representative questions, with what's really being measured and how a strong candidate answers.
1. 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's the cleanest possible test of whether you reach for the right data structure. The naïve double loop is O(n²); a hash map gets you to O(n). It also opens the door to follow-ups — duplicates, no solution, multiple pairs — so a single problem reveals depth.
Strong sample answer"Let me confirm a couple of things first: can the array have duplicates, and is exactly one solution guaranteed? Assuming one solution and we return indices — the brute force is checking every pair, O(n²). I'd rather trade space for time. I'll make one pass, and for each number I'll check whether target minus that number is already in a hash map of value-to-index. If it is, I've found my pair; if not, I store the current value and index and keep going. That's O(n) time and O(n) space. Let me code it, then I'll run it on [2,7,11,15], target 9 and an edge case where no pair exists."
def two_sum(nums, target):
seen = {} # value -> index
for i, n in enumerate(nums):
if target - n in seen:
return [seen[target - n], i]
seen[n] = i
return [] # no pair found
2. Determine whether two strings are anagrams of each other.
Why they ask it: it looks trivial, which is the point — they're watching whether you jump straight to sorted(a) == sorted(b) (O(n log n)) or recognize the frequency-count solution (O(n)). It also tests whether you handle case, whitespace, and Unicode without being told to.
"First, are we case-sensitive, and do spaces count? I'll assume yes for now and ask if it matters. The quick solution is to sort both strings and compare — clean, but O(n log n). Better: if the lengths differ they can't be anagrams, so I return early; otherwise I count character frequencies in one pass with a hash map, then verify the other string decrements every count back to zero. That's O(n) time, O(k) space where k is the alphabet size. For ASCII I could even use a fixed-size array of 26 counts, which is effectively O(1) space."
3. Given a binary tree, return its level-order traversal (each level as a separate list).
Why they ask it: it confirms you can recognize that "level by level" means breadth-first search with a queue, not recursion. Candidates who default to DFS for everything reveal a gap. It also tests clean queue management and off-by-one handling on level boundaries.
Strong sample answer"'Level by level' is the signal for BFS, so I'll use a queue. I'll seed it with the root, then loop while the queue is non-empty: at the start of each iteration I record the current queue length — that's the number of nodes on this level — and process exactly that many, appending their values to a level list and enqueuing their children. When I've drained the level I push the level list onto my result. Time is O(n) since each node is visited once; space is O(n) for the queue at the widest level. I'll handle the empty-tree case by returning an empty list immediately."
4. You're climbing a staircase of n steps, taking 1 or 2 steps at a time. How many distinct ways can you reach the top?
Why they ask it: it's the gentlest possible DP problem and a great way to see whether you can recognize overlapping subproblems and avoid exponential recursion. The "aha" is spotting that it's Fibonacci in disguise. Bonus signal if you optimize from O(n) space down to O(1).
Strong sample answer"The number of ways to reach step n is the ways to reach n-1 (then take one step) plus the ways to reach n-2 (then take two) — so ways(n) = ways(n-1) + ways(n-2), which is Fibonacci. A naïve recursion recomputes the same subproblems and is exponential, so I'll go bottom-up. I only ever need the last two values, so instead of a full array I'll keep two running variables and update them n times — O(n) time, O(1) space. Base cases: one way to climb zero or one step. Let me sanity-check n=3 gives 3."
5. Given a sorted array, remove duplicates in place and return the new length.
Why they ask it: "sorted" plus "in place" is a strong hint for the two-pointer technique. It tests whether you can mutate an array without an extra data structure and reason carefully about the slow/fast pointer invariant — a frequent source of off-by-one bugs.
Strong sample answer"Because it's sorted, duplicates are adjacent, and because it's in place I shouldn't allocate a new array — that points to two pointers. I keep a slow pointer marking the end of the unique section, and a fast pointer scanning ahead. Whenever the fast value differs from the value at slow, I advance slow and copy the new value there. At the end, slow + 1 is the count of uniques. One pass, O(n) time and O(1) extra space. I'd confirm the interviewer is fine with the tail of the array being left as-is beyond the returned length, since that's the usual contract."
System-design questions
For mid-level and senior roles, the system-design round is frequently the one that decides your level. There is no correct answer — the interviewer is buying your judgment: how you scope an open-ended problem, estimate scale, choose between options, and name what you're trading away. The fatal mistake is diving into a database schema before you've asked who the users are. Strong candidates drive a clear arc: requirements, scale estimates, high-level design, data model and APIs, then deep dives on the one or two bottlenecks that matter.
6. Design a URL shortener (like a service that turns long links into short ones).
Why they ask it: it's compact enough to finish in 45 minutes yet rich enough to surface real judgment — key generation, read-heavy scaling, caching, and the read-vs-write asymmetry. It quickly separates candidates who design top-down from those who fixate on one detail.
Strong sample answer"Let me scope it. Functional: create a short code for a long URL, and redirect from the short code. Non-functional: this is extremely read-heavy — maybe 100:1 reads to writes — redirects must be low-latency, and short codes should be unguessable-ish but compact. At, say, 100M new URLs a month, a 7-character base-62 code gives plenty of headroom. For the high level: an API service writes to a datastore mapping code → long URL; reads hit a cache first. For key generation I'd avoid hashing collisions by using a counter encoded in base-62, or a pre-generated key range per host. Because reads dominate, I'd put the hot mappings in a cache and replicate the store for read throughput. I'd accept eventual consistency on analytics counts but keep the core mapping strongly consistent. The main trade-off I'm making is favoring read latency and simplicity over write-time guarantees on the analytics path."
7. Design a news feed (the timeline a user sees when they open the app).
Why they ask it: the feed problem forces the classic fan-out trade-off — do you compute the feed when content is posted (fan-out on write) or when the user opens the app (fan-out on read)? There's no universally right answer, so it's a pure test of whether you can reason about the trade-off rather than recite a pattern.
Strong sample answer"The central decision is fan-out on write versus read. Fan-out on write pre-computes each user's feed when someone they follow posts — fast reads, but expensive and wasteful for users with millions of followers, the 'celebrity problem.' Fan-out on read assembles the feed at request time — cheap writes, but slower reads. I'd go hybrid: fan-out on write for ordinary accounts so the common case is fast, and fan-out on read for high-follower accounts whose posts I merge in at read time. I'd cache the assembled feed per active user with a short TTL, and store posts in a datastore partitioned by author. The trade-off I'm naming explicitly is added system complexity in exchange for handling both the average user and the celebrity case without blowing up write amplification."
8. How would you scale a service that's suddenly getting 10× the traffic it was built for?
Why they ask it: it's less about a specific architecture and more about whether you know the standard scaling toolkit and apply it in a sensible order. Interviewers want to hear you measure before you scale, then reach for the cheapest effective lever first.
Strong sample answer"First I'd measure, not guess — find the actual bottleneck with metrics, because scaling the wrong layer wastes money and time. Assuming it's the typical web/app tier, the cheapest lever is horizontal scaling behind a load balancer since the tier is usually stateless. If the database is the bottleneck, I'd add a read replica and a cache for hot reads before considering sharding, which is a much bigger commitment. I'd add a CDN for static assets, and move anything that doesn't need to be synchronous — emails, image processing — onto a queue so request latency stays flat under load. The order matters: caching and read replicas buy a lot of headroom cheaply; sharding and re-architecture are last resorts because they add lasting complexity."
Practical CS & debugging questions
Sandwiched between coding and design, interviewers often ask applied computer-science and debugging questions to check that your fundamentals are real and not just memorized. These reward plain, concrete explanations over textbook recitation.
9. Explain the difference between a process and a thread, and when you'd reach for each.
Why they ask it: it's a fast probe of whether you understand the runtime your code actually lives in. The strong signal is connecting the definitions to a real engineering decision rather than reciting that "threads share memory."
Strong sample answer"A process has its own isolated memory space; threads live inside a process and share its memory. That shared memory is exactly the trade-off: threads are lightweight and communicate cheaply, but you inherit race conditions and need locks. Processes are heavier and isolated, so a crash in one doesn't take down the others. In practice I reach for threads (or async) when tasks are I/O-bound and need to share state cheaply — handling many network requests — and for multiple processes when I want isolation or true CPU parallelism in a runtime with a global lock, like CPU-bound work in Python. The isolation-versus-sharing decision is the real question, not the textbook definition."
10. A service that was fine yesterday is now timing out under normal load. How do you debug it?
Why they ask it: real engineering is mostly debugging systems you didn't fully build. They want a calm, systematic method — narrowing the problem with evidence — not a lucky guess. Panic and random changes are the anti-pattern.
Strong sample answer"I'd resist changing anything until I've localized it. First, what changed — a deploy, a config change, a traffic shift, a dependency? The timeline usually points straight at the cause. Then I'd look at metrics and logs to narrow the layer: is latency in the app, the database, or a downstream call? If the database, I'd check for a slow query or a missing index, maybe from a new query pattern. I'd reproduce in staging if I can, form one hypothesis at a time, and change one thing to confirm it. If it's an active incident, I'd mitigate first — roll back the suspect deploy or shed load — then root-cause calmly, and afterward write it up so it can't recur. The discipline is one variable at a time, evidence before action."
11. When would you choose a relational (SQL) database over a NoSQL store, and vice versa?
Why they ask it: data-store choice is one of the highest-leverage decisions an engineer makes, and a wrong default is expensive. They want to hear you reason from access patterns and consistency needs, not from hype.
Strong sample answer"I start from the data and the access pattern, not a preference. I reach for a relational database when the data is structured and relational, I need strong consistency and transactions — anything touching money or inventory — and I want flexible ad-hoc queries and joins. I reach for a NoSQL store when I need to scale horizontally to huge volume, the schema is flexible or evolving, and my access patterns are simple and known up front — like a key-value lookup or a document fetched by id — so I don't need joins. The honest answer is most systems end up using both: a relational store as the source of truth and a NoSQL layer or cache for high-volume, simple-access paths. The deciding factors are consistency requirements and query shape."
Behavioral & collaboration questions
Many strong coders are surprised that the behavioral round can sink an otherwise-passing loop. It can. Engineering is a team sport, and this round asks whether you communicate, take ownership, and handle disagreement and failure like a senior professional. Answer with the STAR method — Situation, Task, Action, Result — keeping the situation brief and spending most of your words on what you specifically did. Use real, specific stories with numbers; vague answers read as inexperience.
12. Tell me about a time you disagreed with a teammate on a technical decision.
Why they ask it: technical disagreement is constant in engineering, and how you handle it predicts whether you'll be a productive partner or a source of friction. They're watching for "disagree and commit" — push with evidence, then back the decision once it's made.
Strong sample answer (STAR)Situation: "On a payments service, a senior teammate wanted to add a new microservice for refunds; I thought it belonged in the existing service. Task: I owned the refund work and worried a new service would add deployment and consistency overhead we didn't need yet. Action: Rather than argue in the abstract, I wrote a one-page comparison: the latency and operational cost of a network hop, versus the coupling risk of keeping it in-service, plus a rough migration path if we needed to split later. I walked him through it and said I'd fully back whichever way we went. Result: We kept it in-service with a clean module boundary, shipped two weeks faster, and split it out a quarter later when traffic actually justified it. I learned that a written trade-off moves a disagreement forward far better than a hallway debate."
13. Tell me about a production incident you helped resolve.
Why they ask it: incidents reveal how you behave under real pressure — whether you stay calm, communicate, mitigate before root-causing, and prevent recurrence. It's one of the most predictive behavioral questions for senior engineering roles.
Strong sample answer (STAR)Situation: "Our checkout error rate spiked to about 8% during a peak sale; revenue was actively bleeding. Task: I was on call and owned getting us stable, then finding the cause. Action: I mitigated first — the timeline pointed at a deploy from an hour earlier, so I rolled it back, which dropped errors within minutes, before I fully understood why. Then I dug in: the release had added a synchronous call to a third-party tax API with no timeout, so when that API slowed, our checkout threads piled up. I added a tight timeout and a fallback, and we re-deployed safely. Result: Total customer-facing impact was about 20 minutes instead of hours. I wrote the postmortem and added a checklist item — no new synchronous external calls without a timeout — that caught two similar risks later. The lesson: stabilize first, root-cause second, and turn the fix into a guardrail."
14. Tell me about a time you had to choose between shipping fast and writing it "right."
Why they ask it: engineering is a constant negotiation between speed and quality, and they want to see that you make that call deliberately — taking on tech debt consciously and paying it back — rather than either gold-plating or shipping recklessly.
Strong sample answer (STAR)Situation: "We had a hard launch date for a partner integration and a choice: a clean, fully abstracted integration layer, or a more direct implementation that would ship on time. Task: As the engineer on it, I had to hit the date without leaving a mess that would haunt us. Action: I deliberately took on scoped tech debt — I built the direct version but isolated it behind a single interface, wrote down exactly what was deferred, and filed a tracked ticket to generalize it once we had a second partner. I flagged the decision and the debt explicitly to my lead rather than hiding it. Result: We shipped on time, won the partner, and when the second integration came three months later the interface meant the refactor took two days, not two weeks. The lesson: tech debt is fine when it's a conscious, isolated, written-down loan — not when it's an accident."
Don't walk into this loop alone.
Interview prep is the heart of Marqee's Executive service. A real strategist runs full mock interviews with you — coding, system design, and behavioral — tears down your answers line by line, and preps you for the specific companies on your calendar, so you walk into the real thing rehearsed and calm.
See how the Executive prep works →How to prepare for a software engineer interview
The candidates who do best aren't the ones who grind the most problems — they're the ones who practice deliberately across the right surfaces and rehearse out loud. Here's a plan that scales from four weeks (experienced) to twelve (new grads and career changers).
| Surface | What to do | How much |
|---|---|---|
| Coding patterns | Drill by pattern — hash maps, two pointers, sliding window, binary search, BFS/DFS, DP — not random problems. Always solve out loud and state complexity. | 1–2 problems/day |
| System design | Once coding is solid, study the core building blocks (caching, load balancing, sharding, queues) and practice 6–8 canonical designs end to end. | 2–3 designs/week |
| Behavioral stories | Write 5–7 STAR stories from real projects — a conflict, an incident, a proud win, a failure, a fast-learning moment — and rehearse them aloud. | One pass, then refine |
| Mock interviews | Simulate the real thing under time, with someone watching and pushing back. This is the highest-leverage prep there is. | 1–2/week near the date |
| Company research | Learn the company's stack, products, and engineering values so your answers and your questions land specifically. | Before each loop |
Three principles separate effective prep from busywork. First, narrate everything — practicing in silence trains the wrong skill, because the interview rewards thinking out loud. Second, review your misses; a problem you got wrong and then understood deeply is worth ten you breezed through. Third, do mock interviews. Nothing else surfaces the gap between "I can solve this at my desk" and "I can solve this while a stranger watches and interrupts." A solid résumé gets you the interview — see our software engineer resume example for that — but mock reps are what convert it into an offer.
Common mistakes & red flags
Interviewers compare notes against a rubric, and certain behaviors reliably sink otherwise-strong candidates. Most are avoidable once you know they're being watched.
- Coding in silence. A correct answer with no narration scores below an incomplete one with clear reasoning. The interviewer can only credit the thinking they hear.
- Jumping to code before clarifying. Writing code against assumptions you never checked signals you'd do the same with real requirements. Always restate the problem and confirm constraints first.
- Ignoring edge cases. Empty input, a single element, duplicates, integer overflow, null — naming these unprompted is a strong positive signal; missing them is a classic down-rank.
- Not reasoning about complexity. Being unable to state the time and space cost of your own solution suggests you wrote it without understanding it.
- Diving into a schema on a design question. Skipping requirements and scale estimates is the single most common way to fail the system-design round.
- Getting defensive when challenged. When an interviewer pushes back, they're often testing whether you can take input. Defensiveness reads as a future collaboration problem.
- Bad-mouthing former teammates. In behavioral rounds, blaming others makes the interviewer imagine you blaming them. Stay gracious, even about real conflict.
- Vague behavioral answers. "We improved performance" with no specifics or numbers reads as either inexperience or invention. Use real stories with real metrics.
Questions to ask the interviewer
The "do you have any questions for me?" close is not a formality — it's still being scored, and it's your chance to show genuine engineering curiosity and judgment. Skipping it, or asking only about perks, is a missed signal. Ask things that reveal how the team actually works. For a deeper menu, see our guide on questions to ask the interviewer; here are strong, role-specific ones for engineers:
- "What does the path from a commit to production look like here — how often do you deploy, and how automated is it?"
- "How do you balance shipping features against paying down technical debt? Can you give a recent example?"
- "What does on-call look like for this team, and how do you handle incidents and postmortems?"
- "How are technical decisions made — RFCs, a tech lead, consensus? Walk me through a recent one."
- "What's the biggest engineering challenge the team is facing in the next six months?"
- "How do engineers grow here — what separates someone at my level from the next one up?"
- "What does a successful first 90 days in this role look like to you?"
Keep preparing
This page focuses on the software engineer loop specifically. For the broader fundamentals that apply to any role, these free guides go deeper:
Frequently asked questions
A typical loop has four to six rounds: a recruiter screen, a technical phone screen with one or two coding problems, then an onsite of two or three coding rounds, one system-design round for mid and senior candidates, and a behavioral or "values" round. Each round scores a different dimension — problem-solving, code quality, design judgment, and collaboration — so you're evaluated as a whole engineer, not just a coder.
The single most common pattern is a data-structures problem solvable with a hash map for O(n) lookups — the classic "find two numbers that sum to a target" is the canonical example. Interviewers favor it because it cleanly separates candidates who brute-force at O(n²) from those who trade memory for time with a hash map, and it leaves room for follow-ups about duplicates, sorted input, and very large datasets.
Start by clarifying scope and estimating scale (users, reads-per-second, data size) before drawing anything. Then sketch the high-level components — clients, API layer, services, datastore, cache — define the data model and key APIs, and only then go deep on the one or two bottlenecks the interviewer cares about, naming explicit trade-offs (consistency vs. availability, SQL vs. NoSQL, caching strategy). The goal is to demonstrate structured judgment, not to recite a perfect architecture.
For most roles, no. You need fluency in the core toolkit — arrays, hash maps, two pointers, binary search, stacks and queues, trees and graphs (BFS/DFS), and basic dynamic programming — plus the ability to reason about time and space complexity out loud. Exotic algorithms rarely appear; what's tested is whether you can recognize which standard pattern fits and implement it cleanly under time pressure.
Common ones include: a time you disagreed with a teammate on a technical decision, a production incident you helped resolve, a project you're proud of and your specific contribution, a time you had to learn a new technology quickly, and a tradeoff you made between shipping fast and code quality. They test collaboration, ownership, and engineering judgment — answer them with the STAR method and real specifics.
Four to eight weeks of consistent practice is typical for experienced engineers; new grads and career changers often need eight to twelve. Spend the bulk of it on coding pattern fluency (one to two problems a day, spaced across patterns), add system design once coding is solid, and rehearse five to seven behavioral stories out loud. Quality of deliberate practice matters far more than raw hours.
The biggest red flags are coding in silence, jumping to code before clarifying the problem, ignoring edge cases, being unable to reason about complexity, getting defensive when challenged, and bad-mouthing former teammates. Interviewers also down-rank candidates who can't explain a trade-off they made — it signals they implemented without understanding why.
Stop applying. Start interviewing.
A real Marqee strategist finds the roles, tailors your materials, runs recruiter outreach and referral discovery, and submits on your behalf — and on Executive, runs the mock interviews that get you offer-ready. Become a marquee candidate instead of one of the pile.
See how it works →