Backend Master Interview Preparation Sheet
Your one-page revision guide to crack backend interviews for DSA, System Design, LLD, and tech or leadership rounds.
Use this as your high-yield interview revision page. It is not meant to cover every topic. It is meant to cover the things that repeat across DSA, System Design, LLD, and interview rounds often enough to matter.
Pair it with the main roadmaps, then use the lists below as your last-mile revision checklist. LLD Roadmap , HLD Roadmap , DSA Roadmap
What to prioritize first
DSA first - Prioritize this for internship, fresher, and SDE 1 style interviews where coding rounds dominate.
System Design next - Shift here for SDE 2+, backend, platform, API, and distributed systems roles where scale and tradeoffs matter.
LLD to close gaps - Practice this heavily if the company likes machine coding, object modeling, design patterns, or real-world code structure discussions.
Target Outcome
If you can solve most of the DSA list below, explain major System Design tradeoffs clearly, and walk through 4–5 LLD problems without drifting into vague class dumping, you are already in strong shape for a large number of interviews.
DSA: the patterns that show up again and again
Arrays and hashing
Two pointers
Sliding window
Binary search
Stack and monotonic stack
Queue and heap
Linked list
Trees and graphs
Backtracking
Trie
Dynamic programming
Greedy
25 must-do DSA questions
Arrays, hashing, and sliding window
Find Pair With Sum : Baseline hashing pattern. You should be able to compare brute force, sorting, and hash map approaches cleanly.
Duplicates Within K Distance : Simple but useful for learning set-based windows and sliding constraints.
Rotate Image : Classic in-place matrix manipulation problem that tests index discipline.
3 Sum to Zero : Sorting, duplicate handling, and two-pointer reasoning in one question.
Find All Anagrams : Strong sliding-window frequency-map question that appears in many variants.
Binary search, greedy, and interval thinking
Minimum Window Substring : One of the most important sliding window patterns to master deeply.
Find First and Last Position : Teaches clean boundary-based binary search instead of just “find target”.
Search Rotated Array II : Binary search with ambiguous duplicate cases and branching discipline.
Split Array Largest Sum : Important example of binary search on answer space.
Jump Game II : Greedy range expansion question with very interview-friendly intuition.
Stack, queue, and heap
Balanced Brackets : Basic stack correctness, but still useful for edge cases and clean thinking.
Implement Queue Using Stacks : Tests amortized analysis and data structure simulation.
Largest Rectangle in Histogram : The classic monotonic stack problem.
Task Scheduler: Greedy counting and cooldown reasoning with useful follow-up discussions.
Merge K Sorted Lists : Heap merge pattern that generalizes to many stream-style problems.
Linked list, trees, and graphs
Intersection of Two Linked Lists : Small problem, but excellent for pointer reasoning and explanation quality.
Sort List : Merge sort on linked lists. Common and very reusable.
Diameter of Binary Tree : Bottom-up tree recursion and “answer through child state” thinking.
Construct Tree From Traversals : Recursion plus indexing map. Great for testing tree reconstruction logic.
Count Islands : Core DFS/BFS connected-component foundation problem.
Backtracking, trie, DP, and DSU
Find Redundant Connection : Union-find basics and cycle detection in an elegant format.
Combination Sum : Backtracking template, branching choices, and pruning.
Add and Search Words : Trie plus wildcard branching. Good for pattern-matching structures.
Count Ways to Climb : The cleanest entry point into one-dimensional dynamic programming.
Longest Common Subsequence : One of the essential two-dimensional DP problems.
DSA revision rule
State the brute-force solution first. Interviewers want to know that you can reason from baseline to optimized.
Explain why the optimized structure works. Do not just say “use a map” or “use DP” without the invariant.
Call out time and space complexity clearly. Say it before the interviewer has to ask.
Walk through one edge case. Empty input, duplicates, overflow, off-by-one, or single-element cases usually reveal whether you really understand the solution.
Practice verbalizing while coding. Silent solving does not prepare you for real rounds.
System Design: what actually matters in interviews
Clarify requirements. Separate functional requirements from scale, latency, consistency, and reliability expectations.
Estimate rough scale. Users, QPS, storage, peak traffic, and read/write ratio shape the design.
Define APIs and data model. This forces your design to become concrete early.
Draw high-level components. Client, gateway, services, cache, database, async workers, and storage.
Deep dive into the real bottleneck. Pick the place where the design gets interesting instead of staying generic.
Handle failures and observability. Retries, DLQs, fallback behavior, metrics, logs, tracing, and alerts matter.
End with tradeoffs. Good design interviews end with constraints, not false certainty.
High-yield System Design topics
Back-of-the-Envelope : EstimationPractice quick reasoning about QPS, storage, bandwidth, and latency budgets.
CAP Theorem : Foundational language for distributed tradeoffs.
Consistency Models : Know strong, eventual, causal, and when each is acceptable.
L4 vs L7 Load Balancing : A very common scaling and routing discussion.
Cache Invalidation Strategies : One of the most practical topics in real systems.
Database Replication : Leader-replica basics, lag, and failover thinking.
Database Sharding : When single-node storage stops being enough.
Message Brokers : Queues, fan-out, decoupling, and async workflow design.
Retry and Backoff Strategies : Critical for resilience and client behavior under failure.
Dead Letter Queues : What happens when retries keep failing.
Distributed Tracing : Observability is part of good design, not a side note.
Exactly-Once Payment Processing : Idempotency and correctness under retries.
Multi-Region Design : Latency, failover, routing, and cross-region data decisions.
Disaster Recovery : RPO, RTO, backups, restore testing, and operational realism.
Classic System Design problems you should be ready for
Design a URL Shortener : Hashing, key generation, storage, redirects, hot keys, and analytics.
Design a News Feed : Fan-out, ranking, caching, and read/write tradeoffs.
Design a Notification System : Retries, templates, preferences, rate limits, and delivery guarantees.
Design a Rate Limiter : Fixed window, sliding window, counters, and distributed fairness.
Design a Ticket Booking System : Seat holds, locking, contention, timeout expiry, and payment correctness.
What interviewers want to hear in System Design
Where the data lives. Not just “use a database,” but which store holds which truth.
Where the bottleneck appears first. Cache hot keys, database contention, queue lag, fan-out pressure, or storage throughput.
How reads and writes scale differently. Caches, replicas, queues, batching, or partitioning should come up naturally.
How duplicate work is prevented. Idempotency, dedupe keys, exactly-once semantics, and safe retries matter.
How failures degrade. What happens when a dependency is slow, down, or partially failing.
What tradeoff you are making on purpose. Strong answers are explicit about the cost of simplicity, latency, consistency, or freshness.
Low Level Design: the parts that separate average answers from strong ones
The goal is not to create many classes. The goal is to model the domain cleanly, keep invariants close to where they belong, and leave space for future requirements without collapsing into a God object.
High-yield LLD topics
SOLID in Real World : Know where each principle helps and where over-application makes code worse.
Composition vs Inheritance : Composition should usually be your default.
Encapsulation : Keep invariants inside objects instead of scattering checks.
Abstraction : Expose what matters, hide what changes.
Dependency Injection: Cleaner wiring, easier tests, lower coupling.
Dependency Inversion : Depend on contracts instead of concrete implementations.
Repository Pattern : Separate persistence details from domain behavior.
Service Layer : Coordinate workflows without bloating controllers or entities.
Thread Safety : Essential whenever shared mutable state exists.
Synchronization Primitives : Know locks, semaphores, and coordination basics.
Strategy Pattern : Great when behavior varies cleanly behind an interface.
Observer Pattern : Useful for event-driven updates and decoupled notifications.
Factory Method : Hide creation complexity and keep callers clean.
Decorator Pattern : Extend behavior without subclass explosion.
State Pattern : Perfect when behavior changes with lifecycle stages.
Clean Architecture : Boundaries, use cases, and dependency direction.
Hexagonal Architecture: Ports-and-adapters thinking for clean change boundaries.
Unit Testing : Interview code should be testable even if you do not write every test.
Long Methods and God Classes : Recognize the smell before you produce it.
A strong LLD answer usually includes
Core entities and responsibilities. Every important domain object should have a reason to exist.
Interfaces where behavior varies. Do not hardwire future variation into conditionals if an abstraction is cleaner.
A clear workflow for the main use case. Walk through the request path from input to state change.
A state model when lifecycle matters. Booking, payment, order, and approval flows usually benefit from explicit state thinking.
Validation and invariant ownership. Decide which object is responsible for enforcing correctness.
Concurrency handling. If two users can update shared state, you need a strategy for correctness.
Extension points. Think about how the design evolves when a new rule or variant appears.
Tests you would write first. This reveals whether the design is actually usable.
Classic LLD problems you should practice
Design Parking Lot : Entities, spot assignment, ticketing, pricing, and entry/exit flow.
Design LRU Cache : Hash map + doubly linked list with strict O(1) operations.
Design Splitwise : Domain modeling, expense strategies, and simplification choices.
Design Elevator : Scheduling, state transitions, and directional logic.
Design Vending Machine : Inventory, payment, state handling, and rollback cases.
Design ATM : Workflow modeling, validation, security, and state machine thinking.
If you can explain the topics on this page clearly and solve most of the linked DSA questions without major hints, you already cover a large chunk of what many interviews expect.