alt Hacker NewsWhat “The Best” Looks Like
Comments
> Seniority here also unfortunately often correlates with age. The best startup employee will usually be someone early in their career who doesn’t have as many responsibilities or as much need for consistency due to having more dependents. They may have fewer immediate cash flow constraints, fewer “adult responsibilities.” Kids need braces and karate classes, and if Mom is doing 996 at a ten-person company paying her peanuts, offering a crappy health care plan, promising an epic payout ten years from now, that’s a real mismatch. Startups are an extreme sport, and generally inadvisable for anybody who’s not in a safe position to speculate on their career for several years.
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.
This completely misses the reason why you need to hire the best initially. It has nothing to do with the hardness of your own company's problems. It has everything to do with the distribution of productivity among any kind of engineer.
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.
Great write-up!
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.
In my opinion as a hiring person at FAANG for almost 20 years, what’s described here has always been the goal. Lots of people work at FAANG who don’t meet this bar because a need to fill seats exceeded the need to hold the line / bar on quality. So tenure pedigree doesn’t say much.
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.
The advice sounds obvious, but execution is hard. The best hires weren't the obvious ones. One of our strongest engineers came from a completely different industry with no relevant experience on paper.
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 built my first company on engineers I hired from the local college by simply asking them to send me students who had clear talent but weren't engaging well in the academic side. We became a local clearing house where we quickly found out whether they could thrive outside of the academic environment. Two of them became "The Best" you talk about. One in DevOps (earns way more than me now) another found his talent in DevEx.
In all humility I think I at least loosely embody those qualities. Right now I’m in a comfy F500 remote job that is stable, and it’s been at a time where stability has been important for my family. There will come a time when I’m ready to start or work at a startup. When I do, I want to find a place where my values are valued. I come to work engaged no matter what, but my work is able to be far more impactful when it comes from my self, not only my work avatar.
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.
Thoughts on finding the hidden gems in early-stage startup hiring.
Lesson it took me far too long to learn about what "the best" is. Bona fides: I'm no titan of industry but I've worked with many, across many industries.
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.
Hunger and drive can definitely lead to unexpected initially results; they cannot replace relevant experience, but if somebody has at least done something similar, it's often worth making a bet on them!
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.
"maybe even a high production value promo video showcasing happy employees, rare wood office counters and a shoes-off policy."
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.
A major part of what makes somebody "the best" is tacit knowledge. This is the sort of skill and "know-how" you can build up from experience and one-on-one instruction, but cannot easily be captured in text.
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!)
Meta, but why does the HN title change the kuril . in domain into just `kuril` here?
edit: interestingly, that happens even in comments..
edit 2: ouch, yes, that was some extension.
I used to be that guy, then I had my first kid at 49 and things have been circling around the bowl since then (he is 4.5; I am... impacted)
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?
My CV is similar to David's and I find myself also having to badger people for the time of day. I have worked in a few roles related to a particular industry for a while and still have trouble convincing people that I'm quick to adapt to the various parts of a large scale ecosystem from R&D to product design and logistics. Even though all the details are on my CV.
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.
These days, best is whoever engages the best with AI. Those who communicate well, with good grammar + detail + nuance + examples + skepticism will do better in the results they get from AI. Of course they have to capable of critically reviewing the AI's output.
They hired Boris on a Tuesday because HR misread “Kubernetes” as “knits sweaters.”
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.