All jobs / Engineering manager / tech lead
Architecture interview questions
Architecture questions a Engineering manager / tech lead can be asked, from first job to senior. Open one to see the strongest answer and why it works.
An interviewer says: “Design a URL shortener.” What do you do first?
The strongest answer: Ask what it must do and at what scale — reads vs writes, expiry, custom aliases, analytics — and state the assumptions you will design against before drawing anything
Why it works: Right. Requirements and numbers first; the boxes follow from them.
- Clarify functional and non-functional requirements first.
- State assumed scale in numbers.
- Only then draw.
- Check assumptions with the interviewer.
What does a load balancer do, and what does it not do?
The strongest answer: It spreads incoming requests across several identical servers and stops sending to ones that fail health checks; it does not make one slow server faster or fix a database bottleneck behind them
Why it works: Right. Distribution and failover, nothing more.
- Distributes requests across servers.
- Removes unhealthy servers.
- Not a cache, not capacity.
- Bottlenecks behind it remain.
What is the difference between scaling up and scaling out?
The strongest answer: Up means a bigger machine — simple, but there is a ceiling and one box to lose; out means more machines behind a balancer, which needs the service to be stateless or to share state elsewhere
Why it works: Right. Up is easy until the ceiling; out needs stateless services.
- Up: bigger box, ceiling, single failure.
- Out: more boxes, needs statelessness.
- Choose by state and ceiling.
- Neither is always right.
Why do interviewers keep asking whether a service is stateless?
The strongest answer: Because a stateless service keeps nothing between requests on its own box, so any instance can serve any request — that is what lets you add instances, replace a dead one and deploy without users noticing
Why it works: Right. Statelessness is what makes scaling out and failover trivial.
- Stateless: nothing kept between requests locally.
- Any instance serves any request.
- State moves to a shared store.
- Enables scale-out and failover.
When does adding a cache help, and when does it not?
The strongest answer: It helps when the same data is read far more often than it changes and a slightly stale answer is acceptable; it does not help write-heavy paths, unique-per-request data, or when staleness is unacceptable
Why it works: Right. Read-heavy, repeated, staleness-tolerant — otherwise it adds complexity for nothing.
- Read-heavy and repeated.
- Staleness must be acceptable.
- Not for writes or unique reads.
- Name what is cached and for how long.
In a design, why do you say which columns are indexed?
The strongest answer: Because the query pattern decides the index: a lookup by short code needs an index on that column or every read scans the table; each index also slows writes and takes space, so you index what you query, not everything
Why it works: Right. Index the lookup paths; pay on writes.
- Index what you look up by.
- Each index costs writes and space.
- Query pattern decides.
- Say the key columns explicitly.
What is a read replica for?
The strongest answer: A copy of the database that receives writes from the primary and serves reads, so read traffic scales out and the primary is left for writes; reads from it can lag slightly behind the primary
Why it works: Right. Reads scale out; expect replication lag.
- Copies primary; serves reads.
- Scales reads, not writes.
- Lag exists.
- Primary stays for writes.
Why would you put a queue between two parts of a system?
The strongest answer: To decouple them: the producer finishes fast and the consumer works at its own pace, spikes are absorbed, and a consumer being down does not lose the work — at the cost of the result arriving later
Why it works: Right. Decoupling and absorbing spikes, paid for in latency.
- Decouples producer and consumer.
- Absorbs spikes.
- Survives consumer outages.
- Result becomes asynchronous.
What is the difference between latency and throughput?
The strongest answer: Latency is how long one request takes; throughput is how many the system handles per second — you can have high throughput with bad latency, and adding servers raises throughput without shortening one request
Why it works: Right. One request's time versus requests per second.
- Latency: time per request.
- Throughput: requests per second.
- They move independently.
- Scaling out helps throughput.
An interviewer asks for p99 latency. What does that mean and why ask for it?
The strongest answer: The time under which 99% of requests finish — it shows the slow tail that averages hide, and the tail is what users on the worst path feel and what times out downstream
Why it works: Right. Tails matter more than averages.
- 99% of requests finish under it.
- Exposes the tail.
- Averages hide outliers.
- Tail drives user experience and timeouts.
How do you estimate storage for 100 million short URLs?
The strongest answer: Pick a per-record size — say a few hundred bytes for the code, the long URL and metadata — multiply, and round: a few hundred bytes times 100 million is tens of gigabytes, so one database handles it and the interesting problem is reads, not storage
Why it works: Right. Rough units, a multiplication, a conclusion.
- Per-record size times count.
- Round to a power of ten.
- Draw a conclusion from it.
- Say what the real constraint is.
What does a CDN do for a web application?
The strongest answer: It serves static files from servers near the user, so images, scripts and styles come from the edge with low latency and the origin only serves what changes
Why it works: Right. Static content at the edge, origin for the rest.
- Static files near the user.
- Lower latency for assets.
- Origin serves dynamic content.
- Cache headers control it.
A penetration test lands two days before launch: one critical finding, three mediums, and a page of low ones.
How do you decide what happens to the launch?
The strongest answer: The critical finding is fixed before launch and the security reviewer agrees it is closed; the rest get an owner and a date, written down and visible to whoever accepts the risk
Why it works: Exactly — what is exploitable now blocks the launch, and everything else becomes owned, dated and visible to the risk owner.
- Exploitable now blocks the launch.
- Rank by severity and exploitability.
- Owner and date for the rest.
- The risk owner must see it.
Your cloud bill has grown quarter on quarter and finance has asked you to explain it.
How do you handle it?
The strongest answer: Make the cost visible to the team by service, set a target with them, fix the biggest waste first, and balance it against the delivery we owe
Why it works: Exactly. Visibility, a shared target, biggest waste first, and a trade-off you own.
- Make cost visible per service.
- Set the target with the team.
- Biggest waste first.
- Do not blame, do not mandate blindly.
How do you decide whether to build or buy a component?
The strongest answer: Whether it is core to what differentiates us, the total cost including operation and lock-in, and whether the team has the capacity to own it well
Why it works: Exactly. Core versus context, whole-life cost, and honest capacity.
- Core or context?
- Total cost, including lock-in.
- Capacity to own it.
- Demos do not decide.
How do you balance reliability work against features?
The strongest answer: Agree service-level objectives with product, and let the error budget decide when reliability work jumps the queue
Why it works: Exactly. Shared objectives make the trade-off a rule instead of a weekly fight.
- SLOs agreed with product.
- Error budget drives priority.
- Not a fixed ritual slice.
- 100% is not a target.
Sales has told a prospect that the platform will handle ten times today’s traffic. The contract is being drafted this week.
What do you do?
The strongest answer: Find out what was promised in writing and by when, load-test the real path against that number, then come back with what holds, what breaks first, and the work and cost to close the gap
Why it works: Right — measure before you answer, then price the gap so the business can decide with real numbers in front of it.
- Measure before you confirm.
- Get the promise in writing.
- Load-test the real path.
- Price the gap honestly.
When does outsourcing engineering work make sense?
The strongest answer: For work outside our core competence, with clear interfaces, retained ownership of the architecture and the decisions, and an exit path
Why it works: Exactly. Non-core, well-bounded, ownership retained, exit possible.
- Outside the core.
- Clear interfaces.
- Keep ownership of decisions.
- Have an exit path.
How do you think about vendor and cloud lock-in at organisation level?
The strongest answer: Decide where lock-in would actually hurt, insulate at those few strategic points, and accept it elsewhere in exchange for speed
Why it works: Exactly. Selective insulation, deliberate acceptance elsewhere.
- Find where lock-in hurts.
- Insulate only there.
- Accept the rest for speed.
- Neither all nor nothing.