4-Month Prep Plan

Goal: “The best time to plant a tree was 20 years ago. The second best time is now.” — We already know JS, so this week we speed-run all 43 topics as pure recall while laying the DSA foundation from scratch.

Topics

Key Concepts

• JS is revision only this week — we’re skimming, not deep-diving. The goal is to jog our memory and flag any weak spots for later.
• For DSA, this is fresh territory. We need to internalize Big O analysis so we can look at any function and estimate its complexity.
• Recursion is the foundation for trees, graphs, and DP later — understand the call stack, base cases, and how to trace through recursive calls.
• Two pointers and sliding window are the first real “patterns” we learn. Once we recognize them, a whole class of array problems becomes solvable.

Practice

• Analyze 3 functions for Big O complexity — write out the reasoning, not just the answer
• Solve 2 two-pointer problems (e.g., pair sum, container with most water)
• Solve 1 sliding window problem (e.g., max sum subarray of size k)
• Write a JS polyfill from memory — Array.prototype.map or Promise.all are great picks

~50 topics · ~2 hrs/day · JS = quick recall, DSA = fresh start

Goal: “Every expert was once a beginner.” — We’re picking up Python for real this week. Meanwhile, DSA shifts into hash maps and sorting — the bread and butter of coding interviews.

Topics

Key Concepts

• Python mutability is crucial — lists are mutable, tuples and strings are not. This trips people up in interviews when they try to modify a string in-place.
• Hash maps are the backbone of 30%+ of interview problems. If we see “find a pair,” “count occurrences,” or “group by,” our first instinct should be reaching for a hash map.
• Prefix sums turn O(n) range queries into O(1) — a simple idea with huge payoff.
• Sorting algorithms — we don’t need to memorize all of them, but we should know merge sort (stable, O(n log n) guaranteed) and quick sort (average O(n log n), in-place).
• Monotonic stacks are a niche but powerful pattern for “next greater element” style problems.

Practice

• Solve 2 hash map problems (e.g., two sum, group anagrams)
• Implement merge sort from scratch in Python — this doubles as Python practice
• Write Python list comprehensions for 3 different transformations (filter + map, flatten 2D list, dict comprehension)
• Solve 1 monotonic stack problem (e.g., next greater element)

~17 topics · ~2 hrs/day · Dual-track: DSA arrays + Python fundamentals

Goal: “The tree that bends in the wind does not break.” — This week we bend our brains around trees, heaps, and binary search while leveling up Python with OOP and decorators.

Topics

Key Concepts

• Binary search is everywhere — not just sorted arrays. The “binary search on answer” pattern lets us solve problems like “minimum capacity to ship packages” by searching the answer space.
• Trees are recursive structures, so tree problems are naturally recursive. If we can solve for one node assuming children are solved, we’re golden.
• Heaps give us O(log n) insert and O(1) min/max access — perfect for “top K” and streaming problems.
• Python decorators are syntactic sugar for higher-order functions. @decorator above a function is the same as func = decorator(func).
• MRO (Method Resolution Order) determines which parent method Python calls in diamond inheritance — it uses the C3 linearization algorithm.
• Dunder methods (__init__, __repr__, __eq__, etc.) let us customize how Python objects behave with operators and built-in functions.

Practice

• Implement a min-heap from scratch (insert, extract-min, heapify)
• Solve 2 binary search variants (e.g., search rotated array, find first/last occurrence)
• Write a Python decorator that logs function calls with arguments and return values
• Create a class hierarchy with an abstract base class — e.g., Shape with Circle and Rectangle subclasses

~19 topics · ~2 hrs/day · Dual-track: DSA trees + Python OOP

Goal: “The only way out is through.” — Month 1 ends with the hardest DSA topics so far (graphs and DP) and the deepest Python concepts (GIL, async, concurrency). We push through together.

Topics

Key Concepts

• BFS = shortest path in unweighted graphs (think “ripple outward”), DFS = exploring all paths (think “go deep, then backtrack”). Know when to use which.
• Topological sort only works on DAGs (directed acyclic graphs) — it’s the go-to for dependency resolution problems.
• DP is just recursion + memoization. If we can write the brute-force recursive solution first, we can convert it to DP by caching subproblems.
• The GIL means Python threads don’t truly run in parallel for CPU-bound work — use multiprocessing for CPU tasks, threading for I/O tasks.
• Context managers (with statement) handle cleanup automatically — no more forgetting to close files or release locks.
• asyncio is single-threaded concurrency. It’s great for I/O-bound tasks like API calls, but won’t speed up CPU-heavy computation.

