Tell me about yourself.

This is the warm-up, but it filters more candidates than people realise. The interviewer wants a 90-second professional arc, not your CV read aloud. Strong answers go: current role and stack, one signature shipped project with measurable impact, why you are interviewing now. Weak answers ramble through every job since university or open with personal life. The kill-shot mistake is starting with "I was born in..." or listing technologies without context. In my placements, the engineers who progress always anchor on outcomes (cut latency by 40 percent, shipped the payments rewrite) rather than tasks. Rehearse it out loud. Anything over two minutes signals you cannot prioritise.

Why are you interested in this role?

The panel is checking whether you researched them or sent the same answer to fifteen companies. They want one specific thing about the product, the engineering culture or the technical problem that drew you in. Strong candidates reference a recent blog post, a public repository, or a problem the company has talked about at a meet-up. Weak candidates say "I love your mission" or "the tech stack is exciting". The kill-shot is naming a competitor by mistake. I tell every engineer I place to spend 30 minutes on the company's engineering blog before the call. It is the cheapest interview prep there is.

Walk me through how you would design a URL shortener.

System design is where mid-to-senior offers are won or lost. The interviewer is testing structured thinking, not memorisation. They want you to clarify requirements first (read-write ratio, scale, custom URLs, analytics), sketch the API, then move to data model, storage choice, hashing strategy and caching. Strong candidates think out loud and call out trade-offs (base62 vs hash collision handling, SQL vs NoSQL). Weak candidates jump straight to a Redis answer. The kill-shot mistake is not asking a single clarifying question. In my experience, panels score the journey, not the final diagram. Spend the first five minutes on requirements, always.

Describe how you approach debugging a production issue you have never seen before.

This question separates engineers who can reason from engineers who only pattern-match. The panel wants to hear a method: reproduce, isolate, form a hypothesis, test it, fix, verify, document. Strong answers reference logs, metrics, distributed tracing and rollback discipline. They mention reading the error message carefully (sounds obvious, often skipped). Weak answers go straight to "I would Google it" or "I would ask a senior". The kill-shot is admitting you would push a fix without reproducing the bug. I have seen brilliant coders fail this round because they could not articulate a process. Practise telling a real war story with the steps in order.

How do you approach code review, both giving and receiving?

Hiring managers ask this to filter out the engineer who is technically strong but corrosive in a team. They want maturity. Strong answers cover: focus on the code not the person, ask questions instead of issuing commands, prioritise feedback (correctness, then design, then style), and accept that style is subjective. On receiving, they want to hear that you do not take it personally and you push back with reasoning when you disagree. The kill-shot is saying "I rarely get feedback" or telling a story where you were clearly the difficult one. Senior engineers who review well get promoted faster. Panels know this.

Tell me about a time you disagreed with a teammate on a technical decision.

Pure behavioural, scored on STAR. The panel is checking whether you can hold a position without burning a bridge. Strong answers describe a specific decision (database choice, framework, deployment approach), explain both sides fairly, walk through how you reached resolution (data, prototype, deferring to the person closer to the problem) and end with what happened. Weak answers either show you always conceded or never did. The kill-shot mistake is bad-mouthing the colleague or describing a disagreement you never resolved. I coach candidates to pick a story where they lost the argument but the outcome was good. Shows humility and judgement.

Tell me about a project that failed and what you learned.

This is the question that exposes self-awareness, and most candidates fumble it. The panel is not interested in fake-failure answers ("I worked too hard"). They want a real shipped or shipped-late project that did not hit its goal, and your honest reflection. Strong answers own a specific decision (pushed back too late on scope, under-tested an edge case, picked the wrong abstraction) and explain what you do differently now. Weak answers blame the PM, the deadline or the spec. The kill-shot is claiming you have never had a project fail. Twelve years in, I have never met an honest engineer who has not. Pretending otherwise reads as inexperience.

Describe a time you had to learn a new technology quickly.

Tests adaptability and learning style. The panel wants a concrete example with a deadline pressure: a new framework for a client, a language change after acquisition, an unfamiliar database. Strong answers describe how you broke the learning into chunks (official docs first, then a small spike, then production code with tight reviews). They name the resources used and quantify the timeline. Weak answers stay vague ("I learn quickly"). The kill-shot mistake is claiming you mastered something complex in days. Senior engineers know real fluency takes months. Show that you got productive fast and kept learning. That is the realistic, hireable answer.

Why do you want to work for our company specifically?

Distinct from "why this role". This is the loyalty filter. The panel wants to know if you will accept a counter-offer two weeks in. Strong answers reference the company's stage, mission, engineering reputation, or a specific person you want to work with. They tie the company to your career trajectory. Weak answers list perks ("hybrid working, good salary") which signals you will leave for any better offer. The kill-shot is confusing them with another company in your pipeline. I have watched candidates get rejected from £130k roles for this. Five minutes on the careers page and the founder's LinkedIn prevents it entirely.

