Five subjects.
One field manual.

OOP: how objects think

OOP models a program as a society of objects that hold their own data and expose behaviour. Master four pillars, then the two ideas interviewers love to poke at — polymorphism and the subtle line between overloading and overriding.

1.1 The four pillars

Everything else is built on these. Know the one-line definition and a concrete "why".

1.2 Polymorphism: static vs dynamic

"Many forms." It comes in two flavours, and naming which is which is a guaranteed interview question.

• Compile-time / static polymorphism — resolved by the compiler using the method signature. This is method overloading (and, in C++, operator overloading).
• Run-time / dynamic polymorphism — resolved at runtime using the actual object's type. This is method overriding, powered by dynamic dispatch.

Overloading (compiler decides)

class Calc {
    int    add(int a, int b)           { return a + b; }   // baseline
    double add(double a, double b)     { return a + b; }   // different param TYPES
    int    add(int a, int b, int c)    { return a + b + c; } // different param COUNT
}

// The compiler looks at the ARGUMENTS you pass and picks the matching method.
new Calc().add(2, 3);        // calls add(int,int)
new Calc().add(2.0, 3.0);    // calls add(double,double)

Overriding + dynamic dispatch (the object decides)

class Animal { void speak() { System.out.println("...generic..."); } }
class Dog extends Animal { @Override void speak() { System.out.println("Woof"); } }
class Cat extends Animal { @Override void speak() { System.out.println("Meow"); } }

Animal a = new Dog();   // reference TYPE = Animal, actual OBJECT = Dog
a.speak();              // prints "Woof" — chosen at RUNTIME from the real object

for (Animal x : new Animal[]{ new Dog(), new Cat() })
    x.speak();          // "Woof" then "Meow" — same call site, different code

Under the hood the JVM keeps a virtual method table (vtable) per class — a lookup of "for this method name, which actual implementation?" At the call a.speak() it follows the object's vtable, so the object's version runs regardless of the reference type.

struct Animal { virtual void speak(); };   // 'virtual' enables dynamic dispatch
struct Dog : Animal { void speak() override; };

Animal* p = new Dog();
p->speak();   // WITH virtual -> Dog::speak().  WITHOUT virtual -> Animal::speak()

1.3 Overloading vs overriding

The single most asked OOP question. Memorize this table cold.

1.4 Static members, hiding & binding

This is the "static inheritance" trap. Static members are inherited (a child can reference them), but they belong to the class, not the object — so they don't participate in dynamic dispatch. Redefining a static method in a child does not override it; it hides it.

class Parent {
    static void who() { System.out.println("Parent.who [static]"); }
           void hi()  { System.out.println("Parent.hi  [instance]"); }
}
class Child extends Parent {
    static void who() { System.out.println("Child.who [static]"); }   // HIDES
           void hi()  { System.out.println("Child.hi  [instance]"); } // OVERRIDES
}

Parent p = new Child();
p.who();   // "Parent.who" -> STATIC resolved by REFERENCE type (compile time)
p.hi();    // "Child.hi"    -> INSTANCE resolved by OBJECT type (runtime)

Same story for fields — they are resolved by the reference type, never polymorphic. This is field hiding:

class A { int x = 1; }
class B extends A { int x = 2; }   // hides A.x, doesn't override it

A ref = new B();
System.out.println(ref.x);          // 1  -> field picked by REFERENCE type A
System.out.println(((B) ref).x);    // 2  -> cast changes the reference type

1.5 Design patterns you must know

Patterns are reusable solutions to recurring design problems. They cluster into three families.

Singleton — exactly one instance

// (a) Bill Pugh holder — lazy, thread-safe, no locking. PREFERRED.
public class Config {
    private Config() {}
    private static class Holder { static final Config INSTANCE = new Config(); }
    public static Config get() { return Holder.INSTANCE; }   // class loaded only on first use
}

// (b) Double-checked locking — note 'volatile' (prevents seeing a half-built object)
public class Cache {
    private static volatile Cache instance;
    private Cache() {}
    public static Cache get() {
        if (instance == null) {                 // 1st check (no lock, fast path)
            synchronized (Cache.class) {
                if (instance == null)           // 2nd check (inside lock)
                    instance = new Cache();
            }
        }
        return instance;
    }
}

