Overview
Six pillars every engineer revisits: how you store data, how you process it, how you scale systems, how you track change, how you think at boundaries, and how you verify correctness. Use this as a quick reference before interviews, design reviews, or debugging sessions.
Data structures
Ways to organize and store data so it can be accessed and modified efficiently. The right structure makes algorithms fast; the wrong one makes them painfully slow.
Key concepts
- Array / list
- Hash map (dict)
- Stack & queue
- Linked list
- Tree (BST, heap)
- Graph
- Trie
What to know
- Time complexity for access, search, insert, delete on each.
- When to use which — e.g. O(1) lookups → hash map; ordering → BST; BFS/DFS → graph.
- Memory layout: arrays are contiguous, linked lists are pointer-chained.
- Trade-offs: arrays fast to access, bad to insert middle; linked lists the opposite.
Algorithms
Step-by-step procedures to solve problems. Algorithms define how you process your data structures — sorting, searching, transforming.
Key concepts
- Sorting (quicksort, mergesort, heapsort)
- Binary search
- BFS / DFS
- Dynamic programming
- Backtracking
- Greedy
- Divide & conquer
What to know
- Big O notation — time and space complexity of every algorithm you use.
- Recursion and the call stack; when to use iterative vs recursive.
- DP = overlapping subproblems + optimal substructure; identify memoization opportunities.
- BFS = shortest path on unweighted graphs; DFS = explore / detect cycles.
System design
How to design large-scale distributed systems — databases, APIs, caching layers, queues. It's less about code, more about trade-offs at scale.
Key concepts
- Horizontal vs vertical scaling
- Load balancing
- Caching (Redis, CDN)
- Databases (SQL vs NoSQL)
- Message queues (Kafka, RabbitMQ)
- CAP theorem
- Microservices vs monolith
What to know
- CAP theorem: you can only guarantee 2 of Consistency, Availability, Partition tolerance.
- When to denormalize: SQL is consistent & relational; NoSQL trades that for scale/flexibility.
- Cache invalidation strategies — write-through, write-back, TTL.
- Stateless services scale horizontally; stateful ones are hard.
- Bottlenecks: identify the slowest component (DB reads? Network? CPU?).
State management
Tracking how data changes over time in an application. In frontends it's UI state; in backends it's session/transaction state; in distributed systems it's consistency across nodes.
Key concepts
- Immutability
- Unidirectional data flow
- CQRS
- Event sourcing
- Transactions (ACID)
- Optimistic vs pessimistic locking
What to know
- Mutable shared state is the root of most bugs — minimize it.
- Unidirectional flow (Redux-style): action → reducer → new state. Easy to trace, debug, replay.
- ACID in DBs: Atomicity, Consistency, Isolation, Durability.
- Optimistic locking: assume no conflict, check on commit. Pessimistic: lock upfront.
- In UIs: local vs global vs server state have different tools and patterns.
Edge case reasoning
Thinking about what happens at the boundaries — empty inputs, huge inputs, concurrent access, invalid data, system failures. Most bugs live here.
Key concepts
- Null / empty / zero inputs
- Off-by-one errors
- Integer overflow
- Concurrency (race conditions)
- Network failures & retries
- Unexpected data types
What to know
- Always ask: what's the smallest valid input? Largest? What if it's empty/null?
- Off-by-one is the most common loop bug — be precise about < vs <=.
- Concurrency: two threads modifying the same resource = race condition. Use locks, atomics, or immutability.
- Idempotency: can you safely retry an operation? Critical for network calls.
- Fail loudly on unexpected input rather than silently swallowing errors.
Validation discipline
The practice of systematically verifying data correctness at every layer — input, processing, output. It's the difference between robust software and software that crashes in production.
Key concepts
- Input validation (type, range, format)
- Schema validation
- Invariant assertions
- Contract-first design
- Sanitization (SQL injection, XSS)
- Error handling patterns
What to know
- Validate at the boundary — as early as possible, before data touches business logic.
- Never trust client input. Ever. Validate server-side even if you validated client-side.
- Distinguish validation errors (user's fault) from system errors (your fault) — return different codes.
- Invariants: conditions that must always be true. Assert them in debug; encode them in types if possible.
- Sanitize ≠ validate. Sanitize removes/escapes dangerous chars; validate rejects bad data.