What does good engineering culture look like to you?

Culture-fit question, but technical underneath. The panel is testing whether your expectations match how they actually work. Strong answers cover psychological safety (asking dumb questions is fine), code review norms, on-call discipline, blameless postmortems, learning budgets and shipping cadence. They give two or three concrete things, not a manifesto. Weak answers stay abstract ("collaborative, innovative"). The kill-shot is describing a culture that obviously contradicts how the company works (asking about flat hierarchy at a hierarchical bank). Mirror the language from their job ad and engineering blog. If you genuinely cannot live with their culture, better to find out in interview than three months in.

Where do you see yourself in three years?

The panel is checking whether your trajectory fits the role they are filling. They do not want to hire a senior engineer who wants to be a manager in eighteen months if there is no path. Strong answers acknowledge ambition without being prescriptive: deeper technical mastery in a specific area, more scope, optionally a tech lead path. Weak answers say "I want your job" (presumptuous) or "I have not thought about it" (no ambition). The kill-shot mistake is naming a job title at a different company. Pitch a direction, not a destination. Hiring managers want engineers who will grow with them for at least two years.

Do you have any questions for us?

Never close with "no, you covered everything". I lose offers for candidates over this every quarter. The panel reads silence as low interest. Strong candidates ask two or three sharp questions: what does success look like in the first 90 days, what is the biggest technical challenge the team faces right now, how does the team handle disagreements on architecture. Weak candidates ask about salary, holidays or remote policy in the first round (save it for HR). The kill-shot is asking something answered on the careers page. Prepare five questions. Pick the two that fit the conversation. It is the easiest scoring round and most candidates waste it.

Interview Q's · Tech · UK 2026

Software Engineer Interview Questions UK

I have placed software engineers across UK fintech, scale-ups and enterprise teams for twelve years, and the interview pattern in 2026 is sharper than ever. London salary bands have flattened for mid-level, so hiring managers compensate by raising the technical bar. Expect a coding screen, a system design round, behavioural interviews and at least one team-fit conversation. The questions below are the ones I see kill candidates most often. I have written the answers from the recruiter's side, telling you what the panel is actually testing for, what a strong response looks like and what mistake immediately ends the conversation.

By Alex · 12-year UK recruiter · 12 questions + recruiter answers

Question 1

Tell me about yourself.

This is the warm-up, but it filters more candidates than people realise. The interviewer wants a 90-second professional arc, not your CV read aloud. Strong answers go: current role and stack, one signature shipped project with measurable impact, why you are interviewing now. Weak answers ramble through every job since university or open with personal life. The kill-shot mistake is starting with "I was born in..." or listing technologies without context. In my placements, the engineers who progress always anchor on outcomes (cut latency by 40 percent, shipped the payments rewrite) rather than tasks. Rehearse it out loud. Anything over two minutes signals you cannot prioritise.
Question 2

Why are you interested in this role?

The panel is checking whether you researched them or sent the same answer to fifteen companies. They want one specific thing about the product, the engineering culture or the technical problem that drew you in. Strong candidates reference a recent blog post, a public repository, or a problem the company has talked about at a meet-up. Weak candidates say "I love your mission" or "the tech stack is exciting". The kill-shot is naming a competitor by mistake. I tell every engineer I place to spend 30 minutes on the company's engineering blog before the call. It is the cheapest interview prep there is.
Question 3

Walk me through how you would design a URL shortener.

System design is where mid-to-senior offers are won or lost. The interviewer is testing structured thinking, not memorisation. They want you to clarify requirements first (read-write ratio, scale, custom URLs, analytics), sketch the API, then move to data model, storage choice, hashing strategy and caching. Strong candidates think out loud and call out trade-offs (base62 vs hash collision handling, SQL vs NoSQL). Weak candidates jump straight to a Redis answer. The kill-shot mistake is not asking a single clarifying question. In my experience, panels score the journey, not the final diagram. Spend the first five minutes on requirements, always.
Question 4

Describe how you approach debugging a production issue you have never seen before.

This question separates engineers who can reason from engineers who only pattern-match. The panel wants to hear a method: reproduce, isolate, form a hypothesis, test it, fix, verify, document. Strong answers reference logs, metrics, distributed tracing and rollback discipline. They mention reading the error message carefully (sounds obvious, often skipped). Weak answers go straight to "I would Google it" or "I would ask a senior". The kill-shot is admitting you would push a fix without reproducing the bug. I have seen brilliant coders fail this round because they could not articulate a process. Practise telling a real war story with the steps in order.
Question 5

How do you approach code review, both giving and receiving?

