Class Design vs Data Structure LLD: What Changes at Senior Level

Mostly class design, and of a small working component rather than a deep inheritance tree. As of 2026-11-02, TrueInterview's bank holds 391 candidate-reported low-level design questions from 25 big-tech companies; 315 are object-oriented design and 43 are data structures & algorithms. Our take: build stateful components such as a rate limiter or a banking ledger end to end in a real language, and give cache-style data structures a small, deliberate slot instead of equal time.

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.

How do class-design and data-structure prompts compare?

They share a round and a name but test different skills. A class-design prompt hands you a system with actors and rules and asks how its objects divide the work. A data-structure prompt hands you a fixed interface with a complexity target and asks for one class that meets it. Class design is the default; the data-structure prompt is the variant you keep ready.

Hello Interview's guide describes the round as one where you are "asked to design the classes, interfaces, and relationships that make it work" for a system such as an elevator controller or a parking lot. The same guide says object-oriented design and low-level design are one format: "They're the same interview, just a different name". Hello Interview's guide adds that low-level design defines the internal structure of a single component within a larger system.

The bank's subtypes only approximate the two kinds: some cache and algorithm-shaped titles are filed under object-oriented design, as the counting note at the end explains, so read the counts as a strong lean rather than an exact split.

Class design wins on preparation value: it covers the large majority of reported questions, and each session also trains the scoping and extension habits a data-structure prompt rewards. Data structure in a class earns a short, fixed block of practice, sized by your target company, and never more than a fraction of your LLD time.

How can you tell which kind you got in the first minutes?

Listen to the nouns in the prompt. If it names a domain with actors and rules, such as a bank, a payout or a file store, it is class design, and your opening minutes go to scope and entities. If it names operations with a cost bound, such as get, put or getRandom in constant time, it is a data structure, and your opening minutes go to the invariant.

Hello Interview's guide says strong candidates pull out the entities and responsibilities, ask a few clarifying questions to fix scope and frame the problem before writing code. Hello Interview's guide allots about 3 minutes to entities and relationships in its delivery framework. That is the class-design opening, and it costs little to run it on a data-structure prompt as well.

Some prompts sit on the line. The bank files Stripe's Rate Limiter, last reported in an onsite in 2026-10, as object-oriented design. Our take: a rate limiter usually has a per-client sliding window or token bucket at its core, so it is a hybrid. For a hybrid like that, ask the interviewer one question early: should the design optimise the cost of each request, or the ease of adding a new limiting rule later? The answer tells you whether to spend the middle of the round on the window or on the policy interface.

What does the interviewer push on in each kind?

For class design the pressure is change: a new rule, a new type or a second kind of user, and whether your classes absorb it without a rewrite. For a data structure the pressure is the complexity bound first, then a follow-up level, usually concurrency or a different eviction policy. In both, a design you can justify line by line beats one decorated with pattern names.

Class design: entities, scope and change

Hello Interview's guide says interviewers evaluate how you break problems into clear entities with well-defined responsibilities, whether the design can handle change without a complete rewrite, and how clearly you communicate trade-offs. Design Gurus lists two concrete checks: "Each class has one reason to change", and a new type should mean "adding a class, not editing a switch statement". Design Gurus' guide also counts error handling and edge cases, such as empty states or maximum capacity, as part of a solid design.

On patterns, Hello Interview's guide is direct: "At Big Tech, interviewers care more about the reasoning than the vocabulary". It says one or two patterns, or none, is fine in most interviews. The same guide says smaller and mid-size companies in India and Asia ask about patterns more directly.

Our take: name a pattern only after the design has produced it. In a courier-payout prompt, pay rules that change by time window are a natural place for a strategy object; in a banking prompt, a transaction record that can be replayed is where command-style objects appear. Hello Interview's guide calls Strategy probably the most common pattern in LLD interviews, which is a reason to recognise it, not a reason to open with it.

Data structure in a class: the bound, then the follow-up

