I was prepared to straight up fight with this author until I actually read what they were saying:
1. Don't hold infeasibly high standards when you're starting up. Time is more precious than than anything (you can't spell "scrappy" without "crappy").
2. Be more intentional than a lottery-ticket financial plan when it comes to evaluating what traits matter and at what priority order. If everything is a priority, nothing is a priority.
3. Recognize market dynamics. If you pay shit for shit hours to do shit work, you'll get shit unless you just get lucky.
4. Hire great people now, rather than waiting for the "best" (read: naively idealized) people.
To this, I'd probably want to see the author add another essay on the perils of hiring mediocre people (Jobs: bozo explosion, Rumsfeld: "A's hire A's, B's hire C's..."), because that's the very common company-killing pit that people are trying to avoid.
Mediocrity drives away talent, and a small team of talented people will absolutely smoke a large team of mediocre people. And therein lies the conundrum of startup hiring: what's the right balance?
I don't know anything about the story of Otherbranch's business (they launched ~about a year ago†), but Patrick, Erin & I briefly worked on a firm with similar business dynamics (Starfighter, a contingency recruiter based on CTF qualifiers). The prospect of eventually writing posts like this is part of why that business got wound down.
I think the points in this post are mostly all well taken, but I also think a hiring manager looks at this and says "yes, this a vendor talking their book". Most of the relationship between a recruiting firm and a tech company is a disagreement about what the threshold for a viable candidate is!
Yeah, to some extent you have to be willing to deal with this stuff in recruiting, which is why I've taken on the clients under discussion at all.
In my Triplebyte postmortem (also on the blog), one of the mistakes I talked about was that Triplebyte was aggressive about trying to dictate terms. We told people how they had to hire.
Otherbranch takes a softer approach: if you ask for my opinion, I'll tell you what I think. Otherwise, I'll do my best to find you what you asked us for, with the understanding that some sets of constraints reduce the probability of success to ~zero.
That goes on the candidate side, too. I get a fair number of people who will come in and tell me "I only want a remote job where I can take a day off whenever I want and only want to work on a super clean codebase and also get paid 250k a year" - and those people are almost never going to end up with jobs. But the tradeoffs they want to make are their business, not mine, until they ask me to do otherwise.
Even if we had perfect filters to accurately identify the best talent, there's not enough of the top few percent to fill all the spaces in the industry, so someone is going to be hiring mediocre talent or forgoing having a business.
In the real world, though, we don't have perfect filters, and churn has a cost, too, so in practice most places are going to derive value if they can make effective use of mediocre talent rather than just letting it increase their churn.
(Moreover, one of the effects frequently claimed from great talent, employed effectively, as noted upthread, is not just their own direct output, but increasing the yield from lesser talent; if you don't hire any lesser talent in the first place, you can't benefit from that.)
Because you're solving mediocre problems for terrible pay. If you want to solve the world's toughest problems for terrible pay and can meet the bar, there are other places with a very happy customer, stable careers, and great benefits.
In my experience, that is what contractors are for; grind through the blergh B and C tier tickets. You can have onshore developers do that but a lot of companies seem fine with offshoring those tasks.
Because you have a mediocre job to do. If you hire excellent talent, you have to pay excellent prices. If you only have mediocre ROI tasks for said talent, then you're reducing the ROI of the task by overpaying for better talent.
Finding "the best" is very hard. You get such a small glimpse at a person from their resume and the interview process. Then good luck getting them to join you instead of another job that can pay more, give better perks, or whatever. You put in all that time interviewing, spending all that money, and look where you work, is it really all that effective?
If your company requires the best then you most likely have too much complexity. If your company requires the best to continue then your company isn't stable. Even if you got the best, can you keep the best? If you argue that there are enough "the best" then really you're just calling average (or anyone just above average) the best
The world isn't full of A players. Too many B players won't listen to grow even if they have the abilities. All you can do is help them discover their potential and that it's worth.
Because sometimes you know how to decompose a problem very well, and some problems are the nice kinds that have a nice horizontal scale-out for mediocre talent.
I think the post is getting at the idea that pedigree is not a reliable predictor of talent, but because it's a convenient and standard one, everyone uses it (which in turns reduces its usefulness). It's harder for a recruiter to fully experience the perils of hiring mediocre people, but they're definitely at ground zero for "what's on a resume is mostly not representative of actual talent".
Hire people who are going to do their best work ever, for you, after having partially but not fully mastered everything you want, via their previous jobs. It's easy to evaluate a resume. It's harder -- but not impossible -- to assess potential. Working inside a big tech company for six years, I saw that PM hires were done almost entirely on pedigree: find me another Stanford grad. These tended to produce a lot of fast exits as well as some comically bad and totally predictable fails.
Engineering hires were done on hunger, drive, scrappiness (and networks). They fared better.
It is possible to do leetcode without practicing, even before AI. That said the structure of the Big Tech process is also quite long/multi-step with many opportunities to give up during, which helps select for drive. It's hard to do this effectively with shorter processes. It is however always a good practice to 1) design very hard interviews but 2) give a lot of preparation to candidates beforehand, even for non-leetcode interviews, as it helps filter who can efficiently and diligently use provided information to increase their performance.
>It is possible to do leetcode without practicing, even before AI
Back when people did in person interviews, people were writing psuedocode on whiteboards, so knowing the right algorithm and being a strong programmer was necessary, and I can see how one might not need to practice.
However, with the move to online interviews where people are expecting running and debugging some complex solutions (so you cannot hand wave trivial but potentially time consuming helper methods), coding speed can easily become the bottleneck.
> 2) give a lot of preparation to candidates beforehand, even for non-leetcode interviews, as it helps filter who can efficiently and diligently use provided information to increase their performance.
Yes, this reminds me of the netflix interview process where they told me to read the culture packet thoroughly, then quizzed me on it! It was quite easy, but you can bet that a lof candidates don't take that seriously.
Those things are fakeable, but there are plenty of people who will aggressively signal a LACK of hunger. It's more of a negative predictor than a positive one.
Verifiable evidence of them learning key new skills on their own, building passion projects (ideally somewhat comparable to what your startup needs), taking work to the finish line, etc.
Press (politely) for extra details via follow-up questions. Make it easy for the legitimate doers to share specifics of what they've done and learned, while the posers get vague in a hurry and change the subject.
Again... You don't need the "best" engineers to develop some crappy derivative app that probably already exists. 99% of the stuff people are trying to build these days requires nothing more then a few competent engineers.
In fact sometimes hiring "Really Smart" people leads to excessive complication via overactive abstraction as the intellect searches for some way to make your boring problem interesting (to them) :-)
Good software is made by motivated people working with a shared vision and with good communication skills. Coding talent and raw CS genius frankly I feel is almost the least part of it, especially since most of these "innovative" startups are mainly gluing together other people's work at this point.
If you don't have people excited about what they're building, talking to each other and liking or at least respecting each other, it's game over.
1. Don't hold infeasibly high standards when you're starting up. Time is more precious than than anything (you can't spell "scrappy" without "crappy").
2. Be more intentional than a lottery-ticket financial plan when it comes to evaluating what traits matter and at what priority order. If everything is a priority, nothing is a priority.
3. Recognize market dynamics. If you pay shit for shit hours to do shit work, you'll get shit unless you just get lucky.
4. Hire great people now, rather than waiting for the "best" (read: naively idealized) people.
To this, I'd probably want to see the author add another essay on the perils of hiring mediocre people (Jobs: bozo explosion, Rumsfeld: "A's hire A's, B's hire C's..."), because that's the very common company-killing pit that people are trying to avoid.
Mediocrity drives away talent, and a small team of talented people will absolutely smoke a large team of mediocre people. And therein lies the conundrum of startup hiring: what's the right balance?