// (c) Enum — simplest; immune to reflection & serialization attacks
public enum Settings { INSTANCE; public void load() { /* ... */ } }

Factory Method — ask for a type, get an object

interface Shape { double area(); }
class Circle implements Shape { public double area() { return 3.14159; } }
class Square implements Shape { public double area() { return 4.0; } }

class ShapeFactory {
    static Shape create(String type) {
        return switch (type) {
            case "circle" -> new Circle();
            case "square" -> new Square();
            default -> throw new IllegalArgumentException("Unknown: " + type);
        };
    }
}
Shape s = ShapeFactory.create("circle");   // caller never says 'new Circle()'

Builder — readable construction of complex objects

class Pizza {
    private final String size; private final boolean cheese, pepperoni;
    private Pizza(Builder b) { size = b.size; cheese = b.cheese; pepperoni = b.pepperoni; }

    static class Builder {
        private final String size;            // required
        private boolean cheese, pepperoni;    // optional
        Builder(String size)   { this.size = size; }
        Builder cheese()       { this.cheese = true;    return this; }   // fluent
        Builder pepperoni()    { this.pepperoni = true; return this; }
        Pizza build()          { return new Pizza(this); }
    }
}
Pizza p = new Pizza.Builder("large").cheese().pepperoni().build();

Builder kills the "telescoping constructor" anti-pattern (new Pizza("L", true, false, true, ...) where nobody can tell what the booleans mean).

Strategy — swap an algorithm at runtime

interface PayStrategy { void pay(int amount); }
class CardPay implements PayStrategy { public void pay(int a) { /* charge card */ } }
class UpiPay  implements PayStrategy { public void pay(int a) { /* charge UPI  */ } }

class Checkout {
    private PayStrategy strategy;
    void use(PayStrategy s)      { this.strategy = s; }   // inject behaviour
    void checkout(int amount)    { strategy.pay(amount); }
}
Checkout c = new Checkout();
c.use(new UpiPay());     // pick the algorithm without touching Checkout's code
c.checkout(500);

Observer — publish/subscribe

interface Observer { void update(String news); }

class NewsAgency {                                   // the Subject
    private final List<Observer> subs = new ArrayList<>();
    void subscribe(Observer o)   { subs.add(o); }
    void publish(String news)    { for (Observer o : subs) o.update(news); }
}
// Any number of observers register and get pushed updates — loose coupling.

Decorator — add behaviour by wrapping

interface Coffee { double cost(); }
class Plain implements Coffee { public double cost() { return 40; } }

abstract class AddOn implements Coffee {     // wraps another Coffee
    protected final Coffee inner;
    AddOn(Coffee c) { this.inner = c; }
}
class Milk extends AddOn {
    Milk(Coffee c) { super(c); }
    public double cost() { return inner.cost() + 10; }   // extend without subclass-explosion
}
Coffee order = new Milk(new Milk(new Plain()));   // 40 + 10 + 10 = 60

DBMS: keeping data correct under chaos

A database's whole job is to stay correct while many users hammer it at once and machines crash mid-write. That promise is ACID, enforced by transactions, concurrency control, and recovery. Then we get hands-on with SQL.

2.1 Transactions & ACID

A transaction is a unit of work that must happen completely or not at all — classically, transferring money: debit one account, credit another. Halfway = corruption. Every transaction guarantees four properties:

BEGIN;                                              -- start transaction
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;   -- debit
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;   -- credit
COMMIT;        -- both succeed together; if anything fails -> ROLLBACK (atomicity)

2.2 Concurrency control

Run transactions in parallel for speed, but interleaving creates anomalies. Interviewers expect you to name all four:

Isolation levels — the dial that trades safety for speed

*MySQL's InnoDB actually blocks phantoms at Repeatable Read too, using gap locks. Higher isolation = more correctness but more locking and less concurrency.

How isolation is implemented

