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 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.

Read this now, before you start, 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 covering 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, defending the trade-offs. But a boundary is now a network call instead of an interface, and getting it wrong costs latency and money instead of a messy class.

The good news is that the habits transfer further 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 the table memorised. You need to know that a network call is roughly a hundred thousand times slower than a memory read, because that ratio drives 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, and 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 — worth understanding properly rather than reciting, because the recited version is usually wrong.
8. Rate limiting, retries, backoff, idempotency. You already met idempotency in lesson E5. 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 instead of 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. That is the same failure that led to building this app.

So 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, the Indian product companies — the machine-coding or LLD round is a real, separately weighted round. Sometimes it is 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 read online usually assumes a loop where design does not appear until senior levels. Under that assumption algorithms are nearly everything. For these companies the assumption is wrong.

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

For the algorithmic side, the efficient path is patterns instead of volume. Two pointers. Sliding window. Binary search on the answer. BFS and DFS. Backtracking. Intervals. Heaps. Tries. Dynamic programming. Union-find.

A few hundred well-chosen problems beats a thousand random ones, which is why NeetCode's pattern lists are the usual recommendation.

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 and the problem at the same time. 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. The phases in this app are timed for a reason, and 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 this section as the general shape, not 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 instead of 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 instead of guessing.

Come back for reps, not for reading.

All chapters