Design Gurus says the expected LRU cache design is a hash map plus a doubly linked list, so that get and put both run in constant time. That baseline is table stakes. The reported titles in the next section add the follow-up levels: a thread-safe version, a weighted version, a frequency-based version, and debugging an implementation someone else wrote.

Our take: over-prepare the debugging variant. Reading another engineer's pointer updates under time pressure is a different skill from writing your own, and memorised code does not help with it. For the thread-safe follow-up, start with one lock around both operations, explain the contention cost, and only then discuss finer-grained locking.

Which reported questions should you practise first?

Start with the stateful components candidates report most, not the generic elevator-and-parking-lot canon. Leaving aside algorithm-shaped titles, Rate Limiter leads the bank with 33 candidate write-ups from 6 companies. The next four most-linked titles are company-specific: each comes from one or two companies, and each is a working component with state that changes over time.

Design Gurus says LLD interviews "reuse a small set of fewer than twenty problems," and its list starts with elevator system, vending machine and traffic light. The most-linked class-design titles in the bank are working components rather than the elevator and vending-machine opening of Design Gurus' list:

The right-hand column is our reading of what each title demands, not a report of what any interviewer asked. Two titles travel widely: the bank files Durable Key-Value Store Serialization under 9 companies and Rate Limiter under 7. If you only have time for one component, take Rate Limiter, because it carries both a design layer and a data-structure core.

The most-filed data-structure-in-a-class prompts in the bank are cache variants:

Outside caches, Apple's Insert Delete GetRandom O(1) was last reported in a phone screen in 2026-09. Its trick is a hash map from value to array index, with removal done by swapping the last element into the gap. Max Stack, covered in the senior section, is the other one-class data structure worth knowing. The most-reported prompts of this kind cluster around a few cache variants, which keeps this part of your preparation compact.

What we would skip: inheritance-first designs as a template. Design Gurus' guide presents chess as the problem that tests inheritance, with a Piece base class and one subclass per piece type. Hello Interview's guide says modern production systems favor "simple state over deep hierarchies" and advises defaulting to interfaces. Keep the chess shape as a known exception and practise composition everywhere else.

Which companies and rounds lean toward data structures?

The round changes the mix. Every one of the 35 questions reported for an OA is object-oriented design. Phone screens show 93 object-oriented design questions of 120 and 14 data-structure questions. Onsites show 218 of 279 and 35 data-structure questions. None of the OA reports are filed under the data-structure subtype, so cache drills are a lower priority for an OA than for a phone screen or an onsite.

The question totals come from the bank's company counts. A count shows what candidates reported, not how often a company asks, but the spread is still useful for sizing. Coinbase has the largest data-structure share in this table, so keep cache drills in a Coinbase plan. Airbnb has none, so an Airbnb candidate can move that time to components.

Worked example: Airbnb against LinkedIn

Take two candidates. The Airbnb candidate sees Progressive Banking System, reported in Airbnb's OA as recently as 2026-10, and Durable Key-Value Store Serialization, which the bank also files under Airbnb. That plan is two components: a ledger that grows level by level and a store that writes itself to disk and reads itself back.

The LinkedIn candidate sees LRU Cache + Thread-Safe Follow-up, reported in LinkedIn's phone screen in 2026-10. That plan keeps the component work and adds one cache with a locking follow-up before the phone screen. Same interview type, different preparation, which is why the company row should be the first thing you check.

Our take on sizing: for an onsite, plan about six class-design sessions for each data-structure session, which matches the onsite reports, and add one concurrency follow-up. For a phone screen, where the data-structure share is similar, use the same ratio. For an OA, put nearly all of your time into class design.

What changes at senior and staff level?

The round stays and the follow-ups get harder. Candidates who self-reported a senior, staff-plus or manager level link these questions 483 times, against 520 from junior, new-grad or intern levels. Design Gurus says LLD questions can be asked "even of mid-level or entry-level candidates"; the level counts show senior candidates meet them as much.