• Lock-based — shared (S) locks for reads, exclusive (X) locks for writes. The key protocol is Two-Phase Locking (2PL): a growing phase where a txn only acquires locks, then a shrinking phase where it only releases. 2PL guarantees conflict serializability.
• Strict 2PL — hold all exclusive locks until COMMIT. Prevents cascading rollbacks (no one reads your uncommitted writes).
• Timestamp ordering — each txn gets a timestamp; conflicting operations must execute in timestamp order, else the younger txn aborts.
• MVCC (multi-version concurrency control) — every write creates a new version; readers see a consistent snapshot from their start time. Readers never block writers and vice-versa (used by PostgreSQL, InnoDB, Oracle).

2.3 Atomicity & recovery

How does "all-or-nothing" survive a power cut mid-write? The answer is Write-Ahead Logging (WAL): the change is written to a durable log before it touches the actual data pages.

• Undo info lets the DB roll back uncommitted transactions after a crash (atomicity).
• Redo info lets it re-apply committed transactions that hadn't reached disk (durability).
• SAVEPOINT gives partial rollback inside a transaction.

BEGIN;
  INSERT INTO orders(id, total) VALUES (1, 500);
  SAVEPOINT after_order;
  INSERT INTO items(order_id, sku) VALUES (1, 'BAD');
ROLLBACK TO after_order;      -- undo just the items insert, keep the order
COMMIT;

2.4 Redundancy vs consistency

Store the same fact in two places and they will drift apart. Redundancy causes anomalies:

• Update anomaly — change a department name, miss one row, now it's inconsistent.
• Insertion anomaly — can't add a department until at least one employee exists in it.
• Deletion anomaly — delete the last employee and you accidentally lose the department's info.

Normalization removes redundancy by splitting tables according to functional dependencies (X → Y means X determines Y).

Denormalization is the deliberate reverse: re-introduce redundancy (e.g. store dept_name on each order) to avoid expensive joins and speed up reads. The trade: faster reads, but slower/riskier writes and a duty to keep copies in sync. Normalize for OLTP correctness; denormalize selectively for read-heavy analytics.

2.5 SQL — from zero to interview queries

SQL has four sub-languages. Knowing which is which signals fluency:

Our example schema (used throughout)

CREATE TABLE departments (
    id   INT PRIMARY KEY,
    name VARCHAR(50) NOT NULL
);

CREATE TABLE employees (
    id         INT PRIMARY KEY,
    name       VARCHAR(50) NOT NULL,
    dept_id    INT,
    manager_id INT,                 -- self-reference to another employee's id
    salary     INT,
    FOREIGN KEY (dept_id)    REFERENCES departments(id),
    FOREIGN KEY (manager_id) REFERENCES employees(id)
);

SELECT — the workhorse

SELECT name, salary          -- 1. which columns to return
FROM   employees             -- 2. from which table
WHERE  salary >= 50000        -- 3. keep only matching rows
ORDER  BY salary DESC         -- 4. sort the result
LIMIT  10;                    -- 5. cap the number of rows

JOINs — combining tables

A join matches rows across tables on a condition. The type decides what happens to non-matching rows.

-- INNER: employees that have a department
SELECT e.name, d.name AS dept
FROM   employees e
JOIN   departments d ON e.dept_id = d.id;

-- LEFT: ALL employees, dept shows NULL if they have none
SELECT e.name, d.name AS dept
FROM   employees e
LEFT JOIN departments d ON e.dept_id = d.id;

-- SELF JOIN: pair each employee with their manager
SELECT e.name AS employee, m.name AS manager
FROM   employees e
LEFT JOIN employees m ON e.manager_id = m.id;

Aggregation: GROUP BY & HAVING

Aggregate functions (COUNT, SUM, AVG, MIN, MAX) collapse many rows into one. GROUP BY makes one result row per group.

SELECT dept_id,
       COUNT(*)    AS headcount,
       AVG(salary) AS avg_pay
FROM   employees
GROUP  BY dept_id
HAVING AVG(salary) > 60000      -- filter GROUPS (after aggregation)
ORDER  BY avg_pay DESC;

Subqueries

-- Scalar subquery: who earns above the company average?
SELECT name FROM employees
WHERE salary > (SELECT AVG(salary) FROM employees);

-- Correlated subquery: above-average WITHIN their own department
-- (inner query re-runs for each outer row, referencing e.dept_id)
SELECT e.name
FROM   employees e
WHERE  e.salary > (SELECT AVG(x.salary) FROM employees x WHERE x.dept_id = e.dept_id);

