62 System Design Interview Questions, and Who Asks Them

You rarely know the question in advance, but it is not random. Many prompts are asked at every level: candidates report Ticketmaster and LeetCode at Meta from E4 to E6, and Bitly on Amazon’s senior list. What changes with the level is the depth expected on the same prompt: a complete design with one deep dive at mid-level, two deep dives at senior, and at staff a reason for choosing where to go deep. Some questions do lean one way. Platforms such as object storage, a message queue or a key-value store across regions show up mostly in staff rounds.

Then the company. In the reports we read in October 2026, Meta interviewers drew from a short list that candidates name again and again: LeetCode, an ad click aggregator, a leaderboard, ticket booking. Amazon interviewers were said to pick a problem from their own team’s work. At the AI labs, inference and GPU scheduling questions were showing up beside the classics. Startups tie the question to whatever the team builds.

The interviewer is not checking whether you know the answer. They are watching how you get there: whether you asked before you drew, whether a number changed a decision, whether you named the bottleneck before the fix. A memorised design skips all three, and it shows.

It shows in the order of things. A candidate who says "I’ll add Kafka here" before saying what problem Kafka solves reads as someone reciting. Interviewers who write about the round name this as a top red flag: technologies listed without being understood. Coaching guides on Google, read in October 2026, say its interviewers have grown wary of rehearsed frameworks and push for first principles instead.

It also breaks when the question moves. Interviewers change something partway through on purpose: a hundred times the users, a node that dies, a new rule from the product team. A memorised answer has nowhere to go. A design you reasoned out does: you change the part the new rule touches and say what changed.

So use the list below to learn the shapes, not the answers. Most of these sixty-two are a few patterns in different clothes: a read-heavy service with a cache, a write path that must never double-count, a fan-out problem, a contested resource. Know what makes each shape hard, and you can reason through the one in front of you. For how the 45 minutes run and what the interviewer notes at each stage, read what the interviewer writes down.

Pick one question at your level, set a 45-minute timer, and say every step out loud. Write three things the system must do and three to five targets with numbers before you draw a box. Use one number to choose a component, and say which. Get a working path for every requirement on the board by minute 25. Then go deep in two places, and for each choice say what you gave up.

Then ask someone to push back. A design always looks finished until someone asks what happens at ten times the traffic, or when the database node dies. That is the part you cannot practise alone.

Every question above opens a practice system design interview on Star Interview with that question chosen. Your AI interviewer reads your whiteboard, answers your questions with real numbers, runs two deep dives and changes a constraint partway through. Your report scores the round the way the big loops do and shows the level your design read as.

Preparing for one company? Read the guides to the Meta design round and the Amazon design round.