Practice

• Implement BFS and DFS on an adjacency list — print the traversal order for both
• Solve 1 topological sort problem (e.g., course schedule)
• Write a context manager using both the class approach (__enter__/__exit__) and the @contextmanager decorator
• Solve a basic DP problem (climbing stairs or fibonacci with memoization, then convert to tabulation)

~18 topics · ~2 hrs/day · Dual-track: DSA graphs + Python advanced

Goal: “It does not matter how slowly you go as long as you do not stop.” — This is a BIG week — we’re closing out both DSA Pass 1 and Python. After this, DSA switches to practice mode and you’ll never have a week without coding problems again.

Topics

Key Concepts

• DP is all about finding overlapping subproblems and optimal substructure. If we can break a problem into smaller versions of itself AND the subproblems repeat, DP is our friend. Start with recursion, add memoization, then convert to tabulation.
• Greedy works when the local optimal choice leads to the global optimal — but we need to prove it (or at least intuit it). Activity selection and fractional knapsack are classic examples.
• Backtracking is brute force with pruning. We explore choices, and the moment we realize a path won’t work, we back up. N-Queens and Sudoku are the poster children.
• Metaclasses are “classes of classes” — rarely used in production but interviewers love asking about them. Know that type is the default metaclass and __new__ vs __init__ at the meta level.
• __slots__ saves memory by preventing __dict__ creation on instances. Great for when we have millions of objects with a fixed set of attributes.

Practice

• Solve 1 knapsack variant (0/1 knapsack or unbounded knapsack)
• Solve 1 greedy problem (e.g., activity selection, jump game)
• Solve 1 backtracking problem (N-Queens or generate parentheses)
• Try 3 Python output questions — predict the output before running
• Write a class using __slots__ and compare memory usage with a regular class

~20 topics · ~2 hrs/day · Milestone week: DSA Pass 1 ✓ · Python ✓

Goal: “Knowledge is of no value unless you put it into practice.” — DSA theory is done. From this week on, Track A is pure coding practice — 2-3 problems per session. Meanwhile, we tackle OOP through JavaScript’s unique prototypal lens.

Topics

Key Concepts

