Day 1: Manager: “So… what do you work on?” Boris (staring into middle distance): “I improve latency.” Everyone nods. No one knows whose.

Week 2, Boris replaces the build pipeline with something called *Hyper-Schrödinger-CI*. It both passes and fails until observed. QA quits.

Week 5: PM: “Why is the app faster?” Boris: “I removed time.” PM: “From… the app?” Boris: “From the concept.”

Graphs go up. Metrics look illegal. AWS bill drops to negative dollars. Finance sends an email asking if Boris is laundering compute.

Standup becomes surreal. Engineer: “What did you do yesterday?” Boris: “Refactored causality.” Scrum Master: “Blocked on anything?” Boris: “Yes. Reality.”

No one dares touch his code. It’s just one file named `truth.go` with no comments and perfect indentation.

Then one day, customers vanish. Revenue hits zero. The system is too optimized. It no longer needs users.

Company goes bankrupt. Boris is unfazed. As he leaves, he turns back: “I warned you. I optimize endgames.”

The repo still compiles. No one knows why.

Oooof. Following this paragraph is a recipe for age and family status discrimination lawsuits. (A number of states prohibit both, and federal law prohibits the former above 40). Quite possibly sex discrimination lawsuits as well if a court quite plausibly concludes that someone who makes decisions this way will also be averse from hiring women of childbearing age or life stage.

Engineers follow a pareto distribution. In a normal sized team, with a typical hiring funnel, you will have a few high performers, who are responsible for most of the team's productivity. If you can only hire one person from that team, then it is more likely than not that you will hire someone with productivity below the team's mean. At an early startup, this could be a death sentence. Especially since we typically reason and plan in terms of means, so it may come as a surprise that your single engineer is less productive than the mean of most teams that you have worked with.

The other reason (also not mentioned) is that you eventually want to scale hiring. That means that you need to have people, that you have hired yourself, hire more people on your behalf. The best people (A players in the metaphor) don't have imposter syndrome, they know how good they are, and how good they aren't. They want to work with other talent, that makes their lives easier, more interesting, and less stressful than covering for/babysitting other people. It's also the only way they can grow from where they are at. So they can be trusted to hire more A players, out of self interest.

The median engineer (let's call them a B player) often knows about where they stand as well, and often they will have started to diversify their skillset into organizational politics. They intuit: hiring people more competent than them gives them less leverage, and they are pretty good at zero-sum status games, that's their edge. They don't want competition, so they hire C players.

So the reason you want to start with the best is because it's the only way to ensure you can move fast when you need to, and the best way to keep the organization effective long enough to exit. All organizations decay into incompetence, but hopefully you can get yours and get out before that happens.

One of my best hires ever was a VR dev we brought in as an intern. He became the backbone of our Unity/Unreal work, including some genuinely gnarly low-level haptics integration into the physics engine. On paper he didn’t look like the “obvious” pick: he’d majored in English Literature, largely because his (UK) school’s CS track was taught in a way that turned him off (they were still doing Fortran…). But he could build.

After our startup, Improbable scooped him up on the strength of that very real, shippable experience, and he’s now a senior SWE at Epic, doing exactly what he loves.

One practical thing that’s helped me find these kinds of people in startup interviews: optimize for calm + realism. My #1 goal is to get the candidate relaxed enough that I can see how they actually think and code. I often ask them to bring any public code they’ve written and we walk through it together. It’s a great way to surface judgment, taste, and real ownership that don’t show up on a resume.

But this candidate profile is the best anywhere. It’s also a bit like writing an article and saying “you shouldn’t try to buy shares in the most well known tickers, try to buy things that are undervalued but will be great in the future”. Yeah, but also duh.

I’m on HN a lot, and I usually tend to passively browse Who’s Hiring and interesting looking YC ads. Outside of that, I don’t think I would pursue a startup job through job search sites. I would most likely want to find projects I think are neat and start to research and maybe contribute if they have OSS projects, then do individual outreach. I’d probably also start blogging and posting more so people can see if I am a fit for them. Agents may be involved, but only insomuch as I could spend more time doing human stuff like writing, listening, and ideation.

I hope this helps a CTO find a good candidate. I’m personally not on the market right now, but AMA if you want help finding similar folks.

What I've learned: hunger shows up in the interview. You can't fake genuine curiosity about your problems. The candidates who ask the sharpest questions about our technical challenges, not salary or perks, consistently outperform.

The trap is thinking you can identify these traits quickly. You can't. If you can, sell the method for a billion dollars.

I've seen "the best." I've had what could be considered "life changing" success by most metrics (but irrelevant by SV-billionaire standards).

The lesson:

There are, in general, two groups of people you can work with. People that do what they say they are going to do, and people who don't.

People who don't do what they say they are going to do outnumber those that do by 20-1.

If you surround yourself with the first group, you're going to be ok. If you don't, most of your time and your organization's time will be spent not-doing, not-measuring, and not-advancing.

"The best" really is that simple, and the bar really is that low.

Of course, if you do what you say you're going to do, and you're incredibly smart, and you have vision, and (insert whatever you care for here) then yeah, you'll be the "best of the best"...but those things are legitimately not necessary for success.

I think hiring managers are overwhelmed and exhausted and respond much more strongly to something digestible than to something wide-ranging. The tailoring of your CVs and resumes should be much more aggressive than you initially expect.

There also is an interesting paradox in experience and motivation; often the most experienced and best people on paper are unfortunately the least motivated, least hungry - burn out and boredom do their part.

Don't forget surfboards!

This was a great post, Alex. Thanks for sharing! Hunger and high agency are such important traits in every startup hire.

And now I'm not sure what to do, moving forward. Government job? Find some niche in a large institution that won't fret too much if I have 2 sleep-impacted nights in a row? And then there's the current hiring economy... Who is going to hire me if I'm completely honest and admit I'm buckling under parenting pressure but really do want to help?

edit: interestingly, that happens even in comments..

edit 2: ouch, yes, that was some extension.

For programmers, this manifests as some mix of intuition and taste. I've worked with people who have had some especial insight that most doesn't; they don't necessarily "produce" the most, but they make the right key decisions and create the kind of core abstractions and systems that provide a better foundation for everything down the line. Or, alternatively, perhaps they're just preternaturally great at finding and fixing bugs. (My experience has been that really good folks tend to lean heavily towards one side or the other, even if they're solid at both.)

I've written before about how this should change how we structure our teams and manage creative, high-leverage work[1]. The same concept should also change how we find and evaluate candidates, but, honestly, I'm not sure how. Evaluating tacit knowledge and expertise is hard, even for experts!

One thing I've found that works is figuring out a way to show-rather-than-tell that you're willing to do things differently. Doing things differently won't be appealing to everyone, but it will be very appealing to specific kinds of experts! When you can't compete on comp and brand, this is one of the better options. One way to do this is to use a specialized, niche language like Haskell. Alex saw this in action at Freckle and I saw it in action hiring folks for Target's supply chain optimization team. But it doesn't have to be a language specifically; it just has to be something that at least some experts care about, and that you can demonstrate. (Just saying you're doing something different or technically interesting won't work because everybody is saying that!)

[1]: https://jelv.is/blog/Letting-Experts-Be-Experts/