Software Engineer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
Most software engineer interviews have four parts: a recruiter screen, a coding round, a system design round for mid-level and senior roles, and a behavioural interview. Some companies use a take-home task or pair programming instead of live coding.
They all test the same things: breaking a problem down, writing correct and readable code, reasoning about trade-offs, and working well with others in a hard week.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Tell me about the most technically complex thing you've built.
What they're really asking: Can you explain a hard system simply, and was the hard part really yours?
Answer outline (STAR)
- SituationA system with real constraints: scale, legacy code or a deadline.
- TaskThe part you personally owned.
- ActionTwo or three key design decisions, and the options you rejected.
- ResultA measurable outcome, and what you'd change now.
Full sample answer (fictional example)
At a ticketing startup I built the seat-hold service: a clicked seat is reserved for ten minutes. A big on-sale meant 8,000 holds a minute on one event. I owned the service end to end. I rejected Postgres row locks because requests queued behind them, and a plain in-memory cache because holds would vanish on restart. I used Redis with atomic set-if-absent and an expiry, and wrote holds to Postgres asynchronously for recovery. At the next on-sale p99 stayed under 40 milliseconds with no double-sold seats. Today I'd add a replay tool for the hold log, because one disputed seat cost half a day.
2.Tell me about a bug that took you a long time to find.
What they're really asking: Do you debug with hypotheses and evidence, or with guesswork?
Answer outline (STAR)
- SituationA production bug that appeared only under certain load or data.
- TaskFind the root cause, not just stop the symptom.
- ActionA reproduction, logs, extra instrumentation, bisecting commits.
- ResultThe fix, and the test that now guards it.
3.Describe a time you disagreed with a technical decision on your team.
What they're really asking: Can you argue with data, accept being overruled and still commit?
Answer outline (STAR)
- SituationA design choice you thought was wrong, such as a new framework.
- TaskRaise it before changing course became expensive.
- ActionWrite up the trade-offs, propose a time-boxed spike, and listen.
- ResultWhat was decided, and how you backed it either way.
Full sample answer (fictional example)
We were choosing between building our own job queue and paying for a hosted one. I wanted the hosted one, because nobody wanted to be paged for a queue. My lead preferred building, to avoid the vendor bill. I wrote down the on-call cost and a rough price comparison, asked for a decision date, and then accepted the call. I took the first on-call rotation and wrote the runbook. Six months later we reviewed it in a retro: two small incidents, and the vendor's price had doubled. We kept ours.
4.Tell me about a time something you shipped broke in production.
What they're really asking: Do you own mistakes, fix them calmly and leave the system safer?
Answer outline (STAR)
- SituationA release that caused errors, downtime or bad data.
- TaskRestore service first, then learn why the bug got through.
- ActionRoll back, tell the people affected, run a blameless review.
- ResultThe safeguard you added: a test, a feature flag or a canary release.
Full sample answer (fictional example)
A migration I wrote added a column and backfilled it in one transaction. On release night it locked the orders table for four minutes and checkout failed. I rolled back within a minute of the alert, said in the incident channel what had happened, and told support which orders to check. The next day I ran a blameless review. The cause was simple: I had tested on 10,000 rows, not 40 million. We now rehearse migrations on a production-sized copy, and CI flags long locks. No migration has locked a table since.
5.Tell me about a time you helped a teammate get better.
What they're really asking: Do you raise the level of the people around you? It weighs more with seniority.
Answer outline (STAR)
- SituationA newer engineer struggling with reviews, tests or an unfamiliar area.
- TaskHelp them grow without taking the work away.
- ActionPair on one task, give specific review comments, agree a next step.
- ResultWhat they could then do on their own.
6.Tell me about a time you picked up a technology you had never used.
What they're really asking: How fast you learn, and from which sources.
Answer outline (STAR)
- SituationA project needing a tool you hadn't touched.
- TaskBecome useful without slowing the team.
- ActionRead the official docs, build a throwaway, ask for early review.
- ResultWhat shipped, and what you passed on.
Full sample answer (fictional example)
When my team moved to Go, I had only written Python, and my first service was due in three weeks. I did the official tour, rebuilt a small internal tool in Go as a throwaway, and asked a teammate to review it after two days instead of at the end. Her comments showed I was writing Python in Go syntax, mostly around error handling and goroutines. I corrected that before starting the real service, which shipped on time. Afterwards I wrote a short guide for the next Python developer joining, listing my five mistakes.
7.Describe a time you got tough feedback on your code or design.
What they're really asking: Whether criticism improves your work or makes you defensive.
Answer outline (STAR)
- SituationA review that found a flaw you had missed.
- TaskSeparate the point from the delivery.
- ActionAsk for a concrete case, test the claim, redo the weak part.
- ResultThe better result, and a habit you kept.
Full sample answer (fictional example)
A senior engineer rejected my design for a pricing cache, saying it would show stale prices. I was annoyed, because I had tested it, so I asked him for a case. He described a midnight price change that my time-based expiry would miss for up to an hour. He was right. I added event-based invalidation for price updates and kept the expiry only as a fallback, and the new design shipped a week later. Now I write a half-page design note before building anything that caches, and ask a reviewer to attack it first.
8.Tell me about leading a piece of work without being the manager.
What they're really asking: Do people follow your lead on influence alone?
Answer outline (STAR)
- SituationA cross-team migration with no single owner.
- TaskAlign several engineers without authority.
- ActionWrite a one-page plan, split the work, unblock others first.
- ResultWhat was delivered, and what peers said.
9.Tell me about a time you paid down technical debt.
What they're really asking: Do you pick debt that really slows people down?
Answer outline (STAR)
- SituationA module everyone feared touching.
- TaskWin the time to fix it beside feature work.
- ActionMeasure its cost, fix in small steps, pin behaviour with tests.
- ResultTime or incidents saved, and the team's reaction.
10.Tell me about a decision you made with incomplete information.
What they're really asking: Can you act without certainty and stay ready to change course?
Answer outline (STAR)
- SituationA choice that couldn't wait, such as a data model.
- TaskDecide well enough to move without boxing the team in.
- ActionState assumptions, choose the reversible option, set a review date.
- ResultWhat happened, and whether you reversed it.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.How would you design a URL shortener that handles millions of new links a day?
What they're really asking: A design warm-up: do you clarify requirements and justify each component?
Answer outline
- Clarify the read-to-write ratio, expiry, custom aliases and analytics first.
- ID generation (a counter in base62, or hashes with collision checks), a key-value store and a cache.
- Scale reads with replicas and a CDN, and say what happens when the cache fails.
12.What happens when you type a URL into a browser and press Enter?
What they're really asking: The breadth of your mental model, and whether you choose the right depth.
Answer outline
- DNS, the TCP and TLS handshakes, then the HTTP request to a CDN or load balancer.
- The server's application, cache and database, and the response.
- The browser parses, fetches assets and renders. Go deep wherever the interviewer steers.
Full sample answer (fictional example)
I'd go in order. The browser checks its caches, then asks DNS for the domain's IP address. It opens a TCP connection and, for HTTPS, a TLS handshake to agree encryption. Then it sends the HTTP request, which usually reaches a CDN or load balancer first. That passes it to an application server, which may check a cache and query a database before returning HTML. The browser parses the page, fetches scripts, styles and images, and renders. I can go deeper on any step, such as DNS caching or what changes with HTTP/3.
13.How do you choose between a relational and a NoSQL database?
What they're really asking: Do you choose storage from access patterns, or from habit?
Answer outline
- Start from the data's shape, the queries and the consistency each one needs.
- Relational: joins, transactions, constraints. Document or key-value: flexible schemas, easy horizontal scaling.
- Then the operational side: backups, migrations and what the team already runs well.
Full sample answer (fictional example)
I start from the queries, not the brand. If the data has relationships and I need joins, transactions and constraints, I'd use a relational database like Postgres, which covers most products for a long time. If I'm storing huge volumes of simple records looked up by key, such as sessions or events, or the shape varies a lot, a key-value or document store can fit better and scales out more easily. I'd also ask what the team already runs well, because backups, migrations and on-call matter as much as features.
14.What is the time and space complexity of your solution, and can you improve it?
What they're really asking: Asked after most coding answers: do you know what your own code costs?
Answer outline
- State the worst-case Big O and the input that drives it.
- Name the bottleneck and the structure that removes it, such as a hash map.
- Mention the trade-off, often memory for speed.
15.What makes code easy to change six months later?
What they're really asking: Engineering judgement: naming, boundaries, tests and care for the next reader.
Answer outline
- Small units with clear names, behind narrow interfaces.
- Tests that pin behaviour, not implementation, so refactoring stays safe.
- A real example of hard-to-change code, and what you did about it.
16.How do you review a pull request?
What they're really asking: Do your reviews catch real problems and help the author?
Answer outline
- Read the ticket, then check correctness, edge cases, tests and security.
- Leave formatting to tools, and separate blockers from suggestions.
- Ask questions rather than give orders, and approve good changes quickly.
17.What's the difference between concurrency and parallelism, and what bugs does shared state cause?
What they're really asking: Fundamentals that bite in production: race conditions and deadlocks.
Answer outline
- Concurrency is juggling many tasks; parallelism is running them at the same instant.
- Shared mutable state causes races, and careless locking causes deadlocks.
- Fixes: a consistent lock order, immutable data, message passing, atomics. Give a real case.
18.What is the difference between a process and a thread?
What they're really asking: Operating system basics that explain real concurrency bugs.
Answer outline
- A process has its own memory; threads in a process share it.
- Shared memory is why threads need locks and can crash each other.
- Processes cost more to start but isolate failures.
19.How does a hash map work, and what happens when two keys collide?
What they're really asking: Do you know the structure behind a daily tool, and its worst case?
Answer outline
- A hash function maps the key to an array index: constant time on average.
- Collisions use chaining or probing for the next free slot.
- A full table resizes; poor hashing drifts towards linear lookups.
20.Where would you add a cache, and what can go wrong?
What they're really asking: Do you treat caching as a trade-off against freshness?
Answer outline
- Cache what is read often and rarely changes.
- Choose an expiry or invalidation rule on purpose; stale data is the main risk.
- Plan for a cold cache after restarts, and measure the hit rate.
Full sample answer (fictional example)
I'd cache things read often and changed rarely: product listings, permission lookups, the result of an expensive query. The main risk is stale data, so I decide up front how stale is acceptable and choose either a short expiry or explicit invalidation when the source changes. I'd also think about the first requests after a restart, when the cache is empty and the database takes the full load; a warm-up or request coalescing helps. Then I'd measure hit rate before and after, because a cache with a low hit rate only adds complexity.
21.How would you design a notification system for email, push and SMS?
What they're really asking: A second design question: can you split producers from delivery?
Answer outline
- Clarify volume, delivery guarantees and user preferences such as opt-outs.
- Services publish events; per-channel workers call providers and record results.
- Add retries with backoff, deduplication keys and a dead-letter queue.
22.How do you decide whether a change is safe to ship?
What they're really asking: Your release judgement: evidence, blast radius and a way back.
Answer outline
- Check what the change touches and what the tests cover.
- Shrink the blast radius with a feature flag or canary release.
- Know the rollback first, and name the metric that triggers it.
Take-home or live exercise: tips
Loops often include a 45 to 60 minute live coding round, or a take-home project sized for a few hours.
- Spend five minutes restating the problem and agreeing edge cases; most failed rounds start with a misread question.
- Get a plain working solution first, then improve it, and state the complexity unprompted.
- For a take-home, add a README covering how to run it and what you left out, with readable commits.
Skills employers test for
Technical rounds follow the job ad. These skills are named most often in the 453 newest software engineer job ads we analysed (out of 15,909 live postings), shown as the share of ads that mention each. Expect questions on the top few.
- 1Python48%
- 2CI/CD36%
- 3Code review32%
- 4AWS31%
- 5Kubernetes29%
- 6TypeScript26%
- 7Distributed systems26%
- 8Java25%
Full list: Software Engineer resume keywords.
From live job ads · computed November 2, 2026 · refreshed daily
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.Halfway through a two-week task, you realise it will take five. What do you do?
What they're really asking: Do you raise bad news early, with options?
Answer outline
- Tell your lead now, with the reason and a new estimate.
- Offer options: a smaller first version, more help or a later date.
- Next time, spike the unknowns before estimating.
Full sample answer (fictional example)
I'd tell my lead the same day, not at the deadline. I'd say what I found, for example that the data model needs a migration I hadn't known about, and give a new estimate as a range. Then I'd bring options: ship a smaller first version in two weeks that covers the main case, add a second engineer for the migration, or move the date. The lead and product owner choose. Afterwards I'd write down what I missed, so next time I spike the unknowns before I estimate.
24.A product manager wants a feature you think will hurt reliability. How do you respond?
What they're really asking: Can you push back with evidence and still serve the goal?
Answer outline
- Ask what problem it solves; a safer route may exist.
- Explain the risk in business terms: outages, support load, slower future work.
- Offer a rollout behind a feature flag, then accept an informed decision.
25.You join a team whose main service has no tests. Where do you start?
What they're really asking: Can you improve messy code without stopping delivery?
Answer outline
- Test the code you're about to change, starting with its current behaviour.
- Cover the riskiest paths early: payments, authentication, data writes.
- Make tests part of every change, not a separate project.
26.An alert fires at night for a service you've never touched. What do you do?
What they're really asking: Calm incident handling, and knowing when to escalate.
Answer outline
- Check the dashboards, recent deploys and the runbook.
- Mitigate first (roll back, scale up, fail over), diagnose later.
- Page the owning team early and keep a written timeline.
27.A senior colleague's pull request has a serious design flaw. What do you do?
What they're really asking: Can you give honest feedback upwards without a status contest?
Answer outline
- Read it fully, then ask a question about the part that worries you.
- Describe the failure it allows and offer an alternative, not a verdict.
- If you still disagree, involve the tech lead and respect the outcome.
28.Two teams both need your help this sprint, and both say it's urgent. How do you decide?
What they're really asking: Do you prioritise openly, or quietly let someone down?
Answer outline
- Ask what happens to each if the work slips a week.
- Take the trade-off to your manager rather than deciding alone.
- Tell both teams the plan, and offer smaller help to the loser.
29.You find a security hole in code you merged last month. What do you do?
What they're really asking: Honesty and speed when you caused the problem.
Answer outline
- Report it at once to the security contact or your lead.
- Check logs for signs of use and work out the data in reach.
- Ship the fix with a test, then write a blameless note.
Full sample answer (fictional example)
I'd tell my lead and the security contact straight away, with the commit, what it exposes and since when. I wouldn't fix it quietly first. Then I'd check the logs to see whether anyone used it, and which data was in reach. In parallel I'd write the fix with a test that fails without it, and get it reviewed fast. After deployment I'd write a short blameless note: how it passed review, and which check would have caught it, such as a lint rule. If customer data was exposed, the security team decides on notification.
30.The deadline can't move, but the requirements keep growing. What do you do?
What they're really asking: Do you negotiate scope openly instead of failing quietly?
Answer outline
- Write down the scope and the cost of each addition.
- Ask the product owner to trade: each new item displaces one.
- Ship the core end to end, and keep a visible deferred list.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Saying 'we' for every part of a story.
Name your own piece: 'I wrote the retry logic; the team agreed the schema.' Interviewers hire you, not the team.
Blaming a teammate, product manager or 'legacy code'.
Say what you would do differently. Even when the cause was outside your control, the lesson is yours to give.
Writing code before asking a single question.
Restate the problem and ask about size, inputs and edge cases first; managers want that habit.
A 'failure' that is really a strength, like working too hard.
Choose a genuine mistake with a real cost, and show the safeguard you built afterwards.
How to prepare for a software engineer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: Map the job ad
Highlight the stack and responsibilities, list the five likeliest topics, and rate your confidence in each.
Day 2: Data structures
Solve three problems in a plain editor: hash maps, trees or graphs, sorting. Say the complexity aloud.
Day 3: One full design
Run the URL shortener from requirements to failure modes in 35 minutes, drawing the boxes by hand.
Day 4: Write five stories
One card each: a hard build, a bug, a disagreement, a failure, helping a teammate. Add a real number.
Day 5: Reread your projects
For each project on your CV, write two likely questions and your answers, including what you'd change.
Day 6: Mock interview
Have a friend run 45 minutes: one coding problem, one design, two behavioural. Review the recording for rambling.
Day 7: Setup and rest
Test your internet, editor link and camera, read the engineering blog, pick three questions to ask, then sleep.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- How do feature work, maintenance and on-call split in a typical week?
- How long does a merged change take to reach production?
- What's the biggest piece of technical debt, and is there a plan for it?
- How much say do engineers have in what gets built?
- What should I have shipped by the end of my first three months?
Preparation tips
- Practise coding out loud in a plain editor; your reasoning is scored, not only the code.
- Revise the core data structures and when each fits, rather than memorising solutions.
- Use one system design routine: requirements, rough numbers, design, deep dive, failure modes.
- Prepare two CV projects you can discuss for 20 minutes each, including what went wrong.
- Skim the company's engineering blog for their stack and the problems they write about.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for software engineer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
The live skills section is based on 453 software engineer job ads analysed, the newest we track, with the same deterministic skill matcher as our in-demand skills report: no AI model reads the postings. It was last computed on November 2, 2026 and refreshes daily.
Last reviewed on November 1, 2026.