• Prototypal inheritance is how JS does OOP under the hood — classes are just syntactic sugar over prototype chains. Understanding __proto__, prototype, and Object.create() is essential.
• Private fields (#field) are truly private in modern JS — no workaround to access them from outside. This is different from the older _convention approach.
• this in JavaScript is determined by how a function is called, not where it’s defined. Arrow functions inherit this from their enclosing scope — that’s the key difference.
• Composition over inheritance is a principle we’ll see everywhere in real-world codebases. Mixins are JS’s way of achieving this.
• SOLID principles apply to any OOP language. In JS interviews, expect questions about Single Responsibility and Open/Closed principles specifically.

Practice

• DSA: Solve 5-6 problems this week — mix of easy/medium from arrays, two pointers, binary search, stacks, and trees
• OOP: Implement a small class hierarchy using both prototypes and ES6 classes — e.g., a Shape base with Circle and Rectangle subclasses
• OOP: Create a mixin that adds serialization (toJSON/fromJSON) to any class

~14 OOP topics + DSA practice · ~2 hrs/day · JS OOP = revision, DSA = daily grind

Goal: “The more that you read, the more things you will know. The more that you learn, the more places you’ll go.” — OOP wraps up this week with Python’s elegant take on it, and we kick off DBMS — the last major theory block before system design.

Topics

Note: Friday is heavier on paper, but the OOP wrap-up topics are lighter (reinforcement from our Python study) and the DBMS fundamentals are conceptual quick reads. It balances out.

Key Concepts

• Python OOP has duck typing — “if it quacks like a duck, it’s a duck.” We care about what an object can do, not what it is. This is fundamentally different from Java/C++ style OOP.
• Name mangling (__attr becomes _ClassName__attr) is Python’s way of saying “please don’t touch this” — it’s not truly private, just heavily discouraged.
• MRO (Method Resolution Order) uses C3 linearization to resolve multiple inheritance. Call ClassName.__mro__ to see the lookup order.
• ACID = Atomicity, Consistency, Isolation, Durability — the foundation of reliable transactions. Every database interview starts here.
• CAP theorem says we can only guarantee 2 out of 3: Consistency, Availability, Partition tolerance. In distributed systems, partition tolerance is non-negotiable, so the real choice is between C and A.

Practice

• DSA: Solve 5-6 problems this week — mix of graph traversal and basic DP
• OOP: Implement the Observer pattern in Python with proper use of ABC and dunder methods
• DBMS: Explain ACID vs BASE in your own words — write it out as if teaching a junior developer

~21 topics + DSA practice · ~2 hrs/day · OOP done! DBMS begins

Goal: “In theory, there is no difference between theory and practice. In practice, there is.” — SQL is one of those topics where reading about JOINs means nothing until we write 20 queries. This week we get our hands dirty with real SQL.

Topics

Key Concepts

• JOINs are the most asked SQL topic in interviews — know INNER, LEFT, RIGHT, FULL, CROSS, and SELF joins cold. Draw Venn diagrams if it helps, but understand that JOINs are really about combining rows based on a condition.
• Window functions (ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD) are increasingly popular in interviews. They let us compute across rows without collapsing the result set like GROUP BY does.
• CTEs (Common Table Expressions) make complex queries readable. Recursive CTEs are especially useful for hierarchical data (org charts, category trees).
• Normalization reduces data redundancy — aim for 3NF in most cases. Denormalization is the intentional reversal for read performance. Neither is “better” — it depends on the use case.
• ER diagrams are how we communicate schema design visually. Get comfortable drawing entities, relationships, and cardinality (1:1, 1:N, M:N).

Practice

• DSA: Solve 5-6 problems this week — greedy, backtracking, and interval problems
• DBMS: Write 5 SQL queries using different types of JOINs (at least one self-join and one with a subquery)
• DBMS: Write 3 queries using window functions — ranking, running totals, and comparing with previous rows
• DBMS: Design an ER diagram for a simple e-commerce system (users, products, orders, reviews) and normalize it to 3NF

~13 topics + DSA practice · ~2 hrs/day · Dual-track: DBMS SQL + DSA coding

Goal: “The best index is the one you don’t have to think about — until a query takes 30 seconds.” — This week we open the hood on how databases actually find data and how they keep it consistent when multiple things happen at once. Indexes and transactions are the backbone of every production database.

Topics

Key Concepts

• B+ Trees are what most databases actually use for indexing — all data lives in leaf nodes, and leaf nodes are linked together for efficient range scans. B-Trees store data in internal nodes too, which makes them less efficient for sequential reads.
• EXPLAIN is our best friend for debugging slow queries. Learn to read query plans — look for sequential scans on large tables (bad), index scans (good), and the estimated vs actual row counts.
• Isolation levels trade consistency for performance. From weakest to strongest: Read Uncommitted → Read Committed → Repeatable Read → Serializable. Most production databases default to Read Committed (PostgreSQL) or Repeatable Read (MySQL InnoDB).
• MVCC (Multi-Version Concurrency Control) is how PostgreSQL handles concurrent reads and writes without locking. Each transaction sees a snapshot of the data — readers never block writers and writers never block readers.
• Deadlocks happen when two transactions are each waiting for the other to release a lock. Databases detect these automatically and kill one transaction — our job is to design queries that minimize the chance.

Practice

• DSA: Solve 5-6 DP problems this week — mix of 1D, 2D grid, and knapsack variants
• DBMS: Run EXPLAIN ANALYZE on 3 different queries (one with a JOIN, one with a subquery, one with GROUP BY) and analyze the output — identify where indexes would help
• DBMS: Explain the difference between Read Committed and Repeatable Read with concrete examples — what anomalies does each prevent?
• DBMS: Describe a scenario where optimistic locking is better than pessimistic locking, and vice versa

~12 topics + DSA practice · ~2 hrs/day · Deep dive into how databases really work

Goal: “Not everything is a nail, so not everything needs a SQL hammer.” — This week we explore the other side of the database world — NoSQL, Redis, and scaling patterns. By Friday, we’ll have completed the entire DBMS track. That’s a massive milestone.

Topics

Note: This week completes the entire DBMS collection! We’ve gone from “what is a database” all the way to sharding, CQRS, and change data capture. Starting next week, we enter system design territory. Everything we’ve learned about databases becomes the foundation for designing scalable systems.

Key Concepts

• Document stores (MongoDB) are great for flexible, evolving schemas — think user profiles, product catalogs. Key-value stores (Redis) are the fastest option when we just need to look things up by a key.
• Redis is both a cache AND a data structure server. It supports strings, lists, sets, sorted sets, hashes, streams, and more. Don’t think of it as “just a cache.”
• Caching patterns matter: cache-aside (lazy loading) is the most common, write-through ensures cache consistency but adds latency, write-behind batches writes for performance but risks data loss.
• Replication = copies for reads (scale horizontally for read-heavy workloads). Sharding = splitting data across nodes for writes (scale horizontally for write-heavy workloads). Most production systems use both.
• CDC (Change Data Capture) captures database changes as a stream of events. It’s how we keep multiple services in sync without tight coupling — essential for microservices architectures.

Practice

• DSA: Solve 5-6 tree and trie problems this week — include at least one BST problem and one trie implementation
• DBMS: Design a caching strategy for a read-heavy social media feed — which pattern would we use and why?
• DBMS: Given a scenario (e-commerce, real-time chat, social graph), explain when we’d pick MongoDB over PostgreSQL and vice versa
• DBMS: Sketch out how we’d shard a users table — what would be our shard key and why?

~16 topics + DSA practice · ~2 hrs/day · DBMS complete! System design starts next week

Goal: “System design is not about memorizing architectures — it’s about understanding trade-offs.” — Welcome to the big leagues. This week we learn how to think about systems at scale. Every building block we study here (load balancers, caches, queues) will show up in every system design interview we’ll ever do.

Topics

Note: The database topics on Friday (SQL vs NoSQL, indexing, replication, sharding) build directly on what we studied in Weeks 8-10. We already know this stuff from the DBMS track — now we’re thinking about it at system scale, in the context of designing distributed systems.

Key Concepts

• The system design interview framework: requirements (functional + non-functional) → estimation (QPS, storage, bandwidth) → high-level design → deep dive into components → identify bottlenecks and trade-offs. This structure keeps us organized under pressure.
• Load balancers distribute traffic across servers. Know the algorithms: round-robin (simplest), least connections (smartest for varying request times), IP hash (sticky sessions). L4 vs L7 load balancing is a common follow-up question.
• CDNs serve static content from edge locations close to users. Think of them as geographically distributed caches. CloudFront, Cloudflare, Akamai — they all do the same fundamental thing.
• Message queues (RabbitMQ, Kafka, SQS) decouple producers from consumers. This is how we handle bursty traffic, async processing, and service-to-service communication without tight coupling.
• Proxies sit between clients and servers. Forward proxy = on the client side (VPN, corporate firewall). Reverse proxy = on the server side (Nginx, Caddy). Most “load balancers” in practice are reverse proxies with load balancing capabilities.

Practice

• DSA: Solve 5-6 graph problems this week — BFS, DFS, shortest path, and union-find
• HLD: Estimate the QPS, storage, and bandwidth requirements for a URL shortener that handles 100M URLs per month
• HLD: Draw a high-level architecture diagram for a blog platform — include load balancer, app servers, database, cache, and CDN
• HLD: For the blog platform, explain which components would need to scale first as traffic grows from 100 to 10M daily users

~15 topics + DSA practice · ~2 hrs/day · Welcome to system design!

Goal: “Distributed systems are easy — said no one ever.” — This week we tackle the hard parts of system design: consistency, availability, failure handling, and communication patterns. These are the topics that separate good answers from great ones in interviews.

Topics

Key Concepts

• Consistent hashing solves the “add/remove server” problem. In naive hashing, adding one server reshuffles almost everything. With consistent hashing, only K/N keys need to move (where K is total keys and N is total nodes). This is how DynamoDB, Cassandra, and CDNs distribute data.
• Microservices give us independent deployment, scaling, and tech stack choices — but they add complexity in communication, data consistency, and debugging. Don’t default to microservices. Start monolith, extract services when the pain is real.
• CAP theorem in practice: partition tolerance is non-negotiable in distributed systems, so the real choice is between consistency (CP) and availability (AP). Most systems are AP with eventual consistency — think DNS, social media feeds, shopping carts.
• Circuit breaker prevents cascade failures in microservices. When a downstream service is failing, the circuit “opens” and we fail fast instead of waiting for timeouts. Bulkhead isolates failures — if one service is slow, it doesn’t eat up all our thread pool.
• REST vs GraphQL vs WebSockets — each has its place. REST for CRUD APIs, GraphQL when clients need flexible queries (mobile apps with bandwidth constraints), WebSockets for real-time bidirectional communication (chat, live updates, gaming).

Practice

• DSA: Solve 5-6 problems this week — string DP, interval DP, and binary search on answer
• HLD: Design a notification system — when would we use polling vs SSE vs WebSockets? Draw the architecture for each approach and explain the trade-offs
• HLD: Explain when we’d choose eventual consistency over strong consistency — give 3 real-world examples of each
• HLD: Design a simple API gateway that handles authentication, rate limiting, and routing to 3 downstream microservices

~15 topics + DSA practice · ~2 hrs/day · Scaling, consistency, and communication protocols

Goal: “The best way to learn system design is to design systems.” — This week we finish HLD. We’ll cover the remaining advanced patterns, then jump straight into real interview questions. By Friday, we’ll have designed URL shorteners, chat systems, and social media feeds. System design goes from theory to practice this week.

Topics

Note: The design questions on Thursday and Friday are practice problems. Before reading each note, try to design the system yourself in 45 minutes — grab a whiteboard, a piece of paper, or just a blank doc. Start with requirements, do a quick estimation, sketch the architecture, then read the notes to see what we missed. That’s where the real learning happens.

And with that — HLD is complete! We’ve gone from “what is system design?” all the way to designing real-world systems. Everything from here builds on this foundation.

Key Concepts

• Rate limiting protects our systems from being overwhelmed. The two main algorithms: token bucket (allows bursts, used by AWS and Stripe) and sliding window (smoother rate control). Know both — interviewers love asking “design a rate limiter” as a full system design question.
• Distributed consensus (Raft, Paxos) is how multiple nodes agree on a value. We don’t need to implement these — just know at a high level that leader election, log replication, and safety guarantees are the core pieces. Raft is easier to understand than Paxos, so start there.
• For every design question, follow our framework: requirements gathering → back-of-the-envelope estimation → API design → data model → high-level architecture → deep dives into interesting components. This structure keeps us from rambling.
• URL shortener is the classic starter question — it tests hashing, database design, caching, and read-heavy optimization. Chat system is about real-time communication + message queuing + delivery guarantees. Feed design is all about fan-out-on-write vs fan-out-on-read (the classic trade-off).
• Event sourcing stores every change as an immutable event instead of just the current state. CQRS separates read and write models. Together, they’re powerful for audit trails, temporal queries, and high-throughput systems — but they add complexity we need to justify.

Practice

• DSA: Solve 5-6 mixed problems this week — specifically target the patterns where we’re weakest
• HLD: Time yourself — design a URL shortener in 45 minutes (requirements → estimation → API → data model → architecture → deep dive)
• HLD: Time yourself — design a chat system in 45 minutes using the same framework
• HLD: Compare your designs against the notes — what did we miss? What trade-offs did we not consider?

~15 topics + DSA practice · ~2 hrs/day · HLD complete! Now think in systems

Goal: “Good code isn’t clever code — it’s code that’s easy to change.” — We’ve been designing systems at 50,000 feet. Now we zoom in. This week is about writing code that doesn’t turn into a tangled mess — SOLID principles, design patterns, and thinking in objects. If HLD was about what to build, LLD is about how to build it.

Topics

Note: SOLID principles are asked in almost every LLD interview — sometimes directly (“explain the Open-Closed Principle”), sometimes indirectly (“look at this code, what would you refactor?”). Don’t just memorize the definitions. For each principle, think of a violation and how we’d fix it. That’s what interviewers are really testing.

Key Concepts

• SOLID is the backbone of OOP design. Single Responsibility = a class should have only one reason to change. Open-Closed = open for extension, closed for modification (use abstraction). Liskov = subtypes must be substitutable for their base types without breaking behavior. Interface Segregation = don’t force classes to implement methods they don’t use. Dependency Inversion = depend on abstractions, not concretions.
• “Favor composition over inheritance” — we’ll hear this everywhere. Inheritance creates tight coupling (the “fragile base class” problem). Composition lets us mix and match behaviors at runtime. Use inheritance for “is-a” relationships, composition for “has-a.”
• UML class diagrams are the visual language of LLD interviews. We don’t need to be UML experts, but we need to draw classes, show relationships (association, aggregation, composition, inheritance), and indicate visibility (+public, -private, #protected).
• Factory pattern delegates object creation to a method — great when the exact type depends on input. Builder pattern constructs complex objects step by step — think of creating a Pizza with optional toppings, crust, size, etc. Singleton ensures a class has exactly one instance — use it for database connections, loggers, configuration managers.
• Coupling = how much one class depends on another (low is better). Cohesion = how focused a class’s responsibilities are (high is better). Low coupling + high cohesion = maintainable code.

Practice

• DSA: Solve 4-5 hard problems this week — at least one DP on trees and one complex backtracking problem
• LLD: Implement a thread-safe Singleton, a Factory for shape creation, and a Builder for a meal order — in your preferred language
• LLD: Draw a UML class diagram for a library management system (books, members, librarians, loans)
• LLD: Take any class we’ve written before and evaluate it against each SOLID principle — what’s good, what could be better?

~17 topics + DSA practice · ~2 hrs/day · SOLID + first design patterns

Goal: “Design patterns aren’t rules — they’re a shared vocabulary.” — We’re closing out LLD and kicking off DevOps this week. By Friday, we’ll have designed parking lots, elevator systems, and chess games — and we’ll know our way around DNS, SSH, and HTTPS. The finish line is in sight.

Topics

Note: Friday is dense — but here’s the thing. The LLD design questions are practice problems, not theory. Try designing Parking Lot from scratch in 60 minutes before reading the notes. The DevOps topics on Friday are quick reads — DNS, HTTP, SSH are things we already use every day, now we’re just making sure we can explain them in an interview.

Key Concepts

• Observer pattern is pub/sub within an application — one object changes state, all its dependents get notified automatically. Think event listeners in JavaScript, or RxJS. Strategy pattern lets us swap algorithms at runtime — sorting strategies, payment methods, compression algorithms. State pattern makes an object’s behavior change based on its internal state — vending machines, traffic lights, order workflows.
• For LLD design questions, our approach is: identify entities (nouns) → define relationships → list behaviors (verbs) → pick design patterns that fit → draw a UML diagram → write key classes. The Parking Lot question is the “hello world” of LLD interviews — get it clean, and the rest follow the same structure.
• Decorator adds behavior to objects dynamically without modifying the original class — think middleware chains, Java I/O streams, or Python decorators. Facade provides a simplified interface to a complex subsystem — it’s what we do every time we wrap a messy API in a clean service layer.
• DevOps basics every developer should know: DNS resolves domain names to IP addresses (it’s a distributed hierarchical database). HTTPS = HTTP + TLS encryption (the padlock in the browser). SSH = secure remote access (how we connect to servers). These come up in “how does the internet work” style interview questions.

Practice

• DSA: Solve 5-6 timed problems this week — 20 minutes per problem, no peeking at solutions until the timer runs out
• LLD: Design a Parking Lot system from scratch in 60 minutes — identify entities, draw UML, write the core classes, then compare with the notes
• LLD: Pick one more design question (Elevator or BookMyShow) and try it in 60 minutes
• DevOps: Trace a DNS lookup from typing a URL in the browser to getting an IP address — write out every step

~25 topics + DSA practice · ~2 hrs/day · LLD patterns done! DevOps begins

Goal: “Repetition is the mother of learning.” — This is the heaviest week by topic count, but don’t panic. DSA Pass 2 is re-reading, not learning from scratch. DevOps topics are quick practical reads. Aptitude is formulaic — shortcuts and mental math. We’re in the home stretch, and this week is about making sure nothing falls through the cracks.

Topics

DSA Pass 2 — Spread Across Study Breaks: These additional topics should be revisited throughout the week whenever we have spare time between sessions: Knapsack Patterns · Greedy Algorithms · Backtracking · Intervals · Hash Maps and Sets · Sorting Algorithms · Graph Representations · Shortest Path Algorithms · Union Find · Tries · Common Interview Patterns

Note: Yes, this is a lot of topics — but let’s break it down. DSA Pass 2 is re-reading notes we’ve already studied and solved problems for. We’re going for instant recall, not deep learning. DevOps topics are practical and quick — Docker, CI/CD, and caching are things most of us have used. Aptitude is about learning shortcuts, not grinding through derivations. The full aptitude collection has 48 topics — we’ve picked the 15 most commonly tested ones here. If a specific company requires heavy aptitude, go through the rest of the collection separately.

Key Concepts

• Docker containerizes applications so they run the same everywhere — dev, staging, production. A Dockerfile defines how to build an image. Docker Compose orchestrates multiple containers. These are must-knows for any backend interview.
• CI/CD automates the build-test-deploy pipeline. CI (Continuous Integration) = automatically build and test on every push. CD (Continuous Deployment) = automatically deploy passing builds. GitHub Actions, Jenkins, GitLab CI — the tools differ, the concept is the same.
• For aptitude: focus on shortcuts and mental math tricks, not grinding through every formula. Percentages, ratios, and time-speed-distance cover 60% of aptitude questions. The last 3 topics (mental math tricks, approximation, and time management) are meta-skills that make everything faster.
• DSA Pass 2 isn’t about learning — it’s about instant recall. When we see a problem, the pattern should click within 30 seconds. Two pointers for sorted arrays, sliding window for subarrays, binary search for monotonic search spaces, BFS for shortest path in unweighted graphs, DP for overlapping subproblems. If any of these don’t feel automatic yet, that’s what this pass is for.

Practice

• DSA: Solve 1 problem from each of the 7 major patterns — array (two pointers/sliding window), tree (traversal/BST), graph (BFS/DFS), DP (1D or 2D), greedy, backtracking, and binary search
• DevOps: Write a Dockerfile and docker-compose.yml for a simple Node.js app with a PostgreSQL database
• Aptitude: Time yourself on 10 percentage/ratio problems — aim for under 2 minutes each
• DSA Pass 2: For each topic, ask yourself “what’s the pattern?” and “when do I use this?” — if the answer doesn’t come in 10 seconds, re-read the note

~40+ topic touches · ~2.5 hrs/day · Triple-track: DSA Pass 2 + DevOps + Aptitude

Goal: “This is it — 16 weeks of grinding, 336+ topics, 10 subjects. No new material this week. Just mock interviews, timed practice, and making everything instant recall. You’ve put in the work — now go prove it.”

Schedule

This week is different — no new topics. Every day is structured as a mock interview round.

Revision Checklist

These are the must-revisit pages — the topics that come up most frequently in interviews. Go through them on Thursday and mark anything that doesn’t feel solid.

JavaScript (most asked)

• Closures · Event Loop · Promises · Prototypal Inheritance · this Keyword

Python (most asked)

• Decorators · Generators and Iterators · GIL · Dunder Methods · Context Managers

DSA (pattern recognition)

• Common Interview Patterns · Binary Search · BFS and DFS · DP Fundamentals · Two Pointers

System Design (framework)

• How to Approach System Design · Design URL Shortener · Design Chat System

DBMS (backend must-knows)

• How Indexes Work · Transactions Deep Dive · SQL vs NoSQL · Caching Patterns

LLD (design skills)

• SOLID Principles (SRP) · Design Parking Lot · Observer Pattern · Strategy Pattern

Key Concepts

No new concepts this week. Focus on speed, articulation, and confidence. In DSA mocks, think out loud — explain your approach before coding. In HLD mocks, always start with requirements gathering and estimation before jumping into architecture. In LLD mocks, start with entities and relationships, then layer on design patterns. The goal isn’t perfection — it’s clear, structured communication under time pressure.

Practice

This IS the practice week. Every day is practice.

• Mon: 3 DSA problems (2 medium + 1 hard), 20 min each, talking through your thought process
• Tue: 1 full system design question, 45 min, whiteboard-style (draw it out, explain trade-offs)
• Wed: 1 full LLD question, 60 min, draw UML, write key classes, identify patterns used
• Thu: Revision day — go through every section of the checklist above, quiz yourself on each topic
• Fri: 3 weakest areas + 3 DSA problems — close any remaining gaps

No new topics · ~2-2.5 hrs/day · You’ve covered 336+ topics across 10 subjects — you’re ready!