Reverse a linked list. After you finish, optimize for memory.

Clarify the input — is it singly or doubly linked? Can you mutate the original? Then write the iterative pointer-swap solution (prev, current, next). After it works, discuss space complexity (O(1) for iterative vs O(n) stack for recursive). The optimize-for-memory follow-up is testing whether you know the recursive version uses the call stack.

Design a URL shortener that handles 10K writes/second and 100K reads/second.

Start with capacity math out loud — back-of-envelope storage (URL length × throughput × retention), read/write QPS, peak vs average. Sketch components: API layer, ID generation strategy (counter vs hash vs base62 from auto-increment), datastore (Postgres vs DynamoDB tradeoff), cache layer (Redis for hot reads). End with what breaks first — your bottleneck and how you would shard.

Tell me about a time you disagreed with a senior engineer or manager. What did you do?

Use STAR but spend 60% on the action. Set context briefly (one sentence — what was the technical disagreement). Describe what you did to surface it — specifically, did you write a doc, propose an alternative, run a small experiment? Be honest about the outcome including if you were wrong. Close with what you learned about disagreeing well.

Given a binary tree, return the right-side view (the node visible from the right at each depth).

Recognize this is a level-order problem. Use BFS with a queue, track the last node at each level (or first if reversing direction). Alternative: DFS with depth tracking — visit right children before left, take the first node you see at each new depth. Code one cleanly, mention you considered the other.

How would you debug a production service that has p99 latency spiking from 50ms to 800ms intermittently?

Walk the funnel: first, look at what is correlated — time of day, deployment, request volume, downstream dependency. Check the obvious: GC pauses, lock contention, cold caches, slow downstream call. Talk through what tools you would use — APM traces, flame graphs, kernel-level (eBPF if available). Be specific: "I would pull a 5-minute slow-trace sample from one bad request and compare against a good baseline."

Describe a time you shipped something that broke production. What was your role in the recovery?

Pick a real incident, ideally one where you were the proximate cause. Describe the technical failure in one sentence. Spend most of the answer on the recovery — how you found it, what you did first (revert / mitigate / communicate), and what process change came out of it. End with the longer-term fix, not the immediate hotfix.

Implement an LRU cache with O(1) get and put.

Combine a hashmap with a doubly-linked list. Hashmap gives O(1) lookup of the node; doubly-linked list gives O(1) removal and reinsertion at the head. Walk through the put case: if the key exists, update and move to head; if not and full, evict the tail; insert new node at head. Edge cases: capacity of zero, duplicate keys.

How do you decide when to write a unit test vs an integration test vs an end-to-end test?

Frame it as the test pyramid by cost: unit tests are cheap to write and fast to run, so cover branching logic and edge cases there. Integration tests verify that your modules wire correctly to external dependencies — write them for the seams. End-to-end tests are expensive and flaky, so reserve them for critical user-visible flows (checkout, signup) and accept they will be few. Mention that you write the test layer where the failure mode lives, not where the rules say.

Why are you leaving your current company / why this role?

Lead with what you want next — specific work, scale, technology, or scope. Reference one or two things specific to THIS company that match. Mention the current situation briefly and neutrally. Do not bash your current employer; do not claim everything is perfect. Authenticity beats polish.

You join the team Monday. The codebase has 40% test coverage, a 6-hour CI pipeline, and a deploy that requires a manual gate. What do you do in your first 90 days?

First 30 days: read, ship one small thing through the existing pipeline to feel the pain, document what slows you down. Days 30-60: pick ONE bottleneck (probably the CI time, since it gates everything else), build a proposal, get buy-in. Days 60-90: ship the improvement, measure it, hand off. Reject the urge to fix all three problems at once.

Two sum, then follow-up: three sum, then follow-up: k-sum.

Two-sum: hashmap of complement, O(n) time / O(n) space. Three-sum: sort then two-pointer for each fixed element, O(n²) time / O(1) extra space. K-sum: recurse — for each k > 3, fix one element and recurse with k-1, base case k=2 is the hashmap or two-pointer. Discuss the dedup tricky case (sorted arrays with repeats).

What is the difference between a process and a thread, and when would you choose one over the other?

Process: independent memory space, OS-level isolation, expensive to create, communicates via IPC or sockets. Thread: shared memory within a process, cheap to create, communicates via shared state (with locks). Choose processes when you need isolation (one crash should not take down others) or when running CPU-bound work in languages with a GIL (Python). Choose threads for I/O concurrency in languages with good thread primitives, or when memory sharing is the whole point.

Where do you want to be in three years?

Be honest about direction (IC track, manager track, founder, specialist) without being rigid about title. Tie it to skill development, not just job rungs — "I want to be the engineer the team calls when X breaks." Acknowledge uncertainty without sounding aimless. If you genuinely do not know IC vs manager, say so and explain how you will figure it out.

Do you have any questions for me?

Have 3-4 questions per interviewer, tailored to their role. For an engineer: "What is the most painful part of working on this team?" For a manager: "How do you decide who works on what?" For an exec: "What is the bet this company is making that you would not have made two years ago?" Avoid anything answerable from the careers page.

How long does the typical software engineer interview process take?

4 to 6 weeks end-to-end at most US companies as of 2026. The fastest companies (early-stage startups, some hot AI labs) can close in 8-12 days. Big Tech is back to 5-7 weeks after compressing in 2023.

Should I use LeetCode, NeetCode, or AlgoMonster to prep?

NeetCode 150 is the highest-leverage starting list — it covers the patterns that appear in 80% of real interviews. AlgoMonster is stronger for pattern recognition once you have the basics. Raw LeetCode without a curated list is the slowest path.

Do I need to be able to design distributed systems for a mid-level SWE role?

