Choose the right abstraction.
One skill, taught from every angle. Each domain asks its own version of the same question — which algorithm, which contract, which storage, which rendering strategy, which architecture — and every answer starts in the same place: name the constraints, then take the simplest thing that survives them. That rewards engineering judgment over memorization, and it is why these cross-link constantly. Real decisions never stay inside one domain.
Preparing for an interview?
Follow a sequence of lessons, practical exercises and self-checks. Choose algorithmic problem solving or the systems foundations for Quant SWE.
Don't delegate understanding.
Modern engineering runs on abstractions — frameworks, managed databases, cloud platforms, libraries, LLMs. Use them. But understand what you're delegating.
- Use the abstraction.
- Understand the abstraction.
- Know its trade-offs.
- Know its failure modes.
- Know when to go one layer deeper.
“Build an e-commerce store. I have never built one and I don't know where to begin — what do I do in the first hour?”
“Why is Binary Search appropriate here instead of a Hash Map?”
“The dashboard says revenue was €1,245,892. Every job is green. How would I know if that number were wrong?”
“It works on my laptop. Why is it unusable on a mid-range phone, and why can nobody navigate it with a keyboard?”
“It shipped fine six months ago. Why does a one-line requirement now touch nine files and break two of them?”
“Validation AUC was 0.94. Two weeks after rollout the review queue doubled and nothing threw an error. What is different?”
“The endpoint works. What happens to it at 20x traffic, on a bad deploy, when the payment API stops answering?”
“The ticket says add a button. What problem is it solving, for whom, and how will we know?”
“I wrote one line. What did the compiler turn it into, and which of that was a choice someone made?”
“Both loops are O(n) — why is one of them ten times slower?”
“p99 doubled and CPU is at 15% — where is the time actually going?”
“What contract does the client actually need — and how can it evolve without breaking consumers?”
“How should I store and reach this data — and what am I giving up?”
“Why does this system need microservices instead of a modular monolith?”
“What actually happens between my program and the hardware?”
“What actually happens when one machine communicates with another?”
“What are we protecting, where does trust change, and what happens when a control fails?”
“What is shared, which interleavings are possible, and does this concurrency actually pay for itself?”
“What guarantee does this need, what can fail, and what can each node actually know?”
“We built an application. How do we run it in production — securely, reliably, and without complexity nobody asked for?”
“Why does this system need an agent at all instead of a deterministic workflow?”
The domains are not isolated courses. Follow one idea across all of them — each step opens the lesson in its own domain.
- Learn→
- Visualize→
- Build→
- Use→
- Inspect→
- Break→
- Debug→
- Understand→
- Compare→
- Choose