Software Engineer Interview Questions (2026)

Pick a real example with a clear technical substance (not a personality conflict). State the position you held, the position the team took, and the reasoning on both sides. Describe how you raised the concern (privately first, in writing if appropriate). End with what happened and what you learned: did your concern turn out to be right, wrong, or partially valid? Either ending can land well if you tell it honestly.

Pick a project where you owned a meaningful slice. Open with the problem and the constraint that made it hard. Describe the approach you took, including one or two alternatives you considered and why you ruled them out. Cover what you actually built and one specific technical decision you made. Close with the outcome (a number if you have one) and what you would do differently. Keep the whole thing under three minutes.

Name the technology and the deadline that forced the learning. Describe the path you took (docs, source code, a small prototype, talking to someone who already knew it). Be specific about the moment you knew you had enough to be useful. End with what shipped and how it held up.

Lead with what you are looking for that the new role offers (scope, technology, mission, growth). Acknowledge what is good about your current job so you do not sound bitter. If the truthful answer involves a problem at your current company, state it neutrally and do not dwell.

Always have at least three questions ready, calibrated to the interviewer's role. For an engineer: what does a typical week look like, what is the most painful part of the codebase, how does the team make technical decisions. For a manager: what does success in the first 90 days look like, how is the team measured, what is the team's relationship with the on-call rotation. Skip questions easily answered by the company website.

Group by sorted characters as the hash-map key. Time complexity is O(n * k log k) where k is the average string length. Mention the alternative of using a 26-element character-count tuple as the key, which gets you to O(n * k) at the cost of slightly more code. State which you would prefer in production and why.

Start with the read/write ratio (heavily read-skewed). Cover ID generation: counter vs hash vs base62 of an autoincrement, with the tradeoffs. Talk about the cache (Redis, with the full URL keyed by short code). Cover analytics (event stream to a separate store, not the hot path). Discuss what to do at high scale: read replicas first, then sharding by short code prefix. Acknowledge a few edge cases (custom aliases, expiration, abuse prevention).

For exact counting under tight memory: a deque keyed by timestamp with a hash set tracking distinct IDs in the current window, advancing both as the window slides. Discuss the memory/accuracy tradeoff: at very high cardinality, swap the hash set for a HyperLogLog and accept ~1% error. Be explicit about which one you would pick in production and what data you would need to make that call.

TCP: connection-oriented, ordered delivery, reliable, congestion control. UDP: connectionless, no delivery guarantees, no ordering. Choose UDP when retransmission would do more harm than dropping (real-time audio/video, game state, DNS lookups), or when you are building your own reliability layer (QUIC, custom protocols). Mention QUIC as the modern example of why this question is more interesting than it used to be.

Start with the requirement: per-user fairness, burst tolerance, latency budget. Token bucket is usually the right default: cheap, supports bursts up to bucket capacity, plays nicely with distributed enforcement (Redis-backed counters with atomic INCR/EXPIRE). Cover what to do under multi-region traffic (regional buckets with eventual reconciliation, or pin users to a home region). Mention the user-experience side: returning Retry-After headers and structured 429 responses.

DNS resolution (recursive resolver, root, TLD, authoritative). TCP handshake then TLS handshake. HTTP request constructed by the browser. Server processing (load balancer, app servers, DB queries, response). Browser parses HTML, fires off subresource requests in parallel, builds the DOM, runs JavaScript, paints the page. Discuss caching at every layer (DNS, HTTP, service worker, CDN, browser cache). The interviewer will steer you deeper on whatever interests them.

Start by confirming it is actually a leak: graph RSS over time, separate slow growth from a saw-tooth GC pattern. Take heap snapshots at intervals using --inspect or clinic.js, diff them, and look for retained objects with growing instance counts. Common culprits: closures holding references through long-lived event emitters, unbounded in-memory caches, listeners attached but never removed. Once you find the candidate, write a minimal repro outside production before fixing.

XOR all integers from 0 to N together, then XOR the result with every integer in the input. Pairs cancel out and the missing integer remains. O(n) time, O(1) space. If the question says "could be more than one missing" or "could be duplicates", the answer changes; ask about preconditions before you write code.

Pessimistic: take a lock on a row before reading or writing, hold until commit. Safer under contention, but adds latency and can deadlock. Optimistic: read freely, then check at commit time whether the row changed since you read it (version column or timestamp), retry if it did. Better throughput when conflicts are rare. Choose optimistic for most user-facing CRUD where conflicts are unlikely; pessimistic for hot rows where conflicts are common (inventory counters, financial ledgers).

Pick a bug where the symptom and the cause were genuinely far apart. Describe what made it confusing at first, the wrong hypotheses you ruled out, the moment you realized what was actually happening, and the fix. If the bug was caused by a faulty mental model rather than a typo, this is the strongest version of this story.

Open with the problem and the volume the system needed to handle. Describe the high-level architecture (drawing helps if you have a whiteboard). Cover the database choice, the API surface, how it scales, and what happens when a component fails. Pick one part you would design differently with hindsight and explain why.

Open the incident channel and post that you are looking. Pull up dashboards, confirm scope (one region, all customers, specific endpoint). If a recent deploy is the most likely cause, roll back first and investigate after. Page the on-call for any dependency that looks suspicious. Communicate every five minutes even if you have nothing new. Save root-cause analysis for the postmortem.

Talk to the teammate first, in private. Find out what is happening: are they running the checks locally? Is something flaky? Is the blast radius unclear? Often the fix is changing the system (faster pre-push, branch protection, clearer ownership) rather than changing the person. If the behavior continues after a clear conversation and a system fix, escalate to your manager with specifics.

Ask why this project is the priority. Often you will hear context you did not have. If you still disagree, write up your case in a short doc covering tradeoffs and alternatives, and share it with your manager. If they hold the line, commit to executing well; do not slow-roll the project. Revisit the conversation after the project ships if the outcome supports your original concern.

Start with the dashboards: what does it normally do, what is the request shape, what does normal load look like. Read the on-call runbook even if it is sparse. Skim the codebase for the request entry points and follow one through to the database. Pull recent incidents and read the postmortems if any exist. Find the people who have touched the code recently in git blame and ask them targeted questions. Write a one-page brief as you go; that becomes the missing documentation.