Questions 1 console.log('A'); setTimeout(() => console.log('B'), 0); Promise.resolve().then(() => console.log('C')); console.log('D'); Output order? Show answer A, D, C, B Sync logs A and D. Then the microtask (C) drains before the setTimeout
Predict the output/behavior of each snippet. Attempt first, then click "Show answer" to reveal!
Predict the behavior/output. Each answer is hidden under a "Show answer" toggle — attempt first!
Building Blocks
A review post for the six-floor foundation series .None of these are "define X." They're scenarios and traps
Building Blocks
Sixth and final post in the foundation series. We've built the whole stack, bottom to top (Floors 0–4). This floor is the meta-floor: the everyday patterns engineers assemble from these blocks, and the single tension that runs through every one of them.
System Design
Fourth post in the series. We can move data reliably between machines (Floor 2). Now: once data arrives, how do you store it so it survives a crash, a power cut, a reboot? This is where the word durability finally gets a precise, physical meaning.
Building Blocks
Fifth post in the series. We can store data durably on one machine. But one machine is a single point of failure, and it has a capacity ceiling. This floor goes wide — and it's the floor the whole distributed world stands on.
System Design
Third post in the series. Floor 0 taught us the network is the slow shelf. Floor 1 squeezed everything out of one machine. This floor is where single-machine thinking ends and distributed thinking begins — and it's where a lot of engineers quietly get things wrong.
Building Blocks
Second post in the series. Floor 0 taught us that some data is far away and slow to reach. This floor asks the question that follows: while you're stuck waiting for something slow, what should you actually be doing?
System Design
The first post in a series where I build system-design intuition from the ground up. No jargon dumped on you up front — we start with an everyday situation, reason it out, and only then attach the technical name.
DSA
Math problems have a reputation for being intimidating — as if each one needs some clever theorem you were supposed to remember from school. The truth is far friendlier. Just like array problems, the whole space is covered by a small set of reusable techniques. Once you can name them, "
DSA
When you are starting out, every array problem feels brand new. You solve "remove duplicates," then you meet "move all zeros to the end," and it feels like a completely different puzzle — even though, underneath, it is the same idea wearing different clothes. The goal of