System Design Interview in Four Weeks: A Company-Based Plan

Four weeks is enough to prepare a narrow set of system design problems well while working full time, and problem selection is the lever you control. Forty hours fits about three practice problems worked several times, so choosing those three is the most important decision of the month. Choose them from the problem families candidates report for your target company and round, not from the generic URL-shortener list, and drill one fixed opening on them until it holds under a timer. As of 2026-10-16, TrueInterview holds 475 candidate-reported system design questions from 25 big-tech companies, enough to make that choice company by company.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

Is four weeks enough to prepare for a system design interview?

Four weeks is enough to prepare a narrow set of problems well, and not enough to learn the field. PracHub's four-week guide puts it bluntly: "Four weeks is not enough time to learn distributed systems". That guide budgets ten hours a week, forty hours in total. What it leaves to taste is which problems fill those hours, and that is the part candidate reports can decide.

The target is narrower than it looks. Of the questions in the bank, 399 were last reported within the 12 months before 2026-10-16, so the data describes current loops rather than a 2019 syllabus. Each company's largest families are also distinct enough to steer the choice, even though the top family is often only a tenth to a fifth of that company's design questions. None of this guarantees an offer. If you have never designed or run a service under real load, give yourself longer than a month.

How should you split ten hours a week across the four weeks?

Give each week one job and do not let the jobs blur. Week one reviews building blocks, week two works your three problems slowly, week three repeats the same three on a clock, and week four is mocks. That shape follows PracHub's guide. The difference here is the first evening: spend it choosing your three problems from your target company's reported families, before you open any reading material.

Week one: building blocks, seen through your three problems

Keep PracHub's four topics: load balancing, caching, databases and queues. The change is the lens. If your three include Design Payment System, study databases as transactions, unique constraints and idempotency keys. If they include Design Job Scheduler, study queues as leases, visibility timeouts and retries. If they include Design News Feed, study caching as fan-out on write versus fan-out on read. A building block you cannot attach to one of your three problems is reading, not preparation.

Week two: one slow pass per problem

Work each problem in writing, in the order PracHub's guide gives: "Requirements first, then scale numbers, then the API, then the data model, then the boxes". The same guide observes that most people draw components first, and their designs collapse once someone asks what a row looks like. End each pass by writing down the one deep dive you would prepare, using the last column of the most-linked table below as a starting point. If you have not passed the phone screen yet, make one of the three a prompt that candidates have reported in a screen, using the examples in the phone-screen section.

Week three: the same three, on a clock

PracHub's guide repeats the same three problems under a forty-minute timer, out loud, with the same opening each time. Add two drills that its plan does not have. Once per problem, have a friend or a note card narrow the scope to the API only and follow it. Then finish every timed pass with a deep dive you start without being asked, because that is where senior candidates separate from mid-level ones.

Week four: mocks, then patch the gaps

PracHub's guide reserves week four for mocks, ideally with someone senior enough to interrupt. System Design Handbook's guide suggests a timeboxed 45-minute full mock and recording the session for review. Ask your mock partner to use one prompt you have not practised from the same family as your three. A rehearsed answer that survives an unseen sibling problem is the best evidence that the structure, and not the memory, is doing the work.

Which three problems should you pick for your target company?

Pick one problem from each of your target company's top reported families where the bank has a linked practice page, and fill any gap with a prompt widely filed under that company. Those families differ by company more than generic lists suggest: the top family filed under Meta is ads and recommendation ML, under OpenAI it is LLM and AI infrastructure, and under Amazon it is metrics and logging pipelines. Use the table to find your row, then take the three linked problems.

Read the table by row. A Meta candidate who spends the month on chat and URL shorteners has prepared for families outside Meta's top three and skipped the two at the top. Aced's Meta guide makes a related general point, that candidates who fail the loop often "prepared for the wrong type of question". Reading that type as the company's top problem families is our interpretation of the bank, not Aced's claim. Each linked pick is filed under that company or linked from write-ups at that company, for example Design Hotel Booking System from Meta write-ups and Design News Feed filed under Amazon and Google, and the rows mark the exceptions. Where a top family has no linked practice page here, such as Amazon's maps and delivery or Uber's ride-hailing prompts, choose one from that company's list in the bank.