-- EXISTS: departments that have at least one employee
SELECT d.name FROM departments d
WHERE EXISTS (SELECT 1 FROM employees e WHERE e.dept_id = d.id);

Window functions (the senior-level differentiator)

Like aggregates, but they keep every row and compute across a "window" of related rows defined by OVER (PARTITION BY ... ORDER BY ...).

SELECT name, dept_id, salary,
       ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn,
       RANK()       OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rnk,
       DENSE_RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS drnk,
       SUM(salary)  OVER (PARTITION BY dept_id)                      AS dept_total,
       LAG(salary)  OVER (ORDER BY salary)                           AS prev_salary
FROM employees;

Classic interview queries

1 · Nth-highest salary (shown for 2nd) — three idiomatic ways:

-- (a) Subquery — max salary that is below the overall max
SELECT MAX(salary) FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

-- (b) DENSE_RANK — generalises to ANY N and handles ties cleanly
SELECT DISTINCT salary FROM (
    SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS r
    FROM employees
) t
WHERE r = 2;                      -- change 2 to N

-- (c) LIMIT / OFFSET (MySQL, Postgres)
SELECT DISTINCT salary FROM employees
ORDER BY salary DESC
LIMIT 1 OFFSET 1;                 -- OFFSET = N - 1

2 · Find duplicates and 3 · earn more than manager:

-- Duplicate names
SELECT name, COUNT(*) AS cnt
FROM   employees
GROUP  BY name
HAVING COUNT(*) > 1;

-- Employees who out-earn their manager (self-join)
SELECT e.name
FROM   employees e
JOIN   employees m ON e.manager_id = m.id
WHERE  e.salary > m.salary;

4 · Top earner per department and 5 · delete duplicates keeping one:

-- Highest-paid employee in each department
SELECT name, dept_id, salary FROM (
    SELECT name, dept_id, salary,
           RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS r
    FROM employees
) t
WHERE r = 1;

-- Remove duplicate rows, keep the one with the smallest id
DELETE FROM employees
WHERE id NOT IN (
    SELECT MIN(id) FROM employees GROUP BY name, dept_id, salary
);

Indexes — why queries get fast (or slow)

An index is an auxiliary structure (usually a B+ tree) that keeps a column's values sorted with pointers to rows — turning a full-table scan O(n) into a tree lookup O(log n) for WHERE, JOIN, and ORDER BY.

CREATE INDEX idx_emp_dept ON employees(dept_id);   -- speeds up filters/joins on dept_id

OS: sharing one machine, safely

An OS multiplexes finite hardware — CPU, RAM, devices — across many programs while keeping them isolated and responsive. The interview core: how concurrent work is coordinated (semaphores), how it deadlocks, and how virtual memory fakes infinite RAM.

3.1 Process vs thread

A process is a program in execution with its own address space and resources. A thread is the smallest unit of execution inside a process; multiple threads share the process's memory but each has its own stack, registers, and program counter.

3.2 Semaphores

A semaphore is an integer guarded by two atomic operations:

• wait() (a.k.a. P / down): decrement; if the result would be negative, the caller blocks until a resource frees up.
• signal() (a.k.a. V / up): increment; wake one waiting thread if any.

The canonical problem: producer–consumer

A bounded buffer of size N. Producers must wait if it's full; consumers must wait if it's empty; only one thread touches the buffer at a time. Three semaphores solve it:

semaphore mutex = 1;   // mutual exclusion on the buffer
semaphore empty = N;   // number of empty slots  (producers wait on this)
semaphore full  = 0;   // number of filled slots (consumers wait on this)

void producer() {
    while (true) {
        item = produce();
        wait(empty);          // is there room? block if buffer full
        wait(mutex);          // enter critical section
            buffer_put(item);
        signal(mutex);        // leave critical section
        signal(full);         // announce: one more item to consume
    }
}

void consumer() {
    while (true) {
        wait(full);           // is there an item? block if buffer empty
        wait(mutex);
            item = buffer_get();
        signal(mutex);
        signal(empty);        // announce: one more free slot
        consume(item);
    }
}

3.3 Deadlock

