How to Prep for Multi-Level OOP Simulation OAs in 2026

As of 2026-10-26, TrueInterview's bank holds 28 progressive OOP simulation questions reported at 7 big-tech companies. The most-linked titles are Recipe Manager with 12 write-ups, Meta's Banking System (Progressive OOD) with 10 and In-Memory Database with 9. Prepare by building two to four of the reported systems level by level under a timer, writing only what the current level needs and refactoring before you read the next one.

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.

What is a progressive OOP simulation, and why don't OOP quizzes prepare you for it?

It is one system, such as a bank, a file system or an in-memory database, that you build and then extend across successive levels of a single assessment. All 28 questions in the bank carry the object-oriented design subtype. Of the 28, 1 question was also reported in a phone screen and 1 in an onsite. The set was selected as OA questions, so that count cannot prove the format never appears elsewhere.

Our read: because every question here was reported in an OA, we treat this as an OA skill and prepare it separately from general design-interview prep; the data cannot say how often the format appears in other rounds.

Pages selling OOP tests to employers describe a different product. iMocha's OOP test page says the test may contain multiple-choice and multiple-answer questions, fill-in-the-blanks, whiteboard and audio or video questions, a pseudo-coding platform, coding simulators and true-or-false questions, and it screens for experience with encapsulation, inheritance and polymorphism. TestDome's test "assesses knowledge of OOP concepts such as polymorphism, inheritance, abstraction, encapsulation, as well as software design patterns". TestDome's page also lists work-sample tasks such as analyzing a set of inherited classes and using inversion of control to decouple components. Both pages include some hands-on work, but neither describes one system extended over several levels.

Our take: skip the MCQ drills. Knowing the definition of polymorphism does not rehearse the work these OAs reward, which is adding a feature to your own code without breaking the tests it already passes. Spend your hours implementing a complete reported system end to end in your OA language. We do not describe the contents of individual levels, scoring rules, time limits or platforms here, because the reports behind these counts do not state them reliably; read each prompt's levels on its practice page.

Which companies use the format, and which systems do candidates report?

Coinbase and Anthropic file 10 questions each, Meta 5, Instacart 4, Airbnb 3, and Netflix and Stripe 1 each. A question can be filed under more than one company, so the counts overlap. If your OA is at one of the first three companies, start from the most-linked titles below, then work through the rest of that company's reported questions in the practice bank.

The titles fall into four families: banking and payments, file systems and storage, in-memory databases, and managers of records such as recipes, tasks and grants. One representative per family covers most of the table, so you do not need all eight. Write-up links count candidate reports, not how often a company uses the format, and these are candidate-reported questions reconstructed for practice, not any company's official list.

What each family pushes on, as general engineering knowledge rather than a report of any level's contents:

• Banking and payments. Going by the titles, the state is accounts and balances. The decision that matters is whether a transfer validates both sides before it changes either, so a failed transfer leaves no half-applied balance. Our guess from the title Bank System with Transfer/Accept and Merge, not a reported detail, is that a transfer may sit in a pending state; if a prompt says so, model that pending transfer as its own record.
• File systems and storage. The state is a tree or a map of paths to files. The decisions that matter are how you resolve a path in one place, and, for a versioned system, whether you store each version as a full copy or as a list you can roll back through.
• In-memory databases. The state is records with fields. The decision that matters is how you tell a missing record from a deleted one, since any operation on history or backup would depend on that difference. The bank also files a title named Design In-memory Database with Backup under 2 big-tech companies, with no linked write-ups yet.
• Record managers. The state is a collection of records with lookups. The decision that matters is which index you keep for each query, and how you keep it consistent when a record changes or disappears.

A worked example: suppose your OA is at Anthropic. From the table, start with Recipe Manager and In-Memory Database, which Anthropic shares with Coinbase, then build Bank System with Transfer/Accept and Merge and File Systems. That is four systems, one from each family, which our plan below spreads across three weeks of evenings.

Is the format still in use in 2026?

Yes. 27 of the 28 questions were last reported within the 12 months before 2026-10-26. Recency matters because it tells you the reported list is current enough to use as a syllabus, rather than a record of a format that companies have dropped.

The smaller filers are recent too. Stripe's Payment State Machine (OA) was last reported in 2026-10, Airbnb's Design a Multi-Level In-Memory Cloud Storage Service in 2026-08, and Instacart's In-Memory Key-Value Store in 2026-04. These dates show the format is in use; they do not show that its levels or scoring have changed, so prepare for the format as reported and ignore rumours of a new version.

How should you write level 1 so later levels don't force a rewrite?

Write the smallest set of classes that passes the first level, such as one Account record and one Bank class that owns a dictionary of accounts, and build no hooks for levels you have not read. Martin Fowler's Yagni page on martinfowler.com says the name stands for "You Aren't Gonna Need It", and argues that any abstraction that makes the code for current requirements harder to understand "is presumed guilty". That is the right rule for a timed OA.