Which prompts do candidate write-ups link most?

The most-linked prompts are infrastructure problems that recur across companies. Payments, GPU scheduling and serving, job scheduling and team chat sit at the top of the list, and the textbook URL shortener sits far below them. For a company-agnostic drill, that ordering matters more than any reading list, because it tells you which problems are being reported this year.

Our take: Design Job Scheduler is a better general-purpose drill than Design TinyURL. It is filed under 12 companies in the bank, from Robinhood and Airbnb to Meta and OpenAI, while TinyURL is filed under six and linked from far fewer write-ups. A scheduler also exercises queues, leases, failure recovery and fairness in one problem, which is most of week one's material in a single prompt. If you have one slot that is not tied to a company, give it to the scheduler, and give a second free slot to the payment system.

The mix is also shifting toward AI infrastructure. LLM, RAG and AI-infrastructure prompts took 9% of write-up links in 2025-Q4 and 2026-Q1, then 15% in 2026-Q2 and 13% in 2026-Q3. Those are shares, compared because the raw quarterly totals mostly reflect how many write-ups were collected. If your target is an AI lab or a company building on models, one GPU prompt belongs in your three even if your background is plain backend work.

How is the phone screen different from the onsite?

The two rounds draw on different mixes, so plan them separately. The bank has 336 onsite and 162 phone-screen reports for these questions. Phone-screen reports lean toward A/B testing and experiment design (24) and LLM and AI infrastructure (16), with ads and recommendation ML at 16 and metrics pipelines at 10. Onsite reports lean toward ads and recommendation ML (45), LLM and AI infrastructure (28) and booking and inventory (24).

These phone-screen counts are pooled across companies, so treat them as a direction rather than a per-company list. If the screen is still ahead, make one of your three a prompt with a reported screen at a company like yours: Design News Feed at Amazon, Design GPU Inference Serving System at Anthropic, Design Job Scheduler at Robinhood, or Payment / Coffee-Shop Ordering at OpenAI. Keep the booking or ads problem for the onsite. Aced's Meta guide says system design appears in both the technical screen and the onsite at Meta, and that "The onsite system design round goes deeper and carries more weight in the final hiring committee packet". Treat the screen as a gate that rewards a clean, complete pass, and the onsite as the round where depth earns the level.

One caution on experiment design. The bank files 30 A/B testing and experiment-design questions, 24 of them reported in phone screens, yet write-ups almost never link them, so how often they come up in loops is uncertain. Our view: keep the experiment-design slot the table gives Meta, Google and Uber candidates, because those prompts are filed for the screen even if write-ups rarely link them, and treat it as the top priority for data-heavy or ML roles. Practise it from the question bank.

Should ML engineers and backend engineers prepare differently?

Yes, because the two groups report very different mixes, with one shared family. In write-up links, machine-learning, AI, research and data-science candidates go 49% to ads, recommendation and ranking ML against 9% for software engineers, while LLM and AI infrastructure is shared at 18% and 11%. Payments, booking, chat and maps prompts come almost entirely from software engineers, which makes those families the backend engineer's core and AI infrastructure common ground.

Some ML prompts have no software-engineer links at all, such as Short Video Recommendation & Ranking and Design An Online Ads Ranking System. If you are an ML engineer, put one ranking or recommendation design in your three and practise the parts a backend plan skips: candidate generation, the offline metric, the online experiment and the feature freshness budget. If you are a backend engineer, do the reverse and spend no week-one hours on model training.

Is every system design round an end-to-end distributed systems question?

No. Of the 475 reported questions, 256 are distributed systems, 125 are ML system design, 46 are experiment design and 26 are low-level design. Roughly half of the bank is something other than a boxes-and-arrows distributed design, so a plan that only rehearses that format leaves you exposed.