What shifts is the mix. Concurrency questions draw 21 senior-or-above links against 7 junior-or-below, while data-structure questions lean junior. The senior-heavy titles are stateful and long-lived: Snapshot Social Graph has 20 senior-or-above links against 2 junior-or-below, Durable Key-Value Store Serialization 14 against 2, and Rate Limiter 22 against 11.

Some titles appear only in senior-or-above write-ups: Chat Bot System Refactoring with 9 links, Uber Eats Cart & Pricing Engine with 5, Tagged Command Undo, Command Executor with Execute and Undo and Max Stack with 4 each, and Latency Tracker Percentile, Multi-thread Atomic Counter and Feature Flag SDK with 3 each. Max Stack has 3 links from staff-plus or manager write-ups, the most among the titles the bank lists for that level. Design Gurus says almost every problem has one shared piece of state, and you are expected to find it and say how the race is prevented.

Our take: at senior level the base design is assumed, and the signal comes from four follow-ups.

• Refactoring: in a prompt like Chat Bot System Refactoring, find the seam where a new interface can sit without breaking existing callers.
• Undo: for Command Executor with Execute and Undo, decide what each command stores so it can reverse itself.
• Persistence: for a durable store, say what happens to a half-written record after a crash.
• Concurrency: for a counter or limiter, name the shared state and the cheapest lock that protects it.

Our take on down-leveling: in an LLD round, the level signal sits in the last third. A candidate who finishes the base design with no time for the extension has shown mid-level work, however clean the classes are. If you are interviewing at senior or above, keep the first design deliberately plain so that time remains for the follow-up the interviewer is waiting to ask.

What mistakes cost candidates the round?

Over-building is the mistake Hello Interview's guide singles out: it says "KISS (Keep It Simple) is the most violated principle in LLD interviews", and that candidates over-engineer because they want to show off. The same guide warns against writing code before you understand the problem.

Hello Interview's guide also names a preparation failure: having consumed a lot of material and then stumbling when it is time to apply it. Design Gurus' guide wants patterns used where they fit and "not forced where a plain method would do".

Hello Interview's guide also faults older prep material as either UML-heavy or too academic, such as memorising all 23 Gang of Four patterns. Our take: the fix for all of these is the same. Practise by writing working code against a prompt, out loud and against a clock, rather than reading more solutions. If you have built and extended Rate Limiter once, you can rebuild it in the room; if you have only read five solutions, you rebuild none of them.

Has the mix changed, and does your role matter?

The split between the two kinds has barely moved over four quarters, so you can plan on it. Object-oriented design took 80%, 81%, 80% and 84% of write-up links from 2025-Q4 to 2026-Q3. Data structures & algorithms took between 10% and 16% over the same quarters.

Concurrency fell from 6% of links in 2025-Q4 to 1-2% afterwards, but on link counts of 8, 6, 3 and 5, too few to call a trend. Quarterly link totals mostly reflect how many write-ups were collected, so compare shares rather than totals. The bank is also current: 348 of the 391 questions were last reported within the 12 months before 2026-11-02.

Role shifts the mix more than time does. Machine-learning, AI, research and data-science candidates give data structures & algorithms 21% of their links, against 12% for software engineers. ML-specific components appear too: Weighted Data Batcher with Checkpointing has 5 links from those candidates and 1 from software engineers, and ML Configuration System has 4 and none. If you are interviewing for an ML role, add one more data-structure session and one ML component such as the batcher.

How we counted

The counts come from TrueInterview's database as of 2026-11-02: low-level design questions that candidates described in interview write-ups, filed by company, round, quarter and the candidate's self-reported level and role. These are candidate-reported questions reconstructed for practice, not any company's official question list. A count measures what candidates reported and which write-ups we collected, not how often a company asks a question, and a write-up link count is not the number of interviews held.

