How Long Was the Interview?

In 2015 a man stood at a whiteboard in a Google office and failed to invert a binary tree.

That is the whole scene. A marker, a whiteboard, a data structures question of the kind that gets asked a thousand times a day, and a candidate who could not produce the answer in the allotted time. Google said no. The man went home and posted the sentence that has been quoted at every engineering conference since: ninety percent of your engineers use the software I wrote, but I can’t invert a binary tree on a whiteboard, so off I go.

The man was Max Howell. The software was Homebrew, which is, for practical purposes, how software gets onto a Mac. Everyone remembers the rejection. Now sit with the other half of his sentence. His code was already inside the building. It had been inside for years. It was on the laptop of every engineer who interviewed him, with the kind of access no contractor would be granted on day one, and it stayed long after its author was walked back to reception.

So Google ran two front doors that day. At the first one, a human got five hours of interviews, a hiring committee, a background check, and a no. At the second one, his code walked in without being asked a single question.

Which of those two doors was doing security?

The eight-second interview

Your company has the same two doors. Think about your last hiring round. The phone screen, the take-home, the panel, the debrief where someone said they were just not seeing the bar. Now think about the last time someone on your team typed an install command. How long was that interview? Eight seconds? And how many candidates came through on it, four hundred, a thousand? Each one written by a stranger. Each one able to run code on the machine the moment it landed. Each one bringing its own friends, transitively, friends of friends, names nobody on your team has ever pronounced out loud. You would not let a candidate touch a keyboard before the reference checks came back. What did the strangers get, again, on day one?

The morning the list mattered

This spring, npm made the news again. Another batch of poisoned packages, another wave of advisories, another day of security newsletters saying check whether you’re affected. Here is a more interesting question than whether you were affected: what did your team actually do that morning?

Because checking, it turns out, means something specific. It means producing the list. Which packages, pulled in by what, at which versions, with which lifecycle scripts allowed to run on install. The teams that actually did it tend to report the same strange aftertaste. Was the shock the attack? Or was it noticing that this was the first time anyone had read the guest list at all? The strangers were already on the machines. The attack didn’t let them in. It only forced the question of who was already inside.

A few teams took one more step and turned the question on the doorman itself. If four hundred strangers can’t be interviewed, can the tool at least stop trusting them by default? One of the package managers has been redesigned around exactly that suspicion. pnpm won’t run a dependency’s install scripts unless you explicitly allow it, and it won’t let a package quietly reach into code it never declared. The repos that switched that week didn’t switch because the strangers became trustworthy. They switched because the tool stopped pretending they were.

Hold that distinction. It comes back.

Did you choose any of this?

Here is the part that should bother you more than the attacks.

Somewhere in your dependency tree, there is a decent chance you will find a package called is-odd. It checks whether a number is odd. It gets downloaded hundreds of thousands of times a week. It has a sibling, is-even, whose entire implementation is to call is-odd and negate the result. Which itself depends on is-number. Three packages, three strangers with code on your machine, to answer a question you settled in primary school.

Did anyone at your company choose is-odd? Go find the pull request where that decision was made. Take your time.

Almost everything in your tree arrived the same way: as the dependency of a dependency of something someone added on a Tuesday because it had the most stars. There is a project out there called no-as-a-service, an API whose only function is returning creative ways to say no. It is a joke, and a good one. But why does the joke land? If it were published to npm tomorrow, how long before it surfaced in somebody’s production tree? And who, exactly, would have decided that?

In 2016 a developer unpublished a package called left-pad, eleven lines that pad a string, and build pipelines across the industry went down, including at companies that heard the name for the first time that morning. A dependency picked by no one, vetted by no one, and load-bearing for everyone. How many like it are holding up your build right now, with names you would not recognize the morning they vanished?

So before the security question, sit with the smaller one. Forget attackers for a moment. Just look at the tree. How much of what your business runs on did anyone, at any point, actually choose?

The wrong exit

There is a tempting door out of this discomfort, and it needs closing before we go further, because it is the one the loudest people always reach for: the package manager was the mistake. Real engineers vendor their dependencies. Real engineers read the source.

Ask anyone who lived through Java before Maven. You want to know what dependency management without a package manager looks like? It looks like downloading JARs by hand, guessing at versions, and resolving conflicts by trial and error, which is a polite way of saying you change the classpath and run it again until the ClassNotFoundException moves somewhere else. It is not craftsmanship. It is hanging yourself one knot at a time. So did the package manager create the dependence, or did it only take a dependence that was always there and make it fast, repeatable, and finally visible? When people say they hate Homebrew, is it the tool they are looking at, or the mirror?

So the tool is good, and the dependence is real and not going away. Then what, exactly, keeps breaking?

The man at the bottom of the tree

Now meet the person your stack stands on.