Aced's Meta guide adds that some interviewers scope the round to API design or low-level component design. The same guide reports one recent candidate asked to design an online chess game with distributed design explicitly skipped, which is one candidate's account and not a rule. Aced's guide also warns that "Fighting the constraint or reverting to your rehearsed distributed systems answer is one of the fastest ways to lose points". Design Online Chess Game is a good prompt for the scope-narrowing drill in week three.

What should the opening of a 45-minute round sound like?

Use the same six moves every time: clarify scope, state scale numbers, sketch the API, define one table, draw the request path, and name the bottleneck yourself. Aced describes the Meta round as 45 minutes and advises spending the first five on requirements and scope. The six moves fit inside that window and leave the remaining time for design and depth.

PracHub's guide adds two habits worth keeping: if nobody gives you numbers, assume reasonable ones and say them out loud, and name the bottleneck before anyone asks. Hello Interview's guide says rubrics share four themes: "Problem Navigation, Solution Design, Technical Excellence, and Communication and Collaboration". Aced's guide says interviewers care less about specific choices than about whether you can identify trade-offs, and grade communication as heavily as technical accuracy. Hello Interview's guide lists the failures to avoid: thin requirement gathering, time on trivial parts, ignored scale and memorised answers.

What we'd skip

Skip anything that cannot change what you say in a forty-five-minute conversation about your three problems. PracHub's guide cuts consensus internals and the CAP theorem as philosophy. Keep that cut, and add three of our own: the generic textbook list as a default syllabus, model-training theory if you are a backend engineer, and any fourth problem before the first three survive a timer.

• The generic list as your syllabus. URL shortener, chat and news feed are fine as one slot. As a whole plan they ignore the family at the top of most companies' rows in the table above.
• Older material without a check. Hello Interview's guide says much system design material is still stuck in 2015 relative to modern hardware. Size disks, memory and network with current numbers.
• A memorised "correct" design. Hello Interview's guide says design interviews are not about reaching a single right answer. Spend the hours on the trade-off you will defend.
• New problems in week three. The same three problems, repeated, beat a fourth problem done once.

What changes at senior and staff level?

At senior and staff level the high-level diagram is assumed, and the deep dive carries the level. Write-ups link these design questions 678 times from candidates who self-reported a senior, staff-plus or manager level, against 132 times from junior, new-grad or intern candidates. Among write-ups with a stated level, most come from loops at your level, which is good news for an experienced hire.

Some prompts appear only in senior-or-above write-ups, among them Design GPU Inference Serving System, Design an Ads Frequency Cap System and Design the Data Model for an Ads Demand Platform. Hello Interview's guide describes the difference this way: a senior engineer "will quickly work through the basics leaving time for them to show off the depth of their knowledge in deep dives". The same guide says system design carries disproportionate weight at senior level.

Our take: budget fewer minutes for the first diagram and rehearse one deep dive per problem that you can lead unprompted. For the job scheduler, that is fairness between tenants and what happens when a worker dies mid-job; for the payment system, retries without double charging; for GPU scheduling, preemption and who loses capacity first. Staff candidates should also be ready to explain which requirement they would cut and why, because scope judgement is the signal a staff loop is listening for.

Down-leveling note (our view): the system design round, the project deep dive and behavioral scope carry most of the level signal. In our view, a clean but shallow design pass is how a senior candidate ends up with an offer one level below the one applied for, so the deep-dive drill in week three is the part of this plan you should protect when a week slips.

Worked example: a senior backend engineer interviewing at OpenAI

OpenAI's row points to one GPU prompt, one payments prompt and one chat prompt, so those become the three. Here is how the month runs for that candidate, using prompts that candidates have linked from their write-ups.

