Interview
History
Invent a hiring test. Teach everyone the test. Wonder why the test stopped working.
Credentials
Please bring a degree and a trusted uncle.
The Software Interview: A Short History
Every few years, someone publishes a retrospective on how the tech interview evolved. They tell the story as market forces: technology changes, demand changes, interview formats follow. That's the visible surface. The deeper story is less flattering — and more useful.
This is specifically about big-tech hiring — Google, Microsoft, Amazon, Meta, Uber, Stripe and the companies that modelled themselves on them. Service firms like TCS, Cognizant, and Infosys run a different tradition (aptitude tests, group discussions, mass hiring) that still operates in parallel. That's a separate story. This one is about what happened every time a smart company tried to build a defensible filter for engineering talent — and what happened next.
The tech interview hasn't evolved toward accuracy. It's evolved toward legibility. Every format that dominated did so because it was easy to defend, not because it found better engineers. That's the pattern worth understanding.
Six eras, one pattern
Scroll through the decades. Watch the proxy change — and watch every one of them get gamed until it broke.
1950s–70s
General cognitive ability
Aptitude Tests
Mathematical reasoning, pattern recognition, and abstract problem-solving speed.
Here's the thread running through all of it: every era picked a proxy, and every proxy got gamed until it broke — often within months of the format becoming known. Books appeared. Prep courses followed. The interview became a test of whether you'd studied the test. The proxy always drifts from the actual job, and it keeps working right up until someone games it hard enough that you can't pretend anymore.
Which interview format have you faced most?
The brainteaser decade
Microsoft popularised the brainteaser interview under Gates and Ballmer. The logic: smart people solve novel problems quickly, therefore interview performance on novel problems reveals smartness. The questions became famous overnight. "Why are manhole covers round?" "How many piano tuners are in Chicago?" "How would you move Mount Fuji?" Within a few years the format had spawned a whole genre of prep books — William Poundstone's *How Would You Move Mount Fuji?* (2003) became a bestseller built entirely around decoding Microsoft's puzzles. The interview had already stopped testing what it claimed to test — it was now testing whether you'd read the book.
This is the recurring pattern, and it happens faster every time: the format gets published, the prep industry emerges, and the signal collapses. The brainteaser era was just the first version of a loop that would repeat with whiteboards, then LeetCode, then the full on-site. Each time, the industry watched the gaming happen — and responded by making the test harder, not by questioning whether the test was right.
How DSA and system design took over
So why did DSA win? Not because it predicted performance. Because it scaled — and because it felt defensible.
A LeetCode problem has a right answer and a complexity to optimize. You can grade it consistently across ten thousand candidates. You can ask everyone the same hard thing and tell your hiring committee the process was fair. When most engineers still had CS degrees, it also looked like a reasonable signal for fundamentals. Google and Amazon formalized the whiteboard loop, then the rest of the industry copied it as FAANG became the aspirational model.
Legible, litigable, and scalable beats accurate when you're hiring at volume. That's the real reason DSA dominated — not that it found the best engineers.
System design rose alongside it for a different reason. As systems went distributed, companies needed to know whether you could reason about scale, failure, and tradeoffs — not just write a function. "Design a URL shortener." "Design Twitter's feed." "Design a rate limiter." For mid and senior roles, this round quietly became the one that actually mattered.
Put together, the trio became the universal filter: DSA for "can you code," system design for "can you architect," behavioral for "will you be a nightmare to work with." The format was well-established by the early 2010s. By the mid-2010s it had spread far beyond FAANG — startups, scale-ups, and every company that wanted to feel rigorous adopted it wholesale.
The human cost
The grind carried a cost the industry consistently chose not to count. Reaching LeetCode competency takes between 200 and 400 hours of deliberate practice. That's two to five months of sustained prep for someone working full-time — and it assumes you have a full-time job that isn't already consuming your evenings. It assumes you don't have children. It assumes you have a stable housing situation, a reliable internet connection, and the psychological bandwidth to rehearse failure every night.
The prep economy grew to hundreds of millions of dollars: LeetCode Premium, NeetCode, AlgoExpert, mock interview platforms, FAANG prep bootcamps. The filter wasn't just selecting for engineers — it was selecting for engineers who could afford to treat interviewing as a second job.
Career changers got filtered out. Caregivers got filtered out. Anyone who learned to code outside a CS degree — bootcampers, self-taught developers, people who spent their twenties in a different industry — faced a format that wasn't testing what they knew, but whether they'd memorised the specific patterns the format rewarded. And because the format correlated weakly with performance, the industry wasn't getting better engineers. It was getting engineers who had more time.
The counter-movement that quietly failed
Before AI changed the equation, a counter-movement was already underway. Companies like Stripe, Shopify, and some of the more thoughtful startups started experimenting with alternatives: paid take-home projects that mirrored real work, pair programming sessions instead of solo whiteboards, GitHub portfolio reviews, open-source contribution histories as proxies for skill. The intuition was right. The execution ran into its own problems.
Take-home projects disadvantaged employed candidates — the people with the most relevant experience often had the least available time. GitHub portfolios favoured whoever was *allowed* to code in public: most enterprise, government, and contract work produces nothing open-sourceable, so a thin profile often meant a restrictive employer, not a weak engineer. They also rewarded discretionary free time — which quietly skews against anyone with caregiving duties or a second job. Pair programming sessions were expensive, hard to standardise, and introduced their own biases. Every alternative turned out to filter differently, not less.
The counter-movement taught the industry something important: there is no neutral filter. Every proxy selects for someone. The question was never whether to filter — it was whether what you were filtering for had anything to do with the job.
So the loop survived. Not because it was the best option, but because no alternative had clearly outperformed it at scale. Companies defaulted back to the devil they knew. The prep economy kept growing. The format kept drifting further from the actual job. And then, in 2022, something changed the equation completely.
Why did DSA dominate hiring for a decade?
The crack
Every proxy worked until something gamed it hard enough. In 2022, that something arrived — and it didn't just bend the filter. It walked straight through it, solved every problem, and asked if there was anything else.
