Software Engineer Interview Questions UK: 8 Real Questions and What Interviewers Want

Before your Software Engineer interview, it helps to see the questions from the interviewer's side. We have picked eight from our set of 25 and added the reason each one gets asked.

Eight Software Engineer interview questions, and what the interviewer is thinking

1. Can you walk me through how you would design a URL shortening service?

Why they ask: A classic system design question used to assess how you structure requirements, data and scaling.

2. What are the trade-offs between consistency and availability in a distributed system, and how does the CAP theorem apply?

Why they ask: They want to see whether you grasp the fundamentals underpinning modern distributed design.

3. What does a typical week as a software engineer involve, beyond writing code?

Why they ask: Checks you understand the full engineering lifecycle and collaboration expected of mid-level engineers.

4. Explain idempotency and why it matters when designing APIs and message-driven systems.

Why they ask: Distributed systems retry constantly, so idempotency is a core correctness concept.

5. How do database indexes work, and when can they hurt rather than help?

Why they ask: Indexing is the most common lever for performance and a frequent source of mistakes.

6. When would you use a message queue or event streaming platform, and what problems does it introduce?

Why they ask: They test architectural judgement about asynchronous communication.

7. You are paged because latency on a key API has jumped from 200 milliseconds to several seconds. How do you investigate?

Why they ask: A very common on-call scenario testing systematic diagnosis under pressure.

8. Tell me about a design document or technical proposal you wrote and how you got buy-in.

Why they ask: Mid-level engineers are expected to communicate designs and influence decisions.

A sample answer to question 1

Can you walk me through how you would design a URL shortening service?

I'd start by clarifying requirements: expected traffic, whether links expire, custom aliases, analytics. Say we expect a hundred million new links a month and reads outnumbering writes by around a hundred to one. The API is simple: a POST to create and a GET that redirects with a 301 or 302. For generating short codes I'd use a base62 encoding of a unique ID, with IDs allocated in ranges to each application instance from a counter service so there are no collisions or hot spots, rather than hashing the URL and handling clashes. Storage is a key-value pattern, so a store like DynamoDB or Cassandra, or sharded PostgreSQL, works well. Because reads dominate, I'd put a Redis cache and a CDN in front, and use a 302 if we need analytics. Finally I'd cover rate limiting, abuse and malicious URL checks, and monitoring.

Common mistake to avoid: Jumping into technology without requirements; Ignoring abuse and collision handling

Want the rest?

Full model answers, key points and common mistakes for all 25 questions are on the Software Engineer interview questions page. The first five are free, no sign-up needed.