Rationality on an individual level is not the same thing as what produces the best long-term outcomes for both parties. On an individual level, bringing up comp immediately significantly reduces your chances of being moved forward. It shouldn't, but it does.
This is a specific application of a good general principle. Big companies need to watch for failure modes. Small ones need to watch for success modes, because the default is always failing.
We can. That's kind of the entire point of our business. Check back in a week or two - we've got another blog post on some of our interviewing data in the pipeline.
Yeah, so did I. Being both a ride-or-die leftist and the owner of a company is a weird place to be sometimes, and it's basically the way I figured I could best implement the world I want to see inside the world we have.
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.
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.
It doesn't even need to be "good enough". People SHOULD be picky about founding engineers. But they should be picky about HIRES, not about top-of-funnel proxies for skill.
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.
There is some truth to this, but I would argue (with a considerable amount of data on both assessments and hiring behaviors) that it is less true than people might like to hope it is.
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.
And, more to the point, that they'd hire a _better_ imperfect candidate by taking those four months doing tough interviews with lots of imperfect candidates (rather than hiring one in desperation later).
The market is definitely not dead. It started warming up last summer and has continued to do so throughout 2025.
But the market is two-tiered in a way it hasn't been before, particularly w.r.t. remote hiring. Almost all engineers want remote jobs and a small number of employers offer them, so the remote job hunt still puts employers in the driver's seat. But (good, senior) engineers hold the cards right now for in-office roles.
Author of the OP here - to put some more empirical backing to this, virtually every single engineer in our candidate pool values illiquid equity at 20% or less of face value, and about one in three give it no weight at all.
Totally off the topic of the thread, but it's why I do things differently with the people who work for me. I'm the sole owner of Otherbranch, but I pay out a percentage of profits over certain thresholds (between 25 and 75%, rising at higher levels of profit) to the team. Keeps things concrete and aligns incentives with building something that works today rather than obsessing over a hypothetical exit.
The argument here isn't "the goal of a software engineering job isn't economic", it's "sometimes quality is aligned with economic goals" (which is of course true).
If there's a 10-point scale from 0 = the most hacked-together nonsense and 10 = perfect formal proof of correctness, I'm arguing that a lot of engineers should come down from a 9 to a 6, not to a 0 (or at least, that they'd benefit from picking their battles about when to argue for a 9).
In business contexts, I often argue the opposite, trying to move them from a 3 to a 6, because nontechnical people often underestimate the importance of tech debt. That's not a typical problem on HN, though.
The quality of your team is more-or-less a pre-existing background variable. The question is whether a team of comparable quality takes longer to produce quality software than hacked-together software, and the answer appears to be "yes". The only way out of this is if optimizing more for code quality *actually helps you recruit better engineers*.
I can put a little data to that question, at least. I run a recruiting company that does interviews, so we have data both on preferences and on apparent skill level.
I went and split our data set by whether an engineer indicated that emphasis on code quality was important to them. Our data suggests that you can probably make slightly better hires (in a raw technical-ability sense) by appealing to that candidate pool:
- Candidates who emphasized quality were slightly (non-significantly) more likely to pass our interview and,
- Candidates who emphasized quality were slightly (non-significantly) less likely to have gotten a job already
The effect is pretty small, though, and I doubt it outweighs the additional cost.
It doesn't happen because building the best software is not the goal of a software engineering job.
If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.
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.