Software Engineer Interview Questions and Answers (With What Hiring Managers Actually Want)

Most software engineer interviews have two halves: the behavioural conversation and the technical round. Candidates obsess over the technical half and wing the behavioural one. That is backwards. Hiring managers often decide on fit during the first ten minutes, then spend the rest of the interview confirming or rejecting that first impression.

This guide covers the questions that come up again and again, with answers that work and, more importantly, the reasoning behind them.

The behavioural questions

"Tell me about a project you're proud of"

This is not an invitation to recite your CV. Pick one project. Spend 30 seconds on the problem, 30 seconds on what you built, and the rest on why it mattered and what you learned.

A strong answer sounds like this:

"I worked on the checkout service at my last company. It handled about 40,000 transactions a day and we had a 2% failure rate that no one had time to fix. I spent two weeks adding proper idempotency keys and a retry queue. The failure rate dropped to 0.3%. The bit I'm proud of is that I wrote it up so the next person didn't have to rediscover why we chose idempotency over a distributed lock."

Note what that answer does: it gives a number, it names the technical decision, and it ends on something you'd actually say to a colleague. No buzzwords.

"Tell me about a time you disagreed with a teammate"

Interviewers ask this to check you can have a technical disagreement without making it personal. The wrong answer is "I've never really disagreed with anyone." The right answer has three parts: what you disagreed on, how you resolved it, and what you learned.

"We disagreed on whether to use a queue or a cron job for syncing data. I wanted the queue, he wanted cron because it was simpler. I wrote up the failure modes of cron under load, he pushed back on operational complexity, and we ended up with a queue with a cron fallback. The thing I learned is that 'simpler' often means 'fewer moving parts at 3am', which is a real argument."

"Describe a bug that was hard to find"

They want to see how you debug, not just that you can. Talk through the hypothesis you formed, the tool you reached for, and the wrong turn you took before the right one. Engineers who admit the wrong turn are trusted more, not less.

The technical questions

"How would you design a URL shortener?"

System design questions reward structure, not the right answer. Walk through it out loud: clarify the requirements and expected scale, sketch the high level components, talk about the storage choice and why, then cover the failure cases. If you get stuck, say what you'd do if you had more time. Silence is worse than a partial answer.

"Write a function to reverse a linked list"

Practice this one until you can do it from memory. Interviewers use it as a baseline. If you stumble on the easy one, they assume the hard ones are worse. The trap is overexplaining. Write the code, then explain it. Narrating every keystroke makes you look nervous.

"What happens when you type a URL into a browser?"

This tests breadth. You don't need to go deep on every layer, but you should be able to name them: DNS resolution, TCP handshake, TLS negotiation, HTTP request, server handling, response, rendering. If you can talk about caching at any of those layers, that is a bonus.

Questions to ask them

Always bring questions. Good ones:

• What does the on-call rotation look like?
• How do decisions get made when engineers disagree?
• What is the last thing the team shipped that you are proud of?

These tell you more about the job than the job description will.

What to avoid

• Don't claim a technology you can't answer a follow-up on.
• Don't badmouth a previous employer, even briefly.
• Don't solve in silence for five minutes. Think out loud.

Before you go in

Run through your two best project stories out loud the night before. Not to memorise them, but to hear how they sound. Most answers fail because they're too long, not because they're wrong.

Want to practise the real thing with instant feedback? Try our mock interview tool, or browse our software engineer CV examples to make sure your CV matches the role first.