#interviews

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

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.

Six rounds, a weekend take-home, and a hard LeetCode problem, all to hire someone who'll spend their first quarter adding fields to a form. Most interview loops test whether you can pass interview loops, and I'd rather test the job.

Count how many triplets of side lengths can form a triangle. Testing every triple is n³; sorting plus one observation lets a single comparison count a whole batch of triangles at once.

Find every triplet that sums to zero, without listing any twice. Three unknowns become two once you fix one, and the hard part turns out to be the duplicates, not the search.

Two pointers on a sorted array finds the pair in one pass. But why is it safe to throw a number away after one bad sum? Draw every pair as a grid and the proof becomes a picture.

Pick two walls from a row so the water between them is as large as possible. Checking every pair works, but one observation about the shorter wall makes it a single pass.

Checking every pair in an array costs n² comparisons. If the array is sorted, one comparison can rule out a whole row of pairs at once, and the nested loop collapses into a single pass.

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.