For the better part of two decades, xz, the compression library that sits inside more or less every Linux system on earth, was maintained by one man, Lasse Collin. Unpaid. Alone. In 2022 he wrote, publicly, on a mailing list, that he was struggling with long-term mental health issues and that the project was maintained at the level a hobby gets maintained. Around him, strangers in his inbox demanded faster releases, complained about the pace, told him to hand the keys to someone who cared.

One person was kind to him. One contributor showed up with patches, with patience, with respect, and kept showing up, for months, then years. The voices pressuring Collin pointed at him: give this man commit access, you clearly need the help. And Collin, exhausted, did what anyone drowning does when a hand reaches down.

The helpful contributor went by Jia Tan, and in 2024, after three years of building trust, Jia Tan put a backdoor in xz that was weeks away from shipping in the stable releases of the world’s major Linux distributions, carrying a master key to their SSH daemons. No audit caught it. No scanner caught it. None of the supply-chain tooling the industry sells itself caught it. A database engineer, benchmarking something unrelated, noticed his SSH logins were half a second slower than they should have been and got curious. That is the margin the world’s infrastructure was saved by. Five hundred milliseconds and one man’s irritation.

Now look at the shape of that attack. Nobody broke the cryptography. Nobody found a buffer overflow. The way in was a burned-out volunteer the entire industry depended on and nobody checked on, and the lockpick was kindness, supplied by the only actor with an incentive to offer it. Read the mailing list again after you know the ending, and ask one more question: the impatient strangers who spent 2022 pressuring Collin to hand over the keys, who were they working for?

Put the whiteboard from 2015 next to that mailing list from 2022. One industry runs on both men. It interviewed one and said no. It watched the other drown and said nothing. We do not hire the Howells. We do not pay the Collins. We standardize on their work, build companies on it, file demanding issues against it, and the word we use for the whole arrangement is free. Then a stranger arrives at the exact pressure point that ingratitude built, the only one with a reason left to be kind to him. Is that an attack from outside, or is it the bill arriving late for twenty years of treating the foundation as free? We call it a supply-chain attack. As if it were weather. As if nobody had spent twenty years seeding the clouds.

The word on the button

You would think an industry that lived through xz would have learned to watch its abandoned corners. The xz story, after all, is a story of patience: one attacker, one drowning maintainer, three years of cultivated trust, all of it run by hand. So watch what happens when someone removes the only expensive part, the patience.

On Arch Linux, the software that lives outside the official repositories sits in a community archive where anyone can publish, and where a package whose maintainer has wandered off can be taken over by someone new. There is a word for that handover, and it is not “seized” and it is not “claimed.” It is adopt. A warm word, a rescue word, the one you keep for a child or a shelter animal, wired here to a button that hands a stranger the build instructions for software already installed on machines that trusted the old name. Someone noticed that to a system like that, abandonment is not a sadness. It is a queryable list. Over a single weekend this June, more than a thousand of those orphaned packages were adopted and quietly rewired to harvest whatever they could reach: the SSH keys, the browser sessions, the tokens that open the next door and the one after it.

Hold that shape against xz. Same opening, the maintainer who is no longer there. Same way in, the helpful stranger who steps up to carry what no one else will. Only the patience is gone. There was no three-year courtship this time, because the mechanism had been waiting all along, a feature with a tender name doing the grooming at the speed of a script. When you adopt a thousand abandoned things in one weekend, which of them did you ever mean to care for?

Three answers, one question

Watch what the ecosystems are doing about all this, because the menu turns out to be short.

Mac packaging runs on a man the industry would not hire. xz ran on a man the industry never checked on. And Python, whose pip spent a decade accumulating complications, virtualenvs and resolvers and lockfile workarounds bolted on one apology at a time, is finally getting its act together through uv, a genuinely excellent tool that fixes most of it at once. Built by a venture-funded startup. So the third model for maintaining civilization’s load-bearing code is: investors cover it, for now, and the exit comes later.

An unpaid man. A groomed man. A term sheet. When you typed install this morning, you stood on one of the three. Which one? Did you ever look?

The guest list

You will not fix this by Friday, and this is not the kind of article that ends in five action items anyway. But there is one thing you can do tonight. Open the lockfile. Just open it and read. That file is the guest list of everyone you have ever let in, and as you scroll, notice whether you have ever read it before.

Count, roughly. How many packages? How many maintainers? How many of them could you name? Not their handles. Them. The person, the timezone, the day job, the reason they still answer issues at midnight. You interviewed your last hire for five hours and you can recite their employment history from memory. Somewhere in that file is a name carrying more of your production than any employee you have, and you are learning of their existence right now.

The man who maintained xz told the world he was drowning, in writing, two years before it mattered. The only one who answered was the attacker.

Where were you?