1. Drill one: Design GPU Scheduling Platform, linked from write-ups across OpenAI, Anthropic and Databricks. The deep dive is preemption and fair-share quotas between teams.
2. Drill two: Payment / Coffee-Shop Ordering (read the prompt!), a prompt candidates have reported only at OpenAI. The deep dive is the order state machine when a payment fails halfway.
3. Drill three: Design Slack-like Chat System, reported at Airbnb, OpenAI and Databricks. The deep dive is per-channel message ordering and delivery to clients that reconnect.
4. Optional fourth: Design Online Chess Game, linked from 14 OpenAI write-ups. Use it in week four as the unseen sibling prompt, and practise it once scoped to the API only.

Week one reviews the four building blocks against those three problems only. Week two works each one slowly in writing. Week three repeats them on the clock, and week four is mocks, with the chess game as the surprise prompt.

Our take

The textbook list is the wrong syllabus for a four-week plan, because it is chosen for how well it teaches rather than for what your target company's candidates report. Pick from your company's row, give any free slot to the job scheduler, and spend the saved hours on the deep dive.

How we counted

TrueInterview files candidate-reported system design questions by company, round, month and the candidate's self-reported level. Problem families are assigned from question titles, and 41 titles match no family, so family counts are a floor rather than a census. Counts measure what candidates reported and wrote up, not how often a company asks a question, and the questions are reconstructions for practice rather than any company's official list.

FAQ

Is ten hours a week enough for a system design interview?

Ten hours a week for four weeks is enough for three problems worked several times plus mocks, which is the plan above. If you have only about six hours a week, cut to two problems rather than rushing three, and keep both from the top two families for your target company. If you also have coding rounds in the same month, protect the design hours on fixed evenings rather than taking them from what is left.

Can I prepare for a system design interview in four weeks for free?

Yes. The plan needs a whiteboard, a timer, a friend for mocks and a list of prompts. TrueInterview says it is free to start, with paid plans from $29 billed monthly, and that its system design rounds are practised on a whiteboard. Free write-ups and practice pages are enough to pick your three problems; what costs time, not money, is the repetition in weeks two and three.

Should I read a system design book cover to cover in four weeks?

No. A book chapter is useful as a reference for one of your three problems, for example the chapter on a news feed when your target is Google or Amazon. Reading a whole book cover to cover uses most of the forty hours on prompts your company's candidates may never report, and leaves no time for timed repetition or mocks.

When should I start mock interviews?

Start in week four, after each of your three problems has had one slow pass and at least one timed pass. A mock before then mostly tells you what you already know, that the structure is not yet automatic. If you can book only one mock, schedule it about a week before the interview so you still have evenings to fix what it exposes.

Your practice plan

1. Tonight, find your target company's row in the table above and write down three titles. If you do not know the company yet, use Design Job Scheduler, Design Payment System and Design Notification System.
2. Block ten hours a week in your calendar now, and label the weeks: building blocks, slow pass, timed repeats, mocks.
3. Write the six-move opening on one card: scope, scale numbers, API, one table, request path, named bottleneck.
4. If your phone screen is still ahead, swap one slot for a screen-mix prompt, such as Design GPU Inference Serving System for an AI lab or Design News Feed for Amazon.
5. If you are an ML engineer, make one slot a ranking design such as Reels / Short Video Recommendation.
6. For each problem, write the one deep dive you will lead unprompted, and rehearse it at the end of every timed pass in week three.
7. In week four, ask your mock partner for an unseen prompt from the same family, such as Design an Ads Frequency Cap System if your three include an ads problem.

Sources

• TrueInterview question bank — system design at big-tech companies — counted 2026-10-16
• How to prepare for a system design interview in four weeks | PracHub Knowledge Hub — checked 2026-10-16
• How to prepare for system design interviews in 1 week? — checked 2026-10-16
• Meta System Design Interview (2026 Guide) - Aced (formerly Exponent) — checked 2026-10-16
• System Design in a Hurry | Hello Interview System Design in a Hurry — checked 2026-10-16
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-16

Last reviewed: 2026-10-16.