Subtypes are assigned per question, and the line between the two kinds is not clean. The bank files some algorithm-shaped titles, such as Number of Islands in a Matrix at Uber and Parallel Courses III at Snowflake, under object-oriented design, so we do not use them as examples of class design. LinkedIn's LRU Cache + Thread-Safe Follow-up is filed the same way, so treat the 43 as the questions filed under the data-structure subtype, not as every cache-style prompt.

FAQ

Is the LRU cache an LLD question or a coding question?

It is both, which is why it causes confusion. Design Gurus lists the LRU cache among common LLD problems, next to the in-memory key-value store and the rate limiter. In an LLD round, the interviewer will expect a clean class with a clear public interface, plus the constant-time internals, and then a follow-up such as thread safety or a weighted eviction rule. In an algorithm round, the internals are the whole task. Prepare it the LLD way and you cover both.

How is low-level design different from system design?

System design is about architecture across services, and low-level design is about the code inside one of them. Hello Interview's guide says system design has no coding and "almost no discussion of classes, methods, or interfaces". Design Gurus describes low-level design as the detailed design and implementation of individual components or modules. If your loop has both rounds, expect boxes and data flow in one and class signatures and working methods in the other.

Do you need to memorise design patterns?

No, but you should recognise a few. Hello Interview's guide says four patterns cover 90% of what candidates encounter, which is that guide's view rather than measured data. The same guide says Strategy is probably the most common pattern, because it tests isolating behaviour that varies. Learn what problem each of a handful of patterns solves, then let one appear when your design needs it. Reciting pattern names without a reason in the design earns little at large US companies.

Will you have to run your code?

Sometimes, and you should practise as if you will. Design Gurus says some companies ask candidates to build the design as a running program instead of a sketch. TrueInterview's catalog also tags Rippling's Logger System object-oriented question as AI-allowed and AI-assisted. Practising with runnable code costs little extra and removes the risk of a round where partial code is not enough.

Do companies use LLD instead of algorithm coding?

Some do. Design Gurus says some companies use LLD questions in place of, or in addition to, algorithm coding questions to assess design skills on a smaller scale. The same source describes the round as closer to a collaborative problem-solving session about how to design code for a feature. Ask your recruiter whether your design slot replaces a coding round, and if it does, treat it as carrying the same weight in your schedule.

Your practice plan

This plan is for someone working full time, over three weeks, with three or four sessions each week.

1. Before you start, find your target company in the table above and size your data-structure block: none for an Airbnb-style mix, a few sessions for a Coinbase-style mix.
2. In the first week, build Rate Limiter end to end in your interview language: clarify scope aloud, name the entities, write runnable code, then add a new limiting rule without rewriting an existing class.
3. Also in the first week, if your loop has an OA, build Progressive Banking System under a timer, finishing each level before reading the next.
4. In the second week, work the components filed under your target company, such as Dasher Payment Model, Snapshot Social Graph, Find Duplicate Files or Durable Key-Value Store Serialization.
5. In the third week, give one session to data-structure insurance with Implement an LRU Cache and Debug an Existing Implementation, and add LRU Cache + Thread-Safe Follow-up only if your target company's reports include cache questions.
6. If you are senior or above, add a follow-up drill to each session with Chat Bot System Refactoring, Command Executor with Execute and Undo or Feature Flag SDK.
7. In every session, keep the first design plain and name a pattern only when the design has already produced it.

Sources

• TrueInterview question bank — object-oriented and low-level design at big-tech companies — counted 2026-11-02
• Low Level Design in a Hurry | Hello Interview Low Level Design — checked 2026-11-02
• How to Prepare for a Low-Level Design Interview | Hello Interview — checked 2026-11-02
• Low-Level Design Interview Questions (The Most Common Ones) — checked 2026-11-02
• Difference Between Low-Level Design and System Design Interview Questions — checked 2026-11-02
• Coding Interview Questions by Company · TrueInterview — checked 2026-11-02

Last reviewed: 2026-11-02.