Fowler's Yagni page says he does not add fields or methods until he is ready to use them, and that code for a presumptive feature makes software harder to modify and debug. The same martinfowler.com page quotes Jeremy Miller's warning that an extensibility point nobody uses is likely to get in your way. In a progressive OA that cost is concrete: every speculative interface is one more thing to change when the real next level turns out different from the one you imagined.

What to do instead comes from the same essay. Fowler's page says to ask developers to "imagine the refactoring they would have to do later to introduce the capability when it's needed". Do that at the end of each level, in your head, for one minute. You will usually find the later change is small, which is the evidence you need to stop pre-building.

A first-level data model that stays easy to change:

1. One plain record type per entity, such as an account, a file or a database row. Python's documentation says the dataclasses module generates methods such as __init__() and __repr__() for you, which saves typing on records with several fields.
2. One manager class that owns a dictionary from id to record and exposes the level's operations as methods.
3. Immutable records for values that must not change once written, such as a completed transaction. Python's documentation says that with frozen=True, assigning to a field raises an exception, so an accidental mutation fails loudly in your own tests.
4. No base classes, interfaces or plugin points until a second variant actually exists.

Our take: the common advice to design for extensibility up front is backwards for this format. The candidate who over-builds the first level spends the time the later levels needed. The candidate who writes plain code and refactors at each boundary keeps every level fast.

What does a test-first loop per level look like?

List the level's operations and edge cases as tests, make them pass, refactor both new and old code, and only then read the next level. Martin Fowler's test-driven development page on martinfowler.com describes the same three repeated steps, and it starts with "a vital initial step where we write out a list of test cases first".

Writing the test list first has a second benefit in an OA. Fowler's page says that thinking about the test first forces you to think about the interface to the code first. If the prompt specifies method signatures, the test list is where you notice an ambiguous return value before it costs a level.

The step candidates skip is the third one. Fowler writes, "The most common way that I hear to screw up TDD is neglecting the third step." Without that refactor, the same page warns, the result is "a messy aggregation of code fragments". Our inference: in a progressive OA, that mess is the foundation the next level has to build on, which is why a rushed first level tends to hurt most several levels later, when the shortcuts have stacked up.

A per-level loop you can rehearse:

1. Read only the current level. Write one test per operation and one per edge case, such as an unknown id, a duplicate create, a transfer to the same account, an amount larger than the balance or a delete of something already deleted.
2. Write the simplest code that passes those tests.
3. Refactor for five minutes: rename unclear methods, move shared lookups into one helper and delete dead branches.
4. Run every earlier level's tests again, then read the next level.

We do not know how graders weigh passing tests against code structure, and no source we checked states it. Prepare for both: re-run every earlier level's tests after each change, and keep each method to one operation from the prompt.

What should you do when a later level adds a variant?

Move the part that varies into its own small class or function, such as one function per transfer rule, and leave the Account and Bank classes unchanged. If a later level adds a second transfer rule or a second storage policy, a growing chain of conditionals inside your main class is the shape to avoid.

Refactoring.Guru's Strategy page explains why. In the Refactoring.Guru example, each new routing algorithm added to one class doubled the main class's size, and any change to one algorithm affected the whole class, raising the chance of an error in code that already worked. Refactoring.Guru's page says the pattern puts each variant in a separate class and makes them interchangeable, so you can add or modify one without changing the code that uses it. The page recommends it "when your class has a massive conditional statement that switches between different variants of the same algorithm".

Our take: introduce the separate class when the second variant arrives, not before. That is consistent with Fowler's Yagni rule above, and it means the pattern is a refactor you perform at a level boundary, not a design you start with. Do not prepare by memorising a pattern catalogue; prepare by practising this one move on a real system until it takes a few minutes.

Three twists make good practice exercises. They are our guesses from the titles, not reported level contents, so treat them as drills rather than predictions. For a transfer that needs accepting, give the pending transfer its own record and state, and check that balances add up the same before and after every operation. For a merge, write it as one operation that moves balances and history together, so no reader sees an account half-merged. For versions or rollback, keep the version list per file and treat rollback as moving a pointer, which keeps earlier levels' reads unchanged.

How should you pace yourself across levels?

Pace by rule, because we have no reliable data on time limits for these OAs. Finish and test the current level before reading ahead, save a copy that passes every earlier test, and never start the next level with a failing test on screen.

Amazon's published guidance is useful only in part, and only as general habit. It describes Amazon's own SDE OA, and Amazon is not among the companies filing progressive questions in our bank. Its page advises candidates to "set aside up to two hours of uninterrupted time for the OA", and says, "If you get stuck on a problem, move to the next one and revisit questions as needed." It also allows publicly accessible resources such as language documentation and expects candidates to write their own code rather than copy and paste.

Our take: in a progressive simulation, moving on means something narrower. If a later level depends on an operation you have not finished, skipping ahead may not be possible; the equivalent move is to make the tests you can pass green, leave a short comment on the case that fails, and continue with the next operation.