Hiring managers ask this to filter out the engineer who is technically strong but corrosive in a team. They want maturity. Strong answers cover: focus on the code not the person, ask questions instead of issuing commands, prioritise feedback (correctness, then design, then style), and accept that style is subjective. On receiving, they want to hear that you do not take it personally and you push back with reasoning when you disagree. The kill-shot is saying "I rarely get feedback" or telling a story where you were clearly the difficult one. Senior engineers who review well get promoted faster. Panels know this.
Question 6

Tell me about a time you disagreed with a teammate on a technical decision.

Pure behavioural, scored on STAR. The panel is checking whether you can hold a position without burning a bridge. Strong answers describe a specific decision (database choice, framework, deployment approach), explain both sides fairly, walk through how you reached resolution (data, prototype, deferring to the person closer to the problem) and end with what happened. Weak answers either show you always conceded or never did. The kill-shot mistake is bad-mouthing the colleague or describing a disagreement you never resolved. I coach candidates to pick a story where they lost the argument but the outcome was good. Shows humility and judgement.
Question 7

Tell me about a project that failed and what you learned.

This is the question that exposes self-awareness, and most candidates fumble it. The panel is not interested in fake-failure answers ("I worked too hard"). They want a real shipped or shipped-late project that did not hit its goal, and your honest reflection. Strong answers own a specific decision (pushed back too late on scope, under-tested an edge case, picked the wrong abstraction) and explain what you do differently now. Weak answers blame the PM, the deadline or the spec. The kill-shot is claiming you have never had a project fail. Twelve years in, I have never met an honest engineer who has not. Pretending otherwise reads as inexperience.
Question 8

Describe a time you had to learn a new technology quickly.

Tests adaptability and learning style. The panel wants a concrete example with a deadline pressure: a new framework for a client, a language change after acquisition, an unfamiliar database. Strong answers describe how you broke the learning into chunks (official docs first, then a small spike, then production code with tight reviews). They name the resources used and quantify the timeline. Weak answers stay vague ("I learn quickly"). The kill-shot mistake is claiming you mastered something complex in days. Senior engineers know real fluency takes months. Show that you got productive fast and kept learning. That is the realistic, hireable answer.
Question 9

Why do you want to work for our company specifically?

Distinct from "why this role". This is the loyalty filter. The panel wants to know if you will accept a counter-offer two weeks in. Strong answers reference the company's stage, mission, engineering reputation, or a specific person you want to work with. They tie the company to your career trajectory. Weak answers list perks ("hybrid working, good salary") which signals you will leave for any better offer. The kill-shot is confusing them with another company in your pipeline. I have watched candidates get rejected from £130k roles for this. Five minutes on the careers page and the founder's LinkedIn prevents it entirely.
Question 10

What does good engineering culture look like to you?

Culture-fit question, but technical underneath. The panel is testing whether your expectations match how they actually work. Strong answers cover psychological safety (asking dumb questions is fine), code review norms, on-call discipline, blameless postmortems, learning budgets and shipping cadence. They give two or three concrete things, not a manifesto. Weak answers stay abstract ("collaborative, innovative"). The kill-shot is describing a culture that obviously contradicts how the company works (asking about flat hierarchy at a hierarchical bank). Mirror the language from their job ad and engineering blog. If you genuinely cannot live with their culture, better to find out in interview than three months in.
Question 11

Where do you see yourself in three years?

The panel is checking whether your trajectory fits the role they are filling. They do not want to hire a senior engineer who wants to be a manager in eighteen months if there is no path. Strong answers acknowledge ambition without being prescriptive: deeper technical mastery in a specific area, more scope, optionally a tech lead path. Weak answers say "I want your job" (presumptuous) or "I have not thought about it" (no ambition). The kill-shot mistake is naming a job title at a different company. Pitch a direction, not a destination. Hiring managers want engineers who will grow with them for at least two years.
Question 12

Do you have any questions for us?

Never close with "no, you covered everything". I lose offers for candidates over this every quarter. The panel reads silence as low interest. Strong candidates ask two or three sharp questions: what does success look like in the first 90 days, what is the biggest technical challenge the team faces right now, how does the team handle disagreements on architecture. Weak candidates ask about salary, holidays or remote policy in the first round (save it for HR). The kill-shot is asking something answered on the careers page. Prepare five questions. Pick the two that fit the conversation. It is the easiest scoring round and most candidates waste it.

How to use these answers

Treat these answers as the recruiter's side of the table, not a script to memorise. Combine them with the STAR method (Situation, Task, Action, Result) on every behavioural question and write your own examples in a notebook before the interview. The single mistake I see kill more software engineering offers than any other is rambling. If you cannot answer in under 90 seconds, you have not prepared the answer. Time yourself out loud. One more thing: when you do not know something in a technical round, say so, then explain how you would find out. Pretending to know is the fastest way to lose a senior offer in the UK market.