After the course · chapter null of 33

What to learn after this course

The epilogue. Read it once now, and again when you finish Part 4.

This app has a deliberate boundary, and it is narrow. It teaches Java from nothing, then low-level design, then it grades you against a fixed standard until you can produce a design under a clock. That is one round of an interview loop at Uber, Atlassian, Salesforce or an Indian product company. It is not the whole loop.

Reading this now, before you start, is useful for one reason: you will know what this app is not doing for you, so you can plan the rest instead of discovering the gap late.

1. What this app does not cover, stated plainly

• High-level design, also called system design. Nothing here touches it.
• Data structures and algorithms. No arrays, no trees, no graphs, no complexity analysis.
• Databases beyond "a HashMap stands in for storage". No SQL, no indexing, no transactions.
• Concurrency at scale. Part 1 and Part 4 teach threads inside one JVM. Distributed coordination is a different subject.
• Behavioural and culture-fit rounds. Not a line.
• Typing speed and IDE fluency, which sound trivial and are not when the clock is running.

None of those are oversights. A tool that covered everything would have covered nothing well, and the gap this app was built to close was specific: you can watch design content and still freeze in front of an empty editor.

2. High-level design, since it is the largest gap

What it is, and how it differs from what you have been doing. Low-level design asks how the classes inside one program fit together. High-level design asks how the machines fit together. Same instinct, different altitude: you are still naming the pieces, drawing the boundaries, and defending the trade-offs, but a boundary is now a network call rather than an interface, and getting it wrong costs latency and money rather than a messy class.

The good news is that the habits transfer more than people expect. Naming what you will not build, finding the decision hiding in a vague requirement, saying the cost of a choice out loud — Part 4 drills all three, and an HLD round rewards exactly the same behaviour.

The topics that come up, roughly in the order they are worth learning:

1. Latency numbers you can reason with. Memory versus disk versus network, same datacentre versus cross-continent. You do not need to memorise a table; you need to know that a network call is roughly a hundred thousand times slower than a memory read, because that ratio is what makes every other decision.
2. Load balancing and statelessness. Why a server that remembers who you are is harder to scale than one that does not.
3. Caching. Where to put it, and what to do when it goes stale. Cache invalidation is genuinely one of the hard problems here, not a joke about one.
4. Databases: SQL versus everything else. Indexes, and why a query without one is a full scan. Replication, and read replicas.
5. Sharding and partitioning. Splitting data across machines, and how choosing the wrong key ruins you later.
6. Queues and asynchronous work. Doing the slow thing later, and what happens when the queue backs up.
7. Consistency. Strong versus eventual, and the CAP theorem — which is worth understanding properly rather than reciting, because the recited version is usually wrong.
8. Rate limiting, retries, backoff, idempotency. You have already met idempotency in lesson E5, and it means the same thing at this altitude.

Where to learn it. Designing Data-Intensive Applications by Martin Kleppmann is the book people recommend for good reason: it explains the mechanisms rather than the interview answers. It is dense and worth the time. For interview shape specifically, Alex Xu's System Design Interview books cover the standard problems in the standard format, and his writing is the closest available model to how this course tries to sound.

A warning about HLD practice. It is easy to read fifty system design write-ups and absorb nothing, which is the same failure that led to building this app. If you do one thing differently, do this: close the article and draw the design yourself on paper before reading the solution, then compare. The gap between what you drew and what they drew is the only part that teaches you anything.

3. Data structures and algorithms

Weighting matters here, and it depends on where you are applying.

At the companies this app targets — Uber, Atlassian, Salesforce, and the Indian product companies — the machine-coding or LLD round is a real, separately weighted round, sometimes the one that decides the offer. So the work you do here is not a side dish. It is one of the main courses.

That is worth stating because the advice you will read online usually assumes a loop where design does not appear until senior levels, and under that assumption algorithms are nearly everything. For these companies that assumption is wrong.

Algorithms still matter, and you will still face those rounds. But the split is closer to even than the internet suggests, and this app covers one whole side of it properly.

The efficient path for the algorithmic side is patterns rather than volume: two pointers, sliding window, binary search on the answer, BFS and DFS, backtracking, intervals, heaps, tries, dynamic programming, and union-find. A few hundred well-chosen problems beats a thousand random ones, and NeetCode's pattern lists are the usual recommendation for that reason.

The efficient path is patterns rather than volume: two pointers, sliding window, binary search on the answer, BFS and DFS, backtracking, intervals, heaps, tries, dynamic programming, and union-find. A few hundred well-chosen problems beats a thousand random ones, and NeetCode's pattern lists are the usual recommendation for that reason.

One thing carries over from here directly. Part 1 taught you Java properly — HashMap semantics, equals and hashCode, collection choice, generics. Most people doing algorithm practice are fighting the language at the same time as the problem. You will not be.

4. The rest of the loop

Behavioural rounds. Have four or five real stories ready, with specifics: what the situation was, what you decided, what it cost, what you would do differently. Vague stories read as invented ones.

Speed. Practise typing a small class from blank with no IDE assistance, because the phases in this app are timed for a reason. Phase 2's clock is not decoration.

A caveat I should state rather than pretend about. Interview processes change, and I cannot verify what any company's loop looks like today. Treat everything in this section as the general shape rather than current fact, and check the details against something recent and first-hand — a recruiter, or somebody who interviewed there in the last few months.

5. A suggested order

Spending everything on this app first is still the wrong move, even though the round it trains is heavily weighted where you are applying. Algorithms take the longest to build and benefit most from spacing, so they need to start early and run alongside.

1. Now: work Part 1 of this course to the end. Java fluency is the foundation for everything else and it is the fastest of these to acquire.
2. Then, in parallel: start daily algorithm practice, and continue this course through Parts 2 and 3. These interleave well because they use different muscles.
3. When you reach Part 4: start HLD reading alongside the graded rounds here. The vocabulary from Part 4 — scope, trade-offs, defending a decision — is what an HLD round wants, so learning both at once is cheaper than learning them apart.
4. Last: behavioural stories and mock interviews with a person. Nothing in this app can simulate a human interrupting you, and that is a real skill.

6. What to come back here for

Once you are through Part 4, this app stops being a course and becomes a gym. Its remaining value is narrow and real:

• The 20 problems, each with measured curveballs, so extending a design under pressure has a number attached rather than a feeling.
• The Ledger, which only counts a skill as held after two demonstrations at least three days apart. Passing once is not the same as being able to do it.
• The Standard, so you know what a level 2 looks like rather than guessing.

Come back for reps, not for reading.

All chapters