Get That Job at Google

This is the post that quietly codified a decade of interview prep. A working Google engineer, writing in his own voice and swearing it isn't official policy, tells you the interview is somewhat arbitrary — and then hands you the study guide anyway. The candor is the whole trick: he admits the process is noisy, which is exactly what makes his advice worth taking seriously.

The thesis: arbitrary, but preparable

Yegge's opening move is disarming honesty. The interview, he concedes, is noisy enough that a good engineer can walk out without an offer — and he insists that shouldn't be read as a verdict on your ability.

"As far as anyone I know can tell, false negatives are completely random, and are unrelated to your skills or qualifications."— Get that job at Google

He isn't confessing this to make you fatalistic — he's clearing the ego out of the way so you'll actually do the work. Because the flip side of "partly random" is "mostly preparable," and the rest of the post is a concrete syllabus for the preparable part.

"Instead, I want to prep you for some general topics that I believe are shared by the majority of tech interviewers at Google-like companies."— Get that job at Google

And he speaks from the wrong side of the process. Yegge is candid that he nearly didn't get in himself:

"Heck, I kinda didn't make it in on my first attempt, but I begged like a street dog until they gave me a second round of interviews."— Get that job at Google

What to actually study

The heart of the post is a review list — the general topics Yegge says most Google-style interviewers share. It's short, it's fundamentals-heavy, and it's meant to be crammed in about a week. His actual section headers:

• Algorithm Complexity — you must be fluent in Big-O; struggling with basic complexity analysis is close to disqualifying.
• Sorting — know at least one n·log(n) algorithm cold (quicksort, merge sort); don't reach for bubble sort.
• Hashtables — arguably the most important data structure of all; know how they actually work under the hood.
• Trees — binary trees, n-ary trees, and tries, plus traversal, at minimum.
• Graphs — the three representations (objects+pointers, matrix, adjacency list) and the basic traversals.
• Other data structures — the greatest-hits (heaps, stacks, queues) and roughly when each earns its keep.
• Math — a little discrete math and probability; counting, basic combinatorics.
• Operating Systems — processes, threads, concurrency, locks, and the classic deadlock / livelock hazards.
• Coding — know at least one language really well, and be able to write it on a whiteboard.

Two items get his loudest emphasis. Hashtables he calls non-negotiable:

"Hashtables are arguably the single most important data structure known to mankind. ... You absolutely have to know how they work."— Get that job at Google

And graphs, he warns, are quietly everywhere:

"Graphs are, like, really really important. More than you think."— Get that job at Google

What they're really testing

The topic list is a decoy if you read it as a trivia checklist. What the interview actually measures is whether you can do the fundamentals live — reason about a problem out loud, pick a data structure, and write correct-ish code on a whiteboard with someone watching. That's a physical skill, and it decays. Yegge learned this the embarrassing way:

"I was absolutely shocked at how bad at whiteboard coding I had become since I had last interviewed seven years prior."— Get that job at Google

His prescription is athletic, not academic: don't just re-read the theory, rehearse it. Practice the exercises for a week and the difference is dramatic — the point isn't fresh knowledge, it's fluency under pressure, which is the exact signal an interviewer can read in forty-five minutes.

Does it still hold up

Eighteen years on, this post reads like the origin story for a whole industry — the "grind the fundamentals before a big-tech loop" ritual that later hardened into LeetCode marathons. That's arguably its unintended legacy, and a fair critique: Yegge's humane, one-week brush-up became, in the hands of a million anxious candidates, a months-long puzzle grind he never prescribed.

But the load-bearing idea has aged remarkably well. The technical content — complexity, hashtables, trees, graphs, concurrency — is still the spine of a systems interview. And the meta-insight is more honest than anything the industry has managed since: the process is noisy, false negatives are real and random, so you can't control the outcome — only your preparation. Detaching your self-worth from a coin-flip result while still doing the work is, if anything, better advice in 2026 than it was in 2008.