Software Engineer mock interview
Answer common software engineer interview questions out loud, from “Tell me about yourself” to debugging and design trade-offs, then get feedback on what you said.
- Free, no account
- Answer by voice or by typing
- About 10 minutes
What they assess
What Software Engineer interviews look for
Problem solving
How you break an unfamiliar problem down, what you ask before you start, and whether you check your own work. The reasoning counts as much as the answer.
Technical depth
Whether you understand the tools you list: why you chose them, what went wrong with them, and what you’d do differently.
Code quality and ownership
Testing, code review, and what you do after the code ships: monitoring, fixing what broke, and cleaning up after yourself.
Collaboration
Working with product managers, designers and other engineers: disagreeing well, explaining technical constraints plainly, and asking for help early.
Learning and judgement
How you pick up a new codebase or language, and how you balance doing it properly against shipping on time.
Questions
8 common Software Engineer interview questions, and how to answer them
- Opening
Tell me about yourself.
What they’re looking for: A two-minute summary of the kind of engineer you are: the stack you work in, the scale of what you build, and one piece of work you’re proud of.
How to answer: Start with your current role and what you build. Give one project with a concrete result (users, latency, reliability, time saved). Finish with why this team’s work is the next step.
- Behavioural
Tell me about a project you’re proud of. What was your part in it?
What they’re looking for: Ownership and technical judgement: what you personally designed or built, the trade-offs you made, and a result you can measure.
How to answer: Set up the problem in a sentence or two, then spend most of the answer on your decisions and why you made them. End with the result and one thing you’d change now.
- Behavioural
Tell me about the hardest bug you’ve fixed.
What they’re looking for: A methodical approach: how you reproduced it, narrowed it down, confirmed the cause, and stopped it happening again.
How to answer: Describe the symptom and why it mattered. Walk through the steps you took to find the cause, including the dead ends. Finish with the fix and what you added so it can’t come back (a test, an alert, a guard).
- Behavioural
Tell me about a time you disagreed with a technical decision.
What they’re looking for: That you can push back with evidence, listen, and commit to the outcome, even when the decision doesn’t go your way.
How to answer: Say what was proposed and what worried you. Explain how you made your case (data, a prototype, a written proposal) and how it was decided. End with the outcome and what you learned about the other view.
- Role-specific
How do you make sure your code is ready to ship?
What they’re looking for: A real routine rather than a slogan: the tests you write, how you use code review, and how you check it works in production.
How to answer: Describe what you do before opening a pull request, what you expect from review, and how you roll out and watch a change. Use a recent change as the example.
- Role-specific
How would you design a URL shortener?
What they’re looking for: Structured thinking out loud: clarifying requirements, a simple design first, then scale, storage and failure cases.
How to answer: Ask about scale and requirements first. Sketch the simplest design (an API, a way to generate short codes, a key-value store), then discuss caching, collisions, analytics and what happens when a component fails.
- Behavioural
Tell me about a time you had to learn a new technology quickly.
What they’re looking for: How you learn under time pressure: what you read first, who you asked, and how quickly you were contributing.
How to answer: Name the technology and the deadline. Describe your approach to learning it and the first thing you shipped with it. Finish with how long it took and what you’d tell someone else learning it.
- Motivation
Why do you want to work here?
What they’re looking for: That you understand the product and the engineering problems behind it, and that your experience fits them.
How to answer: Name something specific about the product or the engineering team (a public talk, blog post, open-source project or the product itself). Connect it to work you’ve done and what you want to do next.
More Software Engineer interview questions to practise
- Walk me through your resume, focusing on your technical work.Opening
- Why are you looking to leave your current role?Motivation
- What kind of engineering team do you do your best work in?Motivation
- Tell me about a time you missed a deadline. What happened?Behavioural
- Tell me about a time you received tough feedback in a code review.Behavioural
- Tell me about a time you improved the performance of a system.Behavioural
- Tell me about a production incident you were involved in. What did you do?Behavioural
- Tell me about a time you mentored or helped another engineer.Behavioural
- How do you decide when to refactor code and when to leave it alone?Role-specific
- How do you approach working in a large codebase you didn’t write?Role-specific
- What’s your approach to testing? What do you test, and what don’t you?Role-specific
- How would you explain a technical trade-off to a non-technical product manager?Role-specific
- What happens when you type a URL into a browser and press enter?Role-specific
- How do you balance technical debt against shipping new features?Role-specific
- Which technology in your current stack would you replace, and why?Role-specific
- What questions do you have about how the team works?Closing
All 24 questions on this page are in the practice above; each round picks five.
Mistakes to avoid
- Saying “we” for the whole project, so the interviewer can’t tell which parts you built or decided.
- Jumping into a design or coding answer without asking a single clarifying question.
- Listing technologies without saying why you chose them or what problem they solved.
- Describing a bug or incident without the result: how it was fixed, and what stops it happening again.
Questions
About Software Engineer interviews
How the practice works and what happens to your answers: about this mock interview.
What is a software engineer interview usually like?
Most include a recruiter call, one or more technical rounds (coding, and often system design for mid-level and senior roles), and a behavioural round about past projects and teamwork. This practice covers the spoken parts: behavioural questions and talking through technical decisions.
Do I need STAR answers for a technical role?
Yes, for any “Tell me about a time” question. Engineers often spend too long on the technical situation and too little on what they did and what changed. Keep the setup to two sentences and finish with a result you can measure.
How should I practise system design questions out loud?
Say your reasoning as you go: the requirements you’re assuming, the simplest design that works, then how it scales and fails. Interviewers score the thinking they can hear, so practising aloud matters more than for most questions.