In 2026, yes — at L4/SDE-II/equivalent levels, almost all FAANG and adjacent companies now include a 45-minute systems-design round even for mid-level roles. The bar is lower than for senior (you are not expected to design Twitter), but you do need to be able to reason about API design, basic data modeling, and at least one caching layer.

Is it true that AI coding assistants are being used in interviews now?

Yes, but inconsistently. Some companies (Anthropic, GitHub, a handful of startups) explicitly allow Copilot or Claude in coding rounds and adjust the difficulty accordingly. Most companies prohibit them. Always ask in the recruiter screen — assuming wrong gets candidates rejected.

What should I do in the 48 hours before an onsite?

Less than you think. Light review of 1-2 patterns you feel weak on, re-read your STAR stories once, sleep well, eat real meals. Aggressive last-minute prep correlates with worse outcomes — fatigue costs more than the last 10 problems gain.

Technology$80,000 - $180,000

Software Engineer Interview Questions

What 2026 SWE interviews actually look like

Software engineering interviews changed in 2025 with the shift from algorithm-heavy loops to mixed coding-plus-systems-design. These are the questions that determine offers — drawn from documented patterns at Big Tech, mid-size SaaS, and high-growth startups — with the answer frameworks that map to how hiring committees actually score.

Typical rounds

End-to-end time

4-6 weeks

Questions covered

What the Software Engineer interview loop actually looks like

Recruiter Screen

• Phone call• 30 min

Compensation alignment, basic background check, timeline. No technical content.

Hiring Manager Screen

• Video call• 45 min

Project depth — pick one past project, go deep on technical decisions, tradeoffs, and your specific contribution.

Technical Phone Screen

• Live coding (CoderPad / HackerRank)• 60 min

One medium-difficulty problem (graph/tree/hashmap). Communication > optimal solution.

Onsite Loop

• 4-5 back-to-back interviews• 240 min

2 coding rounds, 1 systems-design (mid+), 1 behavioral/leadership, optionally 1 domain-specific.

Bar Raiser / Final

• Cross-team interview• 60 min

A senior engineer from a different team probes for raise-the-bar signal. Often the deciding round.

15 Software Engineer interview questions

Tap any question to see what the interviewer is really asking, how to structure your answer, and the red flags to avoid.

What they're really asking

Can you describe technical work with depth, or do you only know the buzzwords? They want to test whether you operated at the level your resume claims.

Answer framework

Pick one project, ideally from your last 18 months. Open with the business problem (one sentence), then the architectural decision you owned (not just contributed to). Go deep on one specific tradeoff — why you chose technology X over Y, what failed, what you would do differently. Close with a measurable outcome.

What a strong answer signals

You can name specific files, services, or systems by component. You explain a decision you made that turned out to be wrong, and what you learned. You quantify impact in user-visible or revenue-visible terms, not "improved code quality."

Red flags to avoid

•Using "we" throughout — interviewer cannot determine your individual contribution
•Generic technology lists ("used React, Node, AWS") without explaining decisions
•Cannot answer follow-up "what would you change?" — signals shallow ownership

How Software Engineer hires actually get decided

Approximate weight hiring committees place on each dimension. Use this to focus your prep on what actually moves the decision.

Technical signal (coding + systems design)

45%

Can you write correct code and reason about systems at the scope of the role. Most companies score this on a 4-point rubric and require a minimum bar.

Behavioral / leadership signal

25%

How you handle conflict, failure, and ambiguity. Senior+ candidates fail here more often than they fail coding.

Bar raiser / culture-add signal

15%

Does the candidate raise the bar for the team. At Amazon this is a formal role; at most companies it is the cross-team interviewer.

Domain-specific signal

10%

For specialized roles — ML, distributed systems, frontend performance. For generalist SWE roles, this may not exist as a separate dimension.

Recruiter / hiring manager fit

Compensation alignment, timeline, team fit. Rarely determinative, but can swing a borderline case.

How to prepare for a Software Engineer interview

Time-box your coding prep to depth, not breadth

60 LeetCode mediums solved well beats 300 solved superficially. Pick 6 patterns (two pointers, BFS, DFS, dynamic programming, intervals, heap) and rotate through them daily for 4 weeks. The interview tests pattern recognition, not novel problem-solving.

Write 3 STAR stories that cover 8 themes

Behavioral interviews recycle the same themes: conflict, failure, leadership, ambiguity, persuasion, prioritization, mentorship, technical-business tradeoff. You do not need 8 stories — you need 3 deep stories that you can flex to cover all 8 themes.

Build one systems-design template you fully understand

Pick one canonical design — URL shortener, news feed, or rate limiter — and understand it to the level where you can defend every decision. In the interview, you map the new question onto the template, then adjust. Trying to design from scratch under time pressure is how candidates freeze.

Practice talking while typing

The number-one reason strong candidates fail technical screens is silence. Practice solving problems out loud, alone, on video, for 4-5 hours total. The act of narrating slows your code down by maybe 10%, but the interviewer needs the narration to score you.

Ask for the rubric, indirectly

In the hiring manager screen, ask: "What separates a strong hire from a borderline one on your team?" The answer tells you what to emphasize for the rest of the loop. Most candidates never ask.

Software Engineer interview FAQs

More for Software Engineers

Software Engineer resume example Software Engineer cover letter Software Engineer salary guide Skills for Software Engineers How to become a Software Engineer

Interview prep for related roles

Frontend Developer interview questions

Technology • $70,000 - $150,000

Backend Developer interview questions

Technology • $80,000 - $160,000

Full Stack Developer interview questions

Technology • $80,000 - $170,000

Data Analyst interview questions

Technology • $60,000 - $120,000