Software Engineer interview questions
Software engineer interviews test coding, system design and how you collaborate. Expect one hands-on problem, one design or scenario question, and behavioral rounds.
🎤 Practice these out loud with AceCoach →The questions
What software engineers are tested on
What each round is really testing
A software engineer loop is usually built from 6 kinds of question: Coding, System design, Behavioral, Judgment, Scenario, 2026. They are scored separately, which matters more than it sounds — being strong on the technical rounds does not offset a vague behavioural one, because a different interviewer writes that feedback against different criteria and never sees your other scores.
The framework under each question above is not a script to recite. It is the shape of a complete answer — the parts an interviewer is listening for and ticking off. Two candidates can give the same facts and score differently because one of them signposted the structure ("there were three constraints; let me take them in order") and the other produced the same content as an unstructured paragraph. Say the structure out loud; it is doing work.
Turning your own experience into answers
The most common preparation mistake is collecting questions and never building material. Your answers should come from your own work, and your resume is the index of it. Take a line like this one from the software engineer resume example:
Cut checkout p99 latency from 850ms to 310ms via database read-replicas and a Redis caching layer; throughput 8M requests/day
A resume bullet is the result with everything else compressed out. An interview answer is the same story decompressed: what the situation was and why it mattered, what you specifically owned, what you tried that did not work, and only then the number. Expect the follow-up to go straight at the part the bullet omits — how you measured it, what you would do differently, who disagreed with you. Prepare the decompressed version of four or five bullets and you have covered most behavioural rounds.
A week of preparation that works
Days one and two: write the decompressed version of five pieces of your own work, each ending in something measured. Day three: rehearse them out loud — this is the step almost everyone skips, and it is where you discover that an answer clear in your head takes ninety seconds and three restarts to say. Days four and five: work the technical questions above, talking through your reasoning rather than solving silently. Day six: prepare your own questions, which are assessed whether or not anyone tells you so. Day seven: rest, and re-read your own notes rather than adding new material.
If you only have an evening, do the spoken rehearsal. It has the highest return per minute of anything on this list, and it is the part that cannot be improvised on the day. AceCoach will ask these questions aloud and score the structure of what you say back, which is the closest thing to the real conditions you can get on your own.
Before the interview
Check the company's format as well as the role's questions — the same software engineer questions are asked very differently at a big-tech loop, an IT services process and a startup. See Big Tech, IT services & consulting or startups & finance. And make sure the resume that got you the interview can survive the questions it invites: everything on it is fair game, and the numbers attract the most scrutiny.
Earlier than the interview? How to become a software engineer covers the routes into this role, what to learn in what order, and what it pays measured from live postings.
Frameworks are guidance, not scripts — the point is to make the answers your own. All roles →
Communication and explaining technical decisions
Coding and system design questions aren't really about the code; they're about how you think and communicate. A hiring manager watching you code in an interview isn't trying to catch mistakes. They're listening for whether you narrate your thinking, whether you make assumptions explicit, whether you ask clarifying questions, and whether you consider tradeoffs. When you sit down to a coding problem, the best first move is not to code. It's to narrate: "I understand the problem as: given X input, return Y output. I'm assuming these constraints: [list them]. Is that correct?" This tells the interviewer you're thorough and humble.
Tradeoff thinking separates competent engineers from thoughtful ones. When you propose a solution, name what you're optimising for and what you're sacrificing. "I'll use a hash map here because lookup is O(1), but space is O(n). If space were critical, I'd use a sorted list and binary search." This shows you understand the cost-benefit. A hiring manager hears that and thinks: they know what matters and make conscious tradeoffs. "I'll use X" without explaining the tradeoff says: I picked it without thinking or I don't know the alternatives.
Asking for clarification instead of assuming is a professional signal. "Can you clarify the scale? Is this 100 requests per second or 100,000?" affects your entire design. "Do you care more about latency or throughput?" is a valid design question. Vague is normal in interviews because hiring managers want to see if you ask. The candidate who clarifies before designing is stronger than the candidate who assumes and designs based on wrong assumptions.
Technical depth and breadth decisions
Going deep in one language versus breadth in many is an interview signal. Hiring managers care about depth in at least one language because it means you've hit edge cases, learned from mistakes, and understood nuance. If you've shipped 5+ projects in Python and can speak about GIL, memory management, and package versioning, that's stronger than knowing Python, Java, Go, C++ and Rust at tourist level. Depth shows ownership. Breadth shows flexibility. Most strong engineers have depth in 2-3 languages and familiarity in several others.
Algorithms and data structures matter because they show you can think about efficiency. You don't need to memorise algorithm names, but you should be able to spot when a naive solution is O(n²) and think about whether that matters. "For this problem with n=100, O(n²) is 10,000 operations, which is fast. But if n=1M, that's 10^12 operations, which might be too slow. Let me think of an O(n log n) solution." This shows judgment about when to optimise. Premature optimisation is waste; ignored inefficiency at scale is a bug.
Testing and edge cases reveal maturity. When you finish coding a problem, don't declare victory. Say: "let me think about edge cases: empty input, single element, duplicates, negative numbers". Then trace through your code on one. If your code breaks on an edge case, fix it and retest. Hiring managers aren't looking for perfect code; they're listening for whether you anticipate failure modes. "I just wrote this, but I should test it on [edge case]" is a signal you think defensively.
System design and scaling thinking
System design is about showing your mental model of software at scale. You don't need to have built a system handling 100M users. You need to show how you'd think about it if you did. When you're asked to design something, start with clarifications: peak QPS (queries per second), data volume, latency requirements, consistency requirements. Then talk through the layers: API design, data model, caching strategy, storage, CDN, load balancing. Each layer should answer: does this scale? A hiring manager hears you articulate layers and think they can put you on a system and you'll add value.
Naming the bottleneck shows you think like an experienced engineer. "If this service handles 10K requests per second and each request touches the database, the database becomes the bottleneck. We'd add a cache." This is obvious in retrospect, but many junior engineers don't anticipate it. Next-level thinking: "caching helps, but if users expect fresh data, cache invalidation becomes complex. We might use write-through caching or short TTLs, but that reduces cache hit rate. Let me think if there's a different approach." This shows you've experienced that pain.
Availability and reliability concepts matter increasingly. If you talk about failover, replication, or circuit breakers, you've thought about what happens when things break. "Single database is a single point of failure. We'd replicate to a standby and failover automatically." This is basic reliability thinking. More advanced: "automatic failover assumes the standby is warm and in sync. If sync replication is too slow, we use async and accept potential data loss. This is a tradeoff we'd document and discuss with the team." This shows you understand the costs of reliability choices.
Frequently asked questions
Should I write perfect code in a coding interview?
No. Hiring managers expect code that works and is readable. Comments explaining tricky parts are good. Elegant one-liners that nobody understands are bad. If you make a mistake and catch it, that's fine — fix it and move on. If you don't notice, the interviewer might point it out. The point is thinking, not perfection.
How long should I spend on a coding problem?
Usually 45 minutes in an interview. Spend 5 minutes clarifying and planning, 25-30 minutes coding, 10 minutes testing and edge cases. If you're stuck halfway, say so: "I'm realising this approach might be slow. Let me think of a different way." Stuck silence is worse than "I'm thinking out loud; let me work through this."
Do I need to know complex algorithms like balanced trees or tries?
Maybe, depending on the role. If you're interviewing for backend infrastructure, yes. For most product roles, you need trees, linked lists, hash maps, basic sorting and searching. Study the role's likely focus area. Read the job posting for hints. If you don't know an algorithm, you can sometimes reinvent it or do something slower; explain the tradeoff.
What if I get a system design question I've never thought about?
That's the point. Start with the fundamentals: scale, data model, caching, storage. Don't panic. You've designed other systems; the principles transfer. Say what you're uncertain about: "I haven't built a real-time notification system, but I know Kafka is often used for event streaming. Let me think about how I'd use it here." Humility and thinking out loud is fine.
Should I memorise common interview problems?
No. Interviewers usually ask variations they haven't seen before specifically to avoid that. Understand the concepts (linked lists, trees, sorting, dynamic programming) and you can solve variations you haven't seen.