Role interview guide
Software engineer interview questions and what to expect
Software engineer interviews usually combine coding (solving a problem out loud, often in a shared editor), computer science fundamentals and a discussion of your projects. For experienced roles, many companies add a system design round and ask how you've handled production issues and trade-offs; for freshers, expect more on data structures, OOP and final-year or internship work.
What candidates commonly report; it varies by employer, level and country. Last reviewed 18 October 2026.
The usual stages
- 1Online coding test or recruiter screen (for campus hiring, often an aptitude and coding test)
- 2One or two coding interviews: solve a problem out loud and discuss its complexity
- 3Computer science fundamentals: data structures, OOP, databases, operating systems and networks
- 4System design or low-level design round (mostly for experienced roles)
- 5Hiring manager or behavioural round on projects, teamwork and ownership
- 6HR round
What interviewers check
- Clarifying the problem before writing code, and thinking out loud
- Choosing a data structure for a reason and stating time and space complexity
- Working, readable code, tested against edge cases you name yourself
- Depth on your own projects: what you built, why, and what you'd change
- Sensible design trade-offs: simplicity, scale, cost and failure
- Owning bugs and mistakes honestly
Behavioral questions
Tell me about the hardest bug you've fixed. How did you track it down?
A good answer covers
- The symptom and why it was hard to reproduce
- How you narrowed it down: logs, a debugger, comparing a working and a broken version
- The root cause, the fix, and the test you added so it couldn't return
Describe a time you disagreed with a teammate about how to build something.
A good answer covers
- Both approaches, described fairly
- How you compared them: data, a quick prototype, a review with others
- What was decided and how you worked together afterwards
Tell me about a time code you wrote caused a problem for users. What did you do?
A good answer covers
- What broke, who was affected, and how you found out
- How you fixed or rolled back quickly and kept people informed
- What you changed in testing or review afterwards
Tell me about a time you had to get productive in an unfamiliar codebase quickly.
A good answer covers
- How you found your way around: entry points, running it locally, asking the right people
- A small first change you made to learn safely
- What you delivered and how long it took
Questions about the job
Walk me through the project you're proudest of. What did you build yourself, and what would you change now?
A good answer covers
- The problem and who it was for, in a sentence
- Your own part, the stack, and one hard technical decision
- What you'd redo with what you know now
Explain the difference between a process and a thread, and when you'd use more than one thread.
A good answer covers
- Processes have separate memory; threads share memory within a process
- Why threads help: waiting on input and output, using several cores
- The cost: race conditions, locks and deadlocks, with an example
How does a hash map work underneath, and when would you choose a different structure?
A good answer covers
- Hashing a key to a bucket, and how collisions are handled
- Constant-time lookups on average, and what makes them slower
- When an ordered structure such as a balanced tree or a sorted array is the better fit
Explain encapsulation, inheritance and polymorphism using an example from code you've written.
A good answer covers
- Each idea in plain words, plus abstraction
- An example from your own project rather than a textbook animal or shape
- When composition is a better choice than inheritance
What happens, step by step, when you type a web address into a browser and press Enter?
A good answer covers
- A DNS lookup, then a TCP connection and a TLS handshake for HTTPS
- The HTTP request, the server's response and the browser rendering the page
- Where caching happens along the way
Your solution works but is too slow for large inputs. How do you go about speeding it up?
A good answer covers
- Finding the repeated work with a complexity estimate rather than guessing
- Typical fixes: a better data structure, sorting first, caching results, avoiding nested loops
- Checking the faster version still handles the edge cases
Talk me through how you'd design a service that lets people share a file through a link that expires.
A good answer covers
- Requirements first: file sizes, how long links last, who can open them, rough traffic
- Files in object storage, link details in a database
- Hard-to-guess links, expiry, cleaning up old files, and what happens under heavy load
How would you design the database tables for an app where students enrol in courses? Which indexes would you add?
A good answer covers
- Tables for students, courses and enrolments, with keys linking them
- Why a many-to-many relationship needs its own table, and normalisation in plain words
- Indexes for the most common lookups, and their cost on writes
Your service became slow in production right after yesterday's release. How do you investigate?
A good answer covers
- Confirming the impact with metrics and checking exactly what changed in the release
- Narrowing it down: database queries, calls to other services, memory or CPU limits
- Rolling back if users are affected, then finding the root cause
How do you decide what to test, and what's the difference between unit and integration tests?
A good answer covers
- Unit tests check one piece in isolation; integration tests check pieces working together
- Testing behaviour and edge cases rather than chasing a coverage number
- An example of a test that caught a bug for you
What are Git branches and pull requests for, and how do you resolve a merge conflict?
A good answer covers
- Branches let work happen in parallel without breaking the main line
- Pull requests for review and automated checks before merging
- Resolving a conflict by understanding both changes, not just picking one side
Motivation and fit
Tell me about yourself and why you want to work as a software engineer.
A good answer covers
- Your education or current role in a sentence or two
- One or two projects or results that show how you build things
- Why this kind of work, and why this team, briefly
Why do you want to join us? What do you know about our product and the engineering behind it?
A good answer covers
- Something specific about the product, its users or its technical challenges
- How your skills or interests match the work the team does
- What you hope to learn or own in your first year
Tips
- Talk while you code: say your approach and its complexity before typing, so the interviewer can steer you early.
- Before saying you're done, run your code by hand on a small example and one edge case: empty input, one element, duplicates.
- Know every line of the projects on your resume; interviewers often pick one and ask why you built it that way.
- In design rounds, spend the first few minutes on requirements and rough scale; they shape every choice after.
- If you're stuck, say what you're trying and ask a focused question; silence is harder to help than a wrong idea.
- Prepare stories about a bug, a disagreement and a deadline; behavioural questions come up in technical loops too.
Practise it out loud
A mock interview asks what software engineer interviews usually test, follows up on your answers and gives you a report. The warm-up is free, needs no account and checks five of these questions as you answer.
About this guide
Written by Orbit from what candidates and interviewers commonly describe for this kind of job. The questions are Orbit's own practice questions, not questions taken from any employer's interviews. Processes change, so check the job post and what your recruiter tells you.