Writing

All of the site's copy moves out of components into one central file, and components read it through `t('key')`. The keys are typed against that file, so they autocomplete, and a typo or a deleted line fails the type-check instead of shipping blank.

Click "Show all" on a collapsed block and the button unmounts, taking keyboard focus with it: the next Tab starts from the top of the page. `useCollapsible` moves focus to whatever replaced the button.

`line-clamp` cuts text off, but it can't tell your JavaScript whether it did, so every short description gets a pointless "Show more". `useOverflow` measures the element and answers that one question.

A "Copied" tick, a "Saved" badge, a shake on a wrong password: state that should be true for a moment and then go back on its own. `useMomentaryFlag` is that boolean, with the timer handled.

On 2 July 2019 a single new firewall rule took Cloudflare, and a large part of the web with it, offline for 27 minutes. Not an attack, not a hardware failure. How does one rule do that to every server at once?

Pay by bank looks like two taps in the pitch deck. In production it's five hand-offs across three companies, and every one of them loses people.

Your ledger says a payment succeeded. The provider's settlement report, days later, disagrees. Which one is right?

"What happens between typing a URL and seeing the page?" I've shipped web apps for years, and in an interview I still fumbled it.

Every service is healthy and the dashboard average looks great, yet support is full of customers saying the app is slow. Both are telling the truth.

Closing every ticket on a feature doesn't mean the feature works. So whose job is it to find out?

Counting unique visitors sounds like a set: add every user id, read its size. At a few billion ids that set is tens of gigabytes, kept only to produce one number. Do you need to remember who visited to count them?

A celebrity posts and a million people tap the heart in ten minutes, and every one of them sees a count that seems to keep up. One row with a number in it can't take that. So what does?

A green tick appears before you've stopped typing, and behind it is a list of a billion taken names. It isn't one clever database query.

Two eggs, a 100-floor building, and the fewest drops that are guaranteed to find the floor where eggs start breaking. Binary search is the obvious answer, and it loses badly.

Save to the database, then publish an event: two lines, two systems, and nothing that makes them agree. What happens when the process dies in between, and why every obvious fix still leaves a gap.

A checkout handler that calls the ledger, the warehouse, the email service and analytics in a row is as slow as all of them added together and as fragile as all of them multiplied. And every team that cares about payments makes it a little worse.

Two requests read the same row, both do their maths, both write back. One of them silently disappears. How the system should resolve that isn't one answer: it depends on whether the write is a delta, a quick piece of logic, or a human edit made minutes after the read.

The interviewer asks how much traffic you're expecting. Round to powers of ten, turn per-day into per-second, and end every number on the design decision it forces: one node, a cache, or a shard.

You're about to add logging to a new service, or you're staring at an existing one where every incident turns into a grep-and-guess session across a dozen disconnected log lines. Replace the step-by-step logs with one wide event per request.

A tiny `createEvent(name, seed)` that accumulates fields over the life of a request via `.set()` and emits exactly one structured log line via `.emit()`, so a request that touches ten steps still produces one row instead of ten.