rachofsunshine

I can take a look privately if you'd like, or publicly here if you want broader opinions / to serve as a data point for others.

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.

Some startups (like mine) are delivering a service, and the technology used to deliver that service is instrumental. Our back-end is an Airtable I configured myself, and it's been sufficient so far; better tech is not make or break for what we do. Other startups, like Flexport some years ago, fundamentally depend on technical function because that's the core of what they do.

One of the common mistakes founders make, in my expetience, is not asking which camp they're in. It's not a hard question to answer (usually), but it's an easy one not to ask.

I very intentionally did not write anything about finding engineers who are just good at the things you care about and not at other stuff, because every bit of data I have says there is a considerable component of general engineering skill underlying most eng roles. No, it isn't totally one dimensional, but (in a principal-component-analysis sense) it is fairly low-dimensional.

There really are just better and worse engineers in the sense that eng A is better than eng B for virtually every job. But that's precisely why recognizing the competitiveness of hiring is important - the more you insist on narrowing your pool, especially in ways others also narrow theirs, the less likely you are to find the rare unknown great engineer.

On the one hand (and as I mentioned in the post), yes, most employers are not as dumb as I'm making them sound. In principle they know they need to comprpmise - but in practice, they often balk at doing so because they haven't clearly articulated what they will compromise on.