What changes at senior and staff level?

Less than the new-grad reputation suggests. By the levels candidates reported, write-ups link these questions 49 times from junior, new-grad or intern candidates and 22 times from senior, staff-plus or manager candidates. Senior candidates are a minority of the links, but a large one, so do not assume your level exempts you from the format.

Two titles lean senior. Versioned File System is linked from 4 write-ups by senior-or-above candidates. Worker / Employee Grant Management has 3 senior-or-above links, 1 of them staff-plus or manager, against 1 junior link. The most-linked titles are mixed: Recipe Manager has 4 senior-or-above links against 8 junior, In-Memory Database 3 against 6, and Banking System 3 against 7. These are link counts by self-reported level, not counts of people.

Our take: at senior level, the same simple-first discipline matters more. If a human reviews your code, boundaries that survive later levels without speculative layers are the senior signal you can control. Be ready to explain why a responsibility lives in its own class, what invariant each operation preserves and what you deliberately left out. If you are senior and target Anthropic or Netflix, add the two senior-leaning titles to your list.

Down-leveling note (our view): we have no data on how much an OA weighs in a level decision. In our view, scope and judgement are easier to show in the design and behavioral rounds that follow, so use the OA to show clean, passing code and make the case for your level in those later rounds.

How we counted

Counts come from TrueInterview's question bank as of 2026-10-26 and cover questions tagged as progressive OOP online assessment questions and filed under big-tech companies. A question can be filed under several companies and reported in several rounds, so tallies overlap. Write-up links count candidate reports, split by the level each candidate gave, and say nothing about how often a company asks a question.

FAQ

Where can I practise multi-level OOP OA questions?

TrueInterview says it offers a free start with no card needed, and paid plans from $29 billed monthly. Each system in the table links to its practice page; the claims we checked do not say which questions the free start covers, so open the page before you plan around it. It also says every question has a reference solution. Use the reference only after a timed attempt, and compare your level boundaries with it rather than copying its structure.

Do OOP MCQ tests or mock tests help with these OAs?

They help with vocabulary and some hands-on tasks, but less with this format. The iMocha and TestDome tests described earlier mix concept questions with short coding or work-sample tasks, while every reported progressive question is one system that you extend over levels. If you want a refresher, define encapsulation, inheritance, polymorphism and abstraction in your own words once, then return to building the reported systems with tests.

Should I practise in Java, Python or C++?

In our view, speed in a familiar language matters more than language features, so use the language you will write the OA in and are fastest in. In Python, dataclasses keep record types short. In Java, use one record class per entity and a HashMap from id to record inside a single manager class. In C++, use a struct per entity and a std::unordered_map from id to struct, so a new level adds methods rather than new containers.

Is this format only for new grads?

No. The senior section above shows senior-or-above candidates link these questions too, and two titles lean senior. If you are experienced, expect the same format and hold yourself to a higher bar on readable boundaries and stated invariants.

Your practice plan

A three-week plan for someone working full time, built from the reported systems:

1. Week one, first day: pick your target company and choose two systems from the table. For Coinbase or Anthropic, start with Recipe Manager and In-Memory Database; for Meta, start with Banking System (Progressive OOD).
2. Week one, second day: set up a test-first template in your OA language: a test file with one empty test per operation, a dataclass for records and one manager class.
3. Week one, rest of the week: build the first system level by level under a timer, with the test list, simplest pass, five-minute refactor and full re-run at every level. Write down each change that forced you to rewrite earlier code.
4. Week two: build the second system, then start one from a different family. Anthropic candidates add both Bank System with Transfer/Accept and Merge and File Systems, finishing the second one early in week three; Coinbase candidates add Cloud Storage System.
5. Week two, if your OA is elsewhere: build that company's reported system, such as Payment State Machine (OA) for Stripe, In-Memory Key-Value Store for Instacart, Design a Multi-Level In-Memory Cloud Storage Service for Airbnb or Versioned File System for Netflix, plus one in-memory database.
6. Week three, if you are senior: add Worker / Employee Grant Management and practise explaining each class boundary and invariant out loud as you write it.
7. Week three, last two sessions: rebuild your first system from a blank file under the timer, then compare it with your first-week version and your rewrite notes. The notes that repeat are the design habits to fix before the real OA.

Sources

• TrueInterview question bank — progressive OOP online assessment at big-tech companies — counted 2026-10-26
• Object Oriented Programming Test | Candidate Screening — checked 2026-10-26
• OOP and Design Patterns Online Test | TestDome — checked 2026-10-26
• Yagni — checked 2026-10-26
• dataclasses — Data Classes — Python 3.15.2 documentation — checked 2026-10-26
• Test Driven Development — checked 2026-10-26
• Strategy — checked 2026-10-26
• Online assessment prep for SDE roles — checked 2026-10-26
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-26

Last reviewed: 2026-10-26.