A deadlock is a set of processes each waiting forever for a resource another holds. It can happen only when all four Coffman conditions hold at once:

The four strategies

• Prevention — structurally negate one of the four conditions (e.g. always acquire resources in a fixed numeric order ⇒ no circular wait).
• Avoidance — grant a request only if the system stays in a safe state. The Banker's algorithm checks whether a safe sequence still exists (one ordering in which every process can get its max need and finish) before allocating.
• Detection & recovery — allow deadlocks, find cycles in the wait-for graph, then recover by aborting a process or preempting resources.
• Ignore (Ostrich algorithm) — pretend it won't happen; reboot if it does. What general-purpose OSes mostly do, because prevention is costly and deadlocks are rare.

3.4 Virtual memory

Virtual memory gives each process its own large, contiguous address space — even larger than physical RAM — by splitting memory into fixed-size pages (virtual) mapped to frames (physical) via a page table. The MMU translates every address; rarely-used pages live on disk.

• Demand paging — a page is loaded only when first accessed; the access traps as a page fault and the OS fetches it.
• TLB (Translation Lookaside Buffer) — a small cache of recent page→frame translations, so most lookups skip the page table entirely.
• Locality of reference — programs tend to reuse nearby addresses, which is why caching and paging work at all.

Page replacement — what to evict when RAM is full

Networks: getting bits across the world

Networking is layered so each level solves one problem and trusts the layer below. Nail the layer model and its protocols, the TCP vs UDP trade-off, how errors are caught/fixed, and how routers find paths.

4.1 The layers & their protocols

The OSI model has 7 conceptual layers; the practical TCP/IP model collapses them into 4. Data gains a header at each layer going down (encapsulation) and sheds it going up.

TCP/IP mapping: Application (OSI 5–7) · Transport (4) · Internet (3) · Link/Network Access (1–2). Mnemonic, bottom-up: Please Do Not Throw Sausage Pizza Away.

4.2 TCP vs UDP

Both are Layer-4 transport protocols; the choice is reliability vs speed. This comparison is asked in nearly every networking interview.

4.3 Error management

Bits flip in transit. The receiver must at least detect corruption, and sometimes correct it.

Detection — "is this frame damaged?"

Correction — "fix it without re-asking"

Hamming code places parity bits at power-of-2 positions (1, 2, 4, 8…). Their combined "syndrome" pinpoints the exact position of a single flipped bit, so the receiver flips it back — single-error correction with no retransmission.

When you'd rather just ask again, you use ARQ (Automatic Repeat reQuest) — retransmission protocols built on ACKs and timeouts:

4.4 Routing basics

Routing is how routers decide the path a packet takes across networks, using routing tables they build and update. Dynamic routing splits into two big families:

System Design: from one class to a million users

Two scales of the same skill. LLD is about classes, responsibilities and relationships inside one service — interviewers probe it through SOLID, UML and patterns. HLD is about boxes and arrows between services — load balancers, caches, databases, queues — and the trade-offs that hold them together. Learn the vocabulary, then the framework to apply it under pressure.

5.1 SOLID & Low-Level Design

SOLID is five principles for writing classes that are easy to change without breaking things. They are the backbone of every LLD interview — know the name, the one-line idea, and the smell each one fixes.

The O and D principles are where most refactors happen. Here's the Open/Closed idea concretely — a payment processor that breaks the rule, then one that follows it:

// ✗ Violates OCP: every new method forces editing this class
class PaymentService {
    void pay(String type) {
        if (type.equals("card"))      { /* ... */ }
        else if (type.equals("upi"))  { /* ... */ }   // edit again for each new type
    }
}

// ✓ Follows OCP + DIP: extend by adding a class, depend on the interface
interface PaymentMethod { void pay(double amount); }

class CardPayment implements PaymentMethod {
    public void pay(double amount) { /* charge card */ }
}
class UpiPayment implements PaymentMethod {
    public void pay(double amount) { /* charge UPI  */ }
}

class PaymentService {
    void checkout(PaymentMethod method, double amount) {
        method.pay(amount);          // new methods need ZERO changes here
    }
}

The other principles you'll be quizzed on

DRY says extract duplicated logic into one place. KISS and YAGNI push the other way — don't over-engineer or build for imaginary future needs. Composition over inheritance means prefer "has-a" (a Car has an Engine) over deep "is-a" trees, because inheritance is rigid and leaks parent details into children. The Strategy and Decorator patterns are composition in action.

Design patterns — the LLD recap map

You met several patterns in the OOP section. Interviewers expect you to place a pattern in its family and name when you'd reach for it. The three Gang-of-Four families:

5.2 UML relationships

LLD answers are drawn as class diagrams, so you must read and draw the relationship arrows. They differ by strength of coupling and lifetime ownership:

A worked mini-LLD: a parking lot

This is the canonical LLD warm-up. You don't write full code — you identify entities, relationships and key behaviours. A clean first pass:

ParkingLot  ──◆── Floor          // lot OWNS floors (composition)
Floor       ──◆── ParkingSpot    // floor OWNS spots
ParkingSpot ──>   Vehicle        // spot references the parked vehicle

Vehicle (abstract)               // is-a hierarchy
  ├── Car        extends Vehicle
  ├── Bike       extends Vehicle
  └── Truck      extends Vehicle

SpotType  enum { COMPACT, LARGE, BIKE, EV }    // strategy for fit-check
Ticket    { id, spot, entryTime, exitTime }
FeeStrategy (interface)          // ✦ Strategy pattern: hourly / flat / EV
ParkingLot.assignSpot(Vehicle)   // key behaviour → returns Ticket
ParkingLot.processExit(Ticket)   // → FeeStrategy.calculate()

Notice the SOLID/pattern hooks: FeeStrategy keeps pricing open/closed, the Vehicle hierarchy uses inheritance, and the lot→floor→spot chain is composition. Calling those out by name is exactly what scores points.

5.3 HLD building blocks

High-Level Design zooms out to services, data stores and the network between them. There's a fixed toolbox of components; an HLD answer is choosing the right ones and justifying the trade-offs. Start with the most fundamental choice — how you grow.

Scaling: vertical vs horizontal

Load balancing

A load balancer sits in front of your servers and distributes incoming requests so no single server is overwhelmed. It also does health checks — routing traffic away from dead instances. Common algorithms: round-robin (rotate evenly), least-connections (send to the least-busy server), and consistent hashing (stick a given user/key to the same server, vital for caches).

Caching

A cache stores hot data in fast memory (e.g. Redis, Memcached) so you avoid slow recomputes or DB hits. Caching is the single highest-leverage performance lever — and the source of the hardest bugs (stale data, invalidation).

Database scaling: replication & sharding

Partitioning comes in two flavours: horizontal (split rows across stores — what "sharding" usually means) and vertical (split columns/tables by access pattern).

SQL vs NoSQL

CAP theorem

The cornerstone trade-off of distributed data. A distributed store can guarantee only two of these three at once:

Since network partitions will happen at scale, P is non-negotiable — so the real choice is C vs A. A CP system (e.g. a banking ledger) refuses to answer rather than return stale data; an AP system (e.g. a social feed) always answers, accepting it may be briefly out of date.

Async & the rest of the toolbox

Microservices vs monolith

5.4 The interview framework

A system-design round is open-ended on purpose — they're watching your process. Don't jump to drawing databases. Follow a script so you never freeze. The standard 6-step flow:

1. Clarify requirements (~5 min). Pin down functional needs ("users post and follow") and non-functional ones (scale, latency, consistency vs availability, read:write ratio). Never design before scoping — ask first.
2. Estimate scale. Back-of-envelope the QPS, storage, and bandwidth from the numbers above. This justifies every later choice (do we even need sharding?).
3. Define the API. List the core endpoints — createPost(), getFeed(userId). This nails down exactly what the system must do.
4. Design the data model. Pick SQL vs NoSQL with a reason, sketch the main tables/entities and the access patterns that shape them.
5. Draw the high-level design. Client → load balancer → app servers → cache → DB, plus queues/CDN/blob store as needed. Walk a request through end to end.
6. Deep-dive & address bottlenecks. Pick the hard part (the feed fan-out, the hot shard) and go deep. Name the single points of failure and how you'd remove them (replication, multiple LBs), then the trade-offs you accepted.