You don't want to hire "the best engineers" | Hacker News Reader

You don't want to hire "the best engineers"

otherbranch.com

394 pointsrachofsunshine319 comments

There is no such thing as "the best engineers." Some engineers are definitely better than others, but once you pass the bar of "really smart, great work ethic," the tech tree diverges pretty dramatically.

Some engineers (like Notch) are amazing at quickly putting out vast quantities of mediocre code, prototyping ideas, maintaining a clear product vision, and bringing something into reality quickly. Other engineers (like John Carmack) are great at generating well-founded opinions and finding clever solutions to difficult issues. Some engineers (like Bill Atkinson) worked mostly remotely and developed amazing technology, while other engineers (like Joel Spolsky) insisted on in-office and built a best-in-class mentorship organization.

While hiring people with exceptional talent is a step-change when it comes to any organization's ability to accomplish its goals, there is no one metric for "best." Much better to identify the specific skills for which you need exceptional talent, and to create a hiring funnel that identifies people who excel in that dimension.

That sounds like you’re talking about distinctions within “the best” to me.

Except if you put any of the above names in an environment that doesn't suit them, they will likely be mediocre at best, and even damaging at worse.

The “best candidate” depends a lot on your existing organization.

> Except if you put any of the above names in an environment that doesn't suit them, they will likely be mediocre at best, and even damaging at worse.

In the immortal words of Jobs, "real artists ship". Those names are well known precisely because they have a proven track record of shipping products - very few of those would let a challenging environment get in the way of shipping.

That said, as their employer, you may well not like the way they go about it. Name-brand engineers don't take shit from management, and if you get in their way, they won't be shy about airing that publicly.

> In the immortal words of Jobs, "real artists ship".

Art is an individual endeavor, most of the time engineering isn't.

Management is though, and that's why individuals can make or break a product, iif they are in a management position. And being an excellent engineering manager doesn't even necessarily mean you need to be an excellent engineer, and vice versa.

Yep. Existence of "the best engineers" would imply existence of The One True Metric by which you can judge the person in all context; but that's at best an oversimplification.

The actual metrics (not necessarily easily quantifiable) are the desired traits you put in your job description; they don't correlate perfectly.

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.

Totally agree with this. I'm in consulting, where there's a significant client communication component to most of our eng roles, so it's a slightly higher-dimensional space than engineering for product orgs. Still, there is a pretty powerful "g factor," where someone who excels in one dimension will probably be pretty good at all the other dimensions.

Still, when we're staffing, there's a world of difference between the great engineer who is happy being mostly left alone and writing complex but well-specced SQL queries for 12 weeks and the great engineer who can balance software architecture, customer meetings, and programming for the same project.

It's all about personality and attitude, anyone can learn to become a better engineer than they were yesterday. The issue is, do they have the resources to do so, are there incentives? Are you making sure they're fully equipped to give you their best? That includes everything from offering training to even benefits, overworked engineers will make mistakes sooner or later.

One can always train for knowledge and skills, attitude is much harder.

It is definitely doable if you have a good mentor / role model you admire. I change a lot in my early to mid 20s because one of my uncles took the time to have one on one convos with me to give me feedback on my behavior and why I should do x, y or z instead. It was like I was a completely different person a year later.

Senior Software Engineers should not promote bad habits to juniors.

Absolutely can be developed, takes buy in from both sides.

Unfortunately in tech either seniors aren't available as they should be everywhere, and juniors can.. sometimes.. prefer.. shiny object syndrome and re-learn everything from scratch, until they realize they aren't the first and that's a great thing that will help them go much further, quicker.

Sometimes I'm just happy to avoid the worst engineers. They do exist. Bad work ethic, poor foundational skills, hard to work with. I feel that if I can weed them out, I've done 75% of my job as a hiring manager.

So much this. As I've been changing teams at my company (which by and large has awesome people) there is the occasional person in the team that just drags down the rest so much, they are probably a net negative. And it's such a breath of fresh air when the whole team is excellent.

So true. Anyone who isn't wanting to be a self-directed learner misses the essence of working and growing with technology.

Yes, essential to protect the broader team from low performance and toxic colleagues. The trick is to get the disruptive folks off the team quickly without causing the productive folks to doubt their job security.

Clear communication and transparent accountability are the way.

Reed Hastings and Erin Meyer talk about this right at the start of No Rules Rules. Netflix had to lay off a big chunk of of their staff because of a funding crunch early in their history. Despite the negative emotional toll that took on everyone, productivity actually improved.

The authors reference a Will Felps experiment[1] that showed that introducing just one pessimistic, lazy, or mean actor into a group of professionals cut the entire group's productivity by 30-40%.

As a result of this lesson, Netflix now only hires "A-players" and is pretty aggressive about letting go of "B-players" and "C-Players."

[1] https://www.thisamericanlife.org/370/transcript

This has been borne out in real-world observational studies, too: https://www.washington.edu/news/2007/02/12/rotten-to-the-cor...

I think the hard part to figure out is how to fire those people without causing a lot of unintended consequences. I have been through layoffs 6 times now, and what I have seen often times they are high up in the food chain with a lot of power, and lay offs are pretty random because they are not telegraphed to everyone so you lose good people.

The people in power circle the wagons around their preferred cliques, because they don't care about the business succeeding nearly as much as their buddies (because there's always the next job.)

Then often the folks are left to do more work with the same pay and the impression that a random draw occurred and they lucked out, nothing more. It really can sour previously hard working folks and have them become that employee that you then think you need to get rid of.

The truth is that most companies are not made of "only A-Players" and that its basically impossible to staff such a company, so you need to limit the damage anyone can do, create systems of checks and balances, reward brilliance and have clear objective levels of work people need to meet to keep their jobs.

Right, what you need are a, b, and c players- and no d or f players.

I think most significant sized operations are built and succeed or fail based on the quality and leadership of the B players. You just can't find enough A players to build an entire [large] company of them and hopefully the C players contribute in a steady, no-drama fashion, leaving the B players* as the differentiating aspect of your particular company.

* - and the focus/determination/consistency with which you part ways with the D and F players.

> You just can't find enough A players to build an entire [large] company of them

The corollary to this is that too many real super star players can hurt a large company, especially if they're too close to each other. They need to be spaced out and inserted into the right places at the key moments when there are critical challenges they are uniquely suited to solve. Super heroes generally make lousy mayors.

Super heroes are able to conquer insurmountable Cthulu-grade existential threats. But that often involves doing things you wouldn't normally do and can cause collateral damage. Fortunately, such threats are fairly rare. Of course, many people who use the term "A players" are really just referring to "good people" not true super stars.

A wise F500 CEO once told me there were only about 20 such super stars in his >10,000 person organization but he shared it more with a tone of "thank goodness there's only about 20 of them" because identifying them and getting them onto the right problems was a constant challenge. He didn't think the organization needed more of them, it just needed to better manage and direct the energies of ones it had - and by direct, he meant "direct it outward" on a massive, high-value problem - not inward laying waste to the day-to-day structures that keep the org running.

That’s an unusual definition of superstars. It sounds like you’re talking about very lopsided people who are experts at one thing?

That is what people typically mean with superstar, a person exceptionally good at a thing. A superstar basketball player doesn't necessarily come with a good attitude, same with movie stars, they don't always deliver great results if they are unhappy with their role.

What do you think superstar means? That they are good at everything? Nobody is good at everything. A superstar programmer is probably not a superstar manager etc, not is he a superstar football player.

Also the more sought after you are the harder it is to stand bullshit, so generally superstars are more fickle than average workers. They don't get more irritated, they just don't hide it as much because they have less reasons to.

This means if your job involves a lot of bullshit then a superstar will likely perform worse than an average worker and will quit soon, since superstars tolerate less bullshit. That doesn't mean they are not a superstar, tolerating bullshit is generally not a part of being a superstar in most peoples definitions.

Anecdotal comment here, Netflix had the best interview process of any company I’ve applied to in my ~20 year career.

Very challenging, but no tricky questions, it felt collaborative and low pressure (comparatively at least) and everyone seemed like someone I would enjoy as a coworker.

What kind of process was it?

Pretty typical big tech process, just done in a very good way.

I had an initial screening where I had to write some code, write a test case, run it, then discuss how i'd parallelize the algorithm (didn't have to write this part). The code wasn't tricky, but I was glad I had practiced writing code quickly as general interview prep.

After the screen was an algorithmic coding round, but it was enjoyable and nothing that couldn't have been solved with some basic data structures and recursion. The interviewer was talkative and was happy to brainstorm as I talked through my solution, it felt like pair programming where I was driving, not just me being watched while I coded.

Then I did two system design interviews and an "HR" type interview/culture fit one.

I also had a 'practical' coding interview that again was challenging but really just some basic data munging. They gave me some (simplified) data structures and a simple version of a problem Netflix has to deal with, then I had to rearrange the data to the right format.

Again, not tricky, but needed lots of thought, they made me run code, and I was glad I had done practice interviews.

Finally, I was scheduled to the final round of the senior manager team interview, but by then I had accepted an offer for a team I liked at Google.

Google also had a really nice interview process except it took 4x as long.

Ironic considering Netflix content is mostly F-level junk these days.

Not really. The quality of engineering has little to do with the quality of content.

Their problem is that the quality of engineering started off being critical (who cares how good the content is if you get endless streaming failures?) and is now not so important.

Maybe an investment in "A-players" for streaming stifled cultural diversity and kept engineers from being able to innovate on novel media formats where they are losing engagement of the younger demographic to TikTok and other social media video formats.

The same corporate strategy and culture that hired "A-player" engineers for streaming is hiring "A-player" studios for content.

Defining A-players as such means you've set the rules of the game instead of building a culture of adaptive success criteria to meet customer opportunities. The label itself is a function of organizational ossification. This is the likely legacy of our tech giants; innovative in only one direction and not able to change fast enough to avoid becoming a brittle, mediocre institution over time.

As consumers, we can all feel this ossified mediocrity every day.

I think this is an important distinction too. It's not skill level or how fast you can code something. It's attitude. How you work with others. How you communicate (at all? Because many people don't raise their hand for help or clarification like at all). How motivated you are to learn and grow. How well you follow a process. Etc.

That's what makes an A player. I manage a bunch of programmers and I'll always hire and keep those who want to be there and want to learn over those with "skill." In fact, I find many junior engineers who outperform senior engineers. All the time. Because they're present. They're there. They care. They're careful. They learn. They're dependable and accountable.

I know it may sound silly, but it's really true and I think a lot of people are surprised.

One consistent red flag I look for after the hire is a refusal to learn anything outside their own narrowly defined scope.

Do you mean outside their job description?

Most job descriptions contain some version of "other duties as assigned", IMO with good reason.

No job description can realistically capture every responsibility; this language helps prevent bad-faith disputes when new tasks or responsibilities arise that aren’t explicitly mentioned but are 5 millimeters away from those mentioned and entirely reasonable to be considered as in-scope for an existing employee.

I think also it's the reality in most engineering roles that you will often have to pivot to new technologies, help out on unfamiliar projects using different technologies (e.g., work on the front-end for a bit when you're a backend engineer), etc. Some engineers aren't comfortable with this and it shows. This is how I understood the original comment, anyway.

Anecdotally: People who aren't flexible about their job description are some of the worst people to work with. They always leave the tough unforeseen challenges to their colleagues to handle. Kinda the definition of "not a team player".

As an engineer, I had a job at a small company where I sat by the office phone, answered it sometimes, and had to get the door for deliveries. Not in my job description, but it needed to be done.

This is under-appreciated, very rarely talked about, and spot on!

I am personally guilty of being far too lenient and tolerant in overlooking "hard to work with". Bluntly, as an engineer, I enjoyed working with a few particular "brilliant assholes" (as their brilliance was often but their AH nature rarely directed at me) and so I tended to tolerate them too much when I transitioned into leadership roles. I don't know if that was biggest mistake as a leader, but it was for sure in the top five.

I agree. I'd argue for an additional "generalist" category, as well. Generalists won't be famous, like the exceptional specialists in your example, but an excellent generalist will be able to do good work in any situation. They will be highly valued by their teammates - though often not, unfortunately, be much recognized by management.

And in most startups, you desperately need a generalist among your first few hires. By all means make your founding engineer a specialist in your specific field - but right after that hire, you need a generalist who is going to knock out all your infrastructure, devops, tooling, testing, and team processes. Otherwise your specialist is never going to have the time to do their thing.

100% agree that there's a lot of diversity in what makes the engineers good. My only quibble is with the conclusion: "identify the specific skills for which you need exceptional talent". Any of these people would be great for your company. When you're small, you can be flexible... if you can get any of those archetypal great engineers, get them and adjust your workflow to work productively with them.

There are likely still some more universal aspects of good engineers.

Curiosity, resourcefulness, empathy, being user-centric are all things to never stop developing.

> Curiosity, resourcefulness, empathy, being user-centric are all things to never stop developing.

those qualities were over-developed by e.g. the cenobites

Err I don't think that's exactly true to say there's no such thing as the best engineers. There's very few who would be capable of solving problems that someone like a Jeff Dean is able to do. Realistically though, not every company needs to solve problems of the difficulty that Google has.

What are you talking about? Clearly they are all cracked engineers and anyone not cracked is cooked like this take.

God i hate the tech world these days.

You're missing the most important kind of great engineer: the guy who's got adequate technical skills but fantastic executive functioning skills. A lot of bright engineers target the "fun" problem or will otherwise get distracted, leaving a lot of simpler tasks ignored. Every team needs the dev who opens up Jira, opens a sorted list of tickets, and just knocks them down one by one, all day every day. Without them, the product will crumble slowly around an increasingly amazing and elegant core.

Eh, with good leadership who knows how to support different people with different motivations, you really don't. But good leaders are even harder to find and hire than good engineers.

And they probably won't use Jira. Or tickets.

Good leaders are great communicators and if they don't write anything down I wouldn't consider putting them up as either.

JIRA is so dysfunctional in many places that people do a good chunk of intra-team planning in spreadsheets and docs instead, and use JIRA sparingly to make everyone faster.

I saw this effect live at my previous big tech after they moved to JIRA. JIRA got used way less than Phabricator because of all the friction it introduced and a lot more informal google docs + slack bot usage increased instead.

I remember to this day asking a report to plan more stuff in JIRA and seeing a beautiful task tree in Phabricator they did in the past. I asked why, and he shrugged and said it was just easier. That's when it really clicked for me. Linear can't come soon enough and burn JIRA to the ground.

I think the core error is marrying a communication tool for the people doing the work, to a reporting tool for people who aren’t doing the work.

Managers are all about that kind of automatic hyper-legibility (I’m skeptical about that being worth anything like the investment most companies put into it to begin with, but that’s another topic) but all it does is shove important communication into side-channels and make the ticket-tracker an extra chore, not a work aid.

Like if you’re often having to hound developers to update tickets (a thing in every single place I’ve worked) they clearly aren’t finding them a useful tool for themselves. You’ve wrecked that supposed use-case, it’s ruined.

It’s also the case that trying to serve both purposes, and in fact strongly favoring the PM + management use case, tends to make the UI for these things terrible for developers, contributing to their avoidance of them—the people who, ideally, would collectively be spending far more time in the tools than anyone else, are second-class citizens as far as those tools’ features and UX.

I was the manager in this case, and I also hated JIRA with a passion. It's often the managers doing the alternative spreadsheets too and only using JIRA as necessary. I found you didn't need to "hound" developers with Phabricator and part of the hounding was me being hounded further up about it. Tools matter! Developers love automated organization!

As a side note, as a developer I’ve never understood why other devs find updating tasks so hard. It’s super easy and makes you look good, and if I’d worked hard and not updated the ticket I can imagine that from my managers perspective it looks like I haven’t done much, that’s bad for me and I would get anxious and not want that. Should be simple, right?

It depends strongly on how it’s used. If you just use it for specific things it’s fine, trying to do everything in JIRA sounds like a terrible idea so why would anyone do that

There's a massive difference between "don't write anything down" and "don't use tickets". There are lots of (much better!) ways to write things down and to communicate than tickets.

More importantly, there are categorically better ways of understanding what we're working on than trying to break work down into bite-size linear "tasks".

Using JIRA isn't really the issue on its own. It's walking around with blinders thinking that tracking things in JIRA is how work gets done because it's invisible to you otherwise because you don't have your ear to the ground listening to your staff and finding out what's happening because you expect it all to be in the ticket tracking system.

The map is not the territory, etc. etc.

The worst managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and everyone was confused about when and where their next task would come from. The answer was usually “they’ll message you at any time with a random request and demand a deadline at the same time”.

Jira helps turn terrible managers into mediocre ones, it at least forces them to write down what needs to be done and let’s me prove I’ve done the work back to them later when they inevitably forget.

The best managers I’ve ever had didn’t use Jira, because they didn’t use much of anything at all, and more senior engineers were trusted to manage work streams and run projects without needing to conform to a process demanded by someone not directly committing code.

Jira might turn terrible managers into mediocre ones, but it also turns good managers into mediocre ones too.

How did those senior engineers assign and track work to less senior devs in the team in your case out of curiosity?

Depends - sometimes with simple Jira boards, sometimes with other tools like Smartsheets or Air Table or a simple spreadsheet, sometimes with post-its and a white board, sometimes with no system formal or otherwise. My point is less about Jira specifically and more about tool/process dogma (although I do think Jira is the tool of choice for most “we must used the Agile Toolkit Scaled Enterprise Framework Productivity System MegaProcess for all things!” types than others, mostly because of having been around forever and because of Atlassian pitching organizations to use Jira workflows for compliance as if it were uniquely capable of tracking when someone clicked a button in a UI).

Fair enough, thank you!

One way is for senior engineers to give junior folks well-defined areas of responsibility, and then not worry about assigning and tracking small tasks within that. The more senior folks explain and motivate what we need and talk through what the interfaces around the area are and how it fits into the broader work of the team, then help as-needed.

Instead of trying to "track" work in terms of tasks, you keep up with the state of the system by understanding the state of each area. Which is pretty natural to do since you'd be helping with design discussions, code review and some pair programming and debugging.

You can get a lot done by talking and by looking.

This sounds really interesting, I bet it’s tuned to work really well for many engineering problems. I can imagine however that for certain company structures it would be a difficult fit.

IMO you need all types. A well-functioning team has people with different strengths that can get pathological when they go too far, and they cover for each other's strengths. The "just do it" high work ethic guys like that are great, but they can sometimes "just do it" in the wrong direction and don't stand back and ask if we should even do these things. "Mr. strategic" can sometimes stand back a bit too much and overthink things, etc.

Totally agreed. I feel like companies are always looking for engineers who can do both, but in reality, a good engineer CAN do both, but they tend to excel and thrive in one or the other.

You're 100% right but the mistake certain kinds of managers make is basically selecting (in performance review or in hiring, whatever) only for that kind of person.

You might get lucky and get the "creative genius engineer who is also an organizational freak who lives to squash JIRA tickets" ... but you also... might not.

The ultimate job of good management in a competently hired software development team is to uncork the potential of team members by finding the things stopping them from being productive, and getting rid of the blockage. Finger pointing about ticket tracking and demanding paperwork ... will not do that, at least not for everyone. For some class of team members the best thing management can do is find some way to accomodate their idiosyncracies.

This is assuming everyone is motivated. I assume most of us are only at work doing what we do at a "startup" type place because we like it and want to do good work. But not everyone agrees on how good work gets done and how to get there.

Too many people go into management for the status or control. In my experience, a good manager is more of a coach than a "boss".

I know that guy, he’s me. Gotten me further than some brilliant but eccentric developers I know.

God bless you. I'm not one of y'all, but if I ever started a company, you'd be hire #1.

Thank you kindly!

Hey me too! I was actually surprised to learn that most developers aren't the type to just plow through a list of Jira tickets. Like, I thought that was the name of the job for engineers. Apparently not!

I don't think either type of engineer is better or worse than the other, but I do believe, as someone else mentioned, that both types are absolutely necessary to a team.

Guy?

So, when I interviewed at all the top tech companies, they all had 4+ technical rounds and one behavioral round, not the inverse.

So either you're correct, or all the top FAANG companies are...

this. high performance is idiosyncratic, based on context and many other factors in dynamic environments.

> There is no such thing as "the best engineers." Some engineers are definitely better than others, but once you pass the bar of "really smart, great work ethic," the tech tree diverges pretty dramatically.

Sure, but I don't think that's the point of the article.

The point of the article is that startups always claim they only hire "the best" (by whatever metric), but they actually don't, because they cannot pay for the best, nor accommodate their needs and opinions.

They actually want "good enough" engineers, not "the best". Again, the precise definition of "best" is not the point; we all agree it varies (though there are some common elements to all the best engineers).

Far from being upset by this, I'm thankful: I know I belong with the "good enough", definitely not the best :)

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.

this is a lot like the debate over IQ. there is no single measure of intelligence. humans have a broad array of different capabilities with every individuals capabilities sitting somewhere on a spectrum compared to the overall population. some capabilities are highly valuable in particular contexts and so people who are entirely focused on making money over-focus on the capability set that they believe translates into making money.

the people doing the hiring want to hire someone with capabilities they lack (which is why they are hiring in the first place) but then also expect that they will be able to exploit the person they are hiring in order to gain an excess share of the profits they create. the idea that you can hire people for their logic and math skills and expect that they won't be able to calculate their own value is a bit of a paradox.

Notch, Carmack, Spolsky may have engineering in their skillsets, but they are also product (game) designers and executives (and world class ones at that). I don’t think that’s really what people want when they’re looking to hire an engineer for their startup.

As for Bill Atkinson… looking at his Wikipedia page, looks like he was indeed a top notch engineer in the 80s, but doesn’t seem like he worked on anything noteworthy after that? Definitely not in the same league as the other 3 IMO.

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 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 on the way up.

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.

Do you have any advice for how to suss out someone's hunger, drive, and scrappiness during the hiring process?

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.

I suspect part of the reason big tech has an arduous interview process is it approximates both intelligence and hunger/drive.

Even very smart people aren't going to waltz in and be able to code fast enough to solve harder interview problems without practicing.

So, people who can pass algorithmic interviews are smart people who also had the hunger/drive to study up/practice some.

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.

Great talent knows how to scale mediocre talent, but you should do so after building that initial core team.

Why ever hire mediocre talent?

availability and cost

Can be financially the only viable option, also they present an amazing opportunity to train up to fit better into your ideal.

Depending on the work, a smaller team that performs better together can often get more done than a larger team.

> Why ever hire mediocre talent?

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.)

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 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.

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.

why doesn't every MLB team just go get Ohtani

Because Zuckerberg or Altman is willing to pay the A players a cool million, and you aren't willing to match that

Should you hire top talent to fix boring bugs? To implement primitive, yet useful features?

Imagine formula 1 team. Should they hire top talent for every position? Like a delivery driver, for example

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.

Ah, spoken like someone who’s actually built a team

In sports, you call them role players and it’s no different when building dev teams

I can’t imagine managing a team full of “best engineers”, sounds like a nightmare

Sometimes you just want solid, competent engineers who can agree to disagree and build what you ask them, in the way you ask them to

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.

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!

† https://www.otherbranch.com/shared/blog/rebooting-something-...

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.

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) :-)

It brings Steve Jobs' quote to mind: "It doesn't make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do"

Companies who generically look for "the best engineers" think their problems will be solved if they can just hire someone smart and tell them what to do. They say they want "the best engineers" but then their job descriptions and interview processes scream "we want someone who will execute our vision exactly as we've defined it."

The best engineers will tell you why your architecture is wrong, why your code sucks, why your timeline is unrealistic, and why your product decisions make no technical sense. If you're not ready for that level of pushback, you don't actually want the best engineers.

  > We hire smart people so they can tell us what to do

Or from Bell Labs: "How do you manage a bunch of geniuses? You don't"

  > Companies who generically look for "the best engineers"

If you need "the best" then your system is (most likely) too complicated and you're going to have a hard time keeping "the best" as their work becomes frustrating.

  > The best engineers will tell you why your architecture is wrong, why your code sucks, why your timeline is unrealistic, and why your product decisions make no technical sense. If you're not ready for that level of pushback, you don't actually want the best engineers.

I want to stress how important this is. An engineer should be grumpy. The job is to find problems AND fix them. They don't just complain but argue why it should be done another way. They complain about what seems like petty things because they understand that if a big problem can be broken down into small problems than the accumulation of small problems creates big problems.

People often conflate phrases like "but what about", "how do we handle", "okay, but" or so on as "no". But these are not "no" phrases by engineers. These are "I'm thinking out loud" phrases.

If you surround yourself with yesmen you've surrounded yourself with people who don't care about the company, they just care about their own survival within it. Unless you're perfect, you need people that are unafraid to challenge management when they think management is wrong. You need people to be able to make mistakes because hindsight is a million times clearer than foresight.

>These are "I'm thinking out loud" phrases.

Not just that, it's also "I want to know what your opinion and reasoning is on this as well" This has often led to some of the most productive conversations of my career.

  > This has often led to some of the most productive conversations of my career.

Same! Often the conversations I've learned the most from are about topics I already think I know a fair amount about but someone mentions some seemingly tiny detail that ends up changing everything. These conversations tend to stick with you long after they're held, as you have to keep updating so many other beliefs lol

Which is to say, collaboration is an incredible tool. You have a lot to gain by knowing others know more than you about certain subjects. This can even come from a very junior person. It's less common, but sometimes they ask a question that they often think are dumb but throws a wrench in everything. (Juniors, speak up. Worst case seniors should use those as teaching moments. Best case, you look like a genius. If seniors get mad, start applying elsewhere (unless you really are holding up a lot of conversations))

>The best engineers will tell you why your architecture is wrong, why your code sucks, why your timeline is unrealistic, and why your product decisions make no technical sense. If you're not ready for that level of pushback, you don't actually want the best engineers.

Then they'll help you figure out how to get where the company needs to be, on a feasible timeline, with the resources available.

> Then they'll help you figure out how to get where the company needs to be, on a feasible timeline, with the resources available.

Only if you actually listen to them. A lot of CEOs seem to forget this step

I'll heartily agree with that but will point out that Jobs was absolutely famous for believing his opinion was the only correct one, micromanaging anything that caught his interest, and routinely chewing people in public out over unimportant details and simple mistakes. So, great sentiment, not a great example. :)

My favorite company I ever worked for was much like what you describe. The management attitude from top to bottom was, here's what we think we need to succeed in this market, tell us what you need to get it done and we will give you the freedom to do it. There was a culture of people fixing small but annoying bugs in between major feature work, prototyping ideas that would make all devs' lives easier, and strong communication within and between teams. You were never chastised for dropping everything to help someone else get unblocked. People were nice to each other and were even not afraid to engage in a little light humor now and again.

It was profitable even throughout the great recession but could only scale to a certain point. So the founders decided to get out at the top and sold it to another company that didn't know what to do with it and most of the good people left when the culture changed to more traditional top-down management.

Jobs: "We hire smart people so they can tell us what to do"

Jobs 10 minutes later: "You did a terrible job because you are a terrible person and you should feel terrible you even exist"

> The best engineers make more than your entire payroll. They have opinions on tech debt and timelines. They have remote jobs, if they want them. They don’t go “oh, well, this is your third company, so I guess I’ll defer to you on all product decisions”. They care about comp, a trait you consider disqualifying. They can care about work-life balance, because they’re not desperate enough to feel the need not to. And however successful your company has been so far, they have other options they like better.

Yep

it's more like short term gain vs long term gain. experienced engineers can design an architecture that will allow you to scale cheaper and faster in the future, at the high initial cost. it will be cheaper to maintain, better for security.

depends at what point your business is at the moment of hiring and what you plan to do with the product. do you need volume or quality (both variants are right)?

If your business is going to cease to exist in 4 months, who cares about scalability? Pay the interest when it comes due and when you can afford it. If someone is serious about building a company they will be okay with that.

unpopular opinion with engineers but unfortunately true

startups are generally moreso a business endeavor than an engineering one, although the engineering must correctly support the business

the engineering begins to take the driver’s seat as the tech debt and cost of scaling catch up to successful companies and begin to create excess drag

but for many years, such companies can typically still afford to throw away money to solve business problems, including these problems of scale

Depends on the business.

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'm in full tech debt black hole right now. Avoid this shit, if at all possible. The excess drag is real AF and is greatly threatening the business.

I’m honestly happy to hear (sorry!) that it matters to someone’s business but the counterargument is of course that if it’s become a threat to the business then it should have taken a front seat sooner….

Sure but then incentivize engineers to hack it out knowing they'll have to deal with the shit show if you become successful. Sorry but most "startup engineers" aren't , and it's basically bad for their careers to implement "the vision" in a throw-away manner.

I don't think it's true that it's bad for your career to do it that way. What happens a lot is we think we have to tell the story of how we gloriously implemented some powerful overkill technical stack in a startup with 4 months of runway to be taken seriously as a Real Engineer.

You can also tell the story of how you worked really hard to engineer a solution that was good enough to carry a startup to viability given the 4 months you had. I would choose the second person over the first person because they have a sense of practicality which is really important. But it can be career limiting to not communicate that in your resume somehow, so I understand how you can think it would be a bad thing. And as always you have to be aware that your employer is in that situation, and so if they don't tell you then you're screwed.

There are a lot of people out there who want to hire practical engineers. It's just a different market and you have to signal differently in your resume.

Let's be real. Most first builds are done by very low talent Indian and Vietnamese developers with zero technical direction. Once the business grows, real engineers and architects are brought in to fight the horrendous, almost laughable, mess to pull the company back from certain failure...without getting any credit.

Yes, this is a very important aspect. An early stage startup needs zero-to-one engineers. People who build fast, aren't afraid to break things, and don't mind YOLO'ing a year of their career on a gamble.

If you find product/market fit before you run out of money... that's when you need to hire engineers who are in it for the long hall. People who focus on reliability and scaling. People who might stick around for 5 years to see if your startup becomes a unicorn.

You know, three years ago I would have said that I can give you a pretty good architecture fairly quickly but if you just want banged-out code I'll be beaten by someone who just plows forward for at least a couple of months... but after some vibe coding I've done I think I could do both at the same time now fairly well. Vibe code very quickly that I also know I can make scale fairly well with not much more effort.

Counterpoint: Experienced engineers will design the architecture that is appropriate for the current state of the business.

The only addendum to this I'd add is the best engineers rarely have to go through the hiring process in a meaningful way, it's usually someone recognizes them from a previous job and vouches heavily for them.

I say this because if you're going through the hiring process like a chump, I'd leave the ego at the door and not talk about compensation or try to demand remote work on a desirable position.

Yes. The more experienced you are, the more your network does all of your job searching for you in the background. (Of course, this assumes you are actively building and maintaining your network.)

I'm not sure it's just a network thing. Certainly you need experience to be a great engineer, but I've known plenty of engineers with 30 years experience who find themselves competing with everyone else when they lose their job.

The best engineer I've ever known spent most of his career doing drivers at Qualcomm. When he left his job they offered him significant raises to stay, offered months of paid leave, and then said he could always come back. Later, an OSS project he worked with heard he was free, and they changed their remote work policies to hire him. He's under 30, and despite working remotely at an OSS project makes significantly more than me.

I like to think I'm a good engineer, but when I work with customers they aren't setting linkedin alerts on my name for if I leave my job. To qualify for what this article is getting at, you really need to be the best engineer out of 100's, not the best engineer in your team of 5.

> this assumes you are actively building and maintaining your network.

Frankly, being a consistent super-star engineer on a team of good engineers, is more important than actively maintaining a network. Experienced founders ask everyone in their small circle of long-time, highly credible, proven associates "who's the best engineer you've ever worked with?" If the answer is interesting, they follow up with "Where are they now?

In my startups, I recruited nearly all of the star engineers this way. In most cases, getting them on board required significant sustained effort. Sometimes just finding them wasn't easy. So - if you're really the engineer on your team who most everyone else would identify as "the best", please don't waste any time maintaining a network. Just keep doing truly great work that others will still be telling stories about over drinks years from now.

If you're not that engineer... then by all means be a reliable, likable, good communicator and maintain your network! Because as a founder, I never had enough high-credibility sightings of "great engineers" in the wild, so I had to mostly build teams out of credible referrals of best "good engineers" and even best "intern or new grad engineers with potential" you've worked with.

This makes sense in a high-churn environment, but some roles are designed so that you rarely work with more than 20 people in a multi-year gig.

This is a good addendum. Do you mind if I add it to the post (credited, of course)?

You can use it, and you don't need to credit me, I don't think it's that unique.

It isn't, but neither is the original post! It's an important addition.

I'm not the poster you replied to, but as a recently retired multi-decade serial tech startup founder of the old-school bootstrap type - the addendum I'd add is what I now teach to young entrepreneurs: Assuming you're a first-time founder whose not playing the high-profile "raise more/spend more drag race" then accept you cannot hire "the best" engineers. You simply don't have the capital or reputation to recruit proven, top-notch talent. So, the only way to win is to play the game differently.

* Aside from a random, serendipitous surprise (which you shouldn't count on), early on the only proven "A players" you're going to have are your co-founders - which is why you chose them and gave them a huge chunk of equity. So you're going to have to get good at the art of hand-crafting a team that can win out of B and C level players. Doing this is hard but it's a tangible skill you can develop if you consciously work at it. They key is developing the knack for spotting raw, undeveloped and emerging talent. Of course, experience over time is the best way to get the knack but there are shortcuts. Always ask your circle of experienced advisors to tell you about times when they've seen someone emerge as a star despite starting from average (or below) expectations. Ask what that future star was like before and probe deeply on this. Ultimately, just being aware this is something you need to do and focusing on it can go a long way.

* Since you can't recruit enough star talent to win playing the game you wanted to play or using the strategy you'd planned, you have to adapt. Be willing to change your game, strategy or approach based on the unique talents and abilities the team you can recruit has. This is how great coaches can still win even with 'B-level' random talent.

* Be willing to accept unconventional, incomplete or flawed candidates if they have above average talent in one or more domains that matter to your unique value prop. Maybe you've figured out there's a backdoor way to win by making a product which doesn't have all the checkbox features but is fr faster than any other alternative at a couple critical things - and your hypothesis is that for some set of customers that will be enough to overlook your lack of features. Then you hear about a dev who's "the best goddamn high-perf optimizer I've ever seen" but after finding and talking to him, you learn he's got an uneven, checkered resume, has a felony record and can't work or live within 500 feet of a school - which is probably why he's available to start immediately if you're willing to have a chat with his parole officer.

Okay, maybe it's not that bad but the point is, you don't have the luxury of being inflexible. Back in the 80s I hired a talented engineer who was openly trans - and this was in a fairly small mid-western city. Times were very different then and it caused significant problems with other employees and even our landlord but I managed the downsides and this person delivered some incredible code that helped our launch product shine. Since times are (fortunately) different today, let's update the example. Maybe today's deeply flawed but weirdly-gifted-in-one-useful-way candidate comes to the interview wearing a MAGA hat and inquires if their licensed hidden carry firearm is going to be an issue in the office. Are you a good enough coach to extract winning results from a random team of flawed players with some unique gifts which are only partial, potential or still emerging? Can you craft a winning team by thinking different and digging deeper than anyone else through the bottomless pool of candidates who couldn't pass the first screen at Google or that hyper-funded AngelList-darling startup everyone's buzzing about? Because there are gems buried in that mountain of mediocrity if you can find and polish them.

Only at very small companies or at very high levels at larger companies. Typically everybody is going to have to go through the full loop. In 99% of cases knowing someone gets you to the interview and nothing more. If you mean the "best engineers" like people whose names are known or the type op AI people that Zuckerberg is personally making offers to, then yes that's different, but those people are such outliers that statements like "going through the hiring process like a chump" don't really make sense because 99.99% of engineers are "chumps."

This.

The best software devs I've hired again and again are basically people i know they are good, or someone I trust a lot recommended them. My "technical" interview is just basically trying to sell them the position.

Likewise I've had the luck of not having real technical interviews in the last 4 jobs I've had, the last being for Principal Engineer. It has been basically acquaintances referring me and soft "what's the problem to solve?" Chats.

Big companies (that pay real money in RSUs) have bureaucracies designed to thwart this. A referral through the hiring manager practically guarantees an interview loop, but there's going to be an interview loop, with at least one veto point outside the hiring manager's sphere of influence.

Several former coworkers have offered me jobs at their startups, but it's like 2/3rds of my current base and 20% of total liquid comp.

> leave the ego at the door and not talk about compensation or try to demand remote work

This makes it sound like these things are written on stone tablets and we just need to accept them as is. They are businesses buying labor. Everything is negotiable.

Talking about those things is not “ego” it’s a perfectly rational thing to do. Whether you should be paid $50k or $500k is not a law of nature but a compromise between buyers and sellers of labor.

Similarly, if you’re willing to trade remote work for a lower salary it’s perfectly rational to bring that up.

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.

See this other post from us: https://www.otherbranch.com/shared/blog/would-you-still-hire...

You have no leverage "immediately". You bring up compensation at the last minute, when the company extends its offer.

If you're not talking about compensation, you're leaving money on the floor. I'm no "best engineer", but I've never failed to get meaningful bumps to my starting comp by giving some pushback on a company's initial offer. Most of the time the only leverage you'll have is the innate friction in the hiring process: By the time a company has extended an offer to you, they've committed non-trivial resources convincing people you're the right pick. It's a PITA to throw all that away, so something like "I'm very interested your offer. For $(offer+X) I could sign today" or "I like your company, but you're offering a bit below market rates. (A contractual pay bump after 3/6 months, an additional week PTO, whatever) or an extra $X would make me willing to accept immediately." will likely work. This should be ideally in person, or at lease over the phone or VOIP, so you have the opportunity to smooth things over and retreat with your tail between your legs if they take it very poorly, but I've never seen that happen. Worst I've heard of is a firm "Sorry, that's the offer, take it or leave it", leaving the applicant no worse off than they were before.

Not negotiating compensation just means you're paying a conflict avoidance tax.

This is ignoring the fact that there are very few opportunities for the best engineers to thrive. I guarantee you there are thousands of John Carmacks laboring away at mid-tier companies with mid-tier managers, inventing paradigm-shifting technologies that get underutilized and shelved behind IP protection by their clueless leadership, living in a B-tier tech city with kids in school and a wife with a job, not able to move, looking at job postings every few weeks and seeing the same dumb-as-bricks derivative adtech vibe-coding middleman companies looking for someone to fill a seat, not developing a network because the few good engineers they know are all in the same situation as them. If you define the best engineers as those that are already incredibly successful, you're doing a terrible job of recruiting for your company. Even a little effort to recognize under-appreciated talent would skyrocket your team's ability, but instead you're salivating over some over-hyped over-paid Silicon Valley rockstars? What a waste. But it doesn't really matter, because your company is also dumb-as-bricks derivative adtech vibe-coding middleware, so why are you even trying to recruit talented engineers at all? Just fill your seats with someone who knows how to type a prompt into an LLM and make your exit before everyone realizes you're a sham.

I interviewed with an early stage pre-seed startup with a very young team, like 25-27. I was interviewed by someone way more junior than me. According to the recruiter, in 3 months, I've made it the furthest and he told me this startup was churning through top tier candidates left and right.

After my interview, I immediately knew why. The team was so junior they didn't know how to evaluate senior talent. They didn't know what they wanted. I've arguably interviewed more candidates than the person interviewing me.

Last I checked, they still haven't filled that role.

The strong hires I've given all came from underrated candidates who didn't come from trendy backgrounds. Still think Dan Luu's advice holds up even more at early stage startups. https://danluu.com/programmer-moneyball/

This is so interesting to hear. From what I've seen, probably half of recent yc startups have founders below 30. I wonder how senior talent views being interviewed by people who are essentially junior/mid developers.

I'm in my 20s with good credentials and have quite a few friends in the startup world. I would never feel comfortable interviewing someone with 10+ years of industry experience.

> I would never feel comfortable interviewing someone with 10+ years of industry experience.

I would say that's probably overcompensating. I've got about 20 years of startup experience at this point, and one of the things that frustrates me the most is a kind of zero-sum mindset, where you "pass" an interview or not.

In the best cases, interviewing is a conversation, a path to better understanding for both parties. The idea that you're "not qualified" is just as silly, in my opinion, as the idea that an hour-long interview lets someone pass judgement. We can both gain, and maybe I'm exactly what you're looking for, in terms of someone who brings skills or perspective you don't have. Maybe it's obvious that I'd be an awful fit. But either way, I believe everyone has something valuable to bring to the conversation.

Some of the best times I've been involved in interviewing, we've had even an intern talk to someone. If they're helpful, clear, and kind, that can be a huge signal. It's kind of a cliche, back in the day, that you ask the office manager how the candidate treated them, but it's absolutely true that if you treat people "below you" in the hierarchy poorly, that's a red flag, to me.

Ten years is almost no experience if they have been doing enterprise development.

As a senior (in age and experience), it is sometimes not pleasant.

The junior interviewer might be really smart and extremely motivated, but ready to argue about something very specific while missing the forest for the tree.

Years ago, I was interviewed by two young guys at meta. They asked me to solve on a white board a problem to which the obvious and expected solution was a binary search. Which I did.

I wrote a generic binary search function, and then used it in another function. I stepped through the code of each functions line by line as attempt to prove correctness.

They wouldn't have it. They argued I could only prove it was working by stepping through both functions together. While I argued the literal point of using (pure) functions was to simplify by composing and abstraction.

Things got quite heated up. Especially with one of dude. I just left right there and then.

Why?

I'm 25+ YOE. 9+ YOE in small companies.

Now, I'll drop a line on ya: I've made several million dollars of mistakes, could easily be 8 figures, though I doubt 9.

Do you want to pay for all that learning someone ELSE paid for, or learn it yourself?

Your call.

Companies that say they only want the "the best engineers" or "we only hire A-students" and "top of the cake-engineers" I've usually found to be a breeding-ground for a somewhat toxic work-environment.

add "we're a meritocracy"

Add:

- we work hard and play hard!

- we are full time in office because we are all aligned on a vision

- generous equity in a promising startup [series A $5M raised by a recent Stanford GSB grad] [salary for 10 YOE in Bay Area is $180k]

I would agree. I would add a straight A student might not be able to hold a conversation very well. There are so many factors, but one thing is for sure— getting a long is what matters most.

I wish there was a way to figure out if someone is proactive, willing and capable of learning and having little patience for bullshit.

These have been the most important traits i've seen on great engineers, people that just plow through the work day after day and jump over hurdles to get stuff done. It feels like everything else is secondary to just wanting to put in the work.

Because people who say that are delusional.

Where I'm from, and this might be universal, those types of firms are either finance or consulting shops.

The actual work practically never warrants the type of people they want to hire, but they pay well enough and they can leverage their prestige. Part of the schpiel is that they can boast to their clients that they hire the best of the best, and thus billing $1000 for a fresh grad is worth it.

There's a lot of focus on signaling. Of course Jane or Joe with a graduate degree in theoretical physics from MIT is going to be able to sift through data and compile spreadsheets and nice powerpoint slides...but it's going to be complete overkill.

Kind of funny I ended up as a researcher at MIT without having finished my degree some how...

I used to work for one of these places that spammed "the best" kind of attitude in their recruitment advertising and the actual work was nowhere near it. Big talk about performance and algorithmics and then the work is 95% sifting through slop to implement more slop. I'd even say it even bred a worse than average culture because now if you complain about any of the slop, you're the dumb one who can't "navigate the business".

Since I can't edit my first reply, I'll also say this:

Many of these shops are strategically preying on the infamous "insecure overachiever" types.

The idea is to work smart and ambitious (but insecure) people to the bone for a short period. 1-3 years. Then when exit opportunities arise, most will leave. Those that stay will have been indoctrinated to think that the toxic culture is normal, or they simply just thrive.

I worked for 5 startups before I went back to grad school and then entered academia; it was over a quarter century ago but I think some of the lessons remain valid.

The best startup I was at was one where four engineers who knew each other had dropped out of a big company and started with a consulting project, developing the first version of the product for an early customer (a national lab) using FPGAs. Then they got venture funding to develop an ASIC version, which is when I got hired as employee #12.

The next best one started when a bunch of friends from undergrad - mostly engineers but one with a business degree - convinced a sales person to go in with them on a startup.

In both cases they didn't have to hire a founding engineer - the founding engineer or engineers were part of the original group that got seed funding. Some of the later hires were quite good, and rose to the level of some of the founders or higher, but their success wasn't dependent on the supernatural ability of someone they hadn't yet identified or hired.

To be honest, the whole idea of "I have a great idea, but don't know how to translate it into product, so I'll hire people to do that" seems like a recipe for disaster in so many ways.

Yeah there's a reason that "ideas guys" are memed to death online. It's very easy to have a great idea, the skill is in selling that idea to VCs, customers, friends and family etc.

Well and actually building the thing well enough for them to become/remain customers.

It's not 2010 anymore. Most startups can't even attract "the best engineers" much less hire them.

This is the late game, why would an engineer work for a fraction of a percent of equity and a below market salary when they can take a job at FANG?

You've got to be offering something really, really valuable like remote work, an interesting problem, and/or a new experience. Otherwise the math doesn't math.

Because FANG companies do not attract "top talent." They attract "very good talent," but typically talent that requires infrastructure that doesn't exist at startups. Daryl Havens is the exception that proves this rule, and you are not Daryl (unless you are Daryl and in which case, "Hey Daryl! Let's meet up sometime and chat about VAXen.")

Neither do scrappy startups, because they don't have the money.

Top talent that accept below-insanely-great pay start their own startups.

Yup. It's somewhat rare to find "top talent" at a startup, but more because many modern startups are stupid, existing only to suck from the VC teat. In my day... Be was a "startup" and Dominic and Andy were "top" talent. (and wasn't Dianne Hackborn at Be back then?) NeXT was a startup once and Avi Tevanian (despite my many, many technical disagreements) was an EXCELLENT engineer. RSADSI was a startup an Steve Dusse and Bob Baldwin were TOP talent.

I think after the dot-com run-up, "startup" often implied "unprofitable idiot idea that looks plausible long enough to convince VCs to use your company as a demonstration of the greater fool theory." But I said "often," not "always." The critical and vexxing part of this is it's so hard to figure out which idiot ideas are profitable before the VCs shower a small cadre of Stanford GSB grads with cash.

Engineers don't really care about equity anymore because they've been burned so many times. The big payouts from a successful company are not necessarily guaranteed the way they were pre-2015 or so. It has become too common for there to be behind-closed-doors dlilutions and investor-only exit opportunities. It has become very unwise to trust anything beyond real cash wired to your bank account.

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.

Love that compensation plan. I wish my (and every) company did that.

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.

Every single solitary person I've personally known who worked at a successful startup got screwed out of their equity somehow. Literally every single one.

Yup. The stories of old, where an engineer would grind for a decade then have a nice seven-figure payout to buy a home seem a remote memory. I'm not sure what happened because successful start-ups still exist and it seems like somebody is profiting off of acquisitions and IPOs.

It still happens all the time. It's just in an awkward in-between, where it's neither so uncommon that it's worth comment in news stories nor so common that most people in tech know someone who's gotten it. The Figma IPO surely minted dozens of millionaires, although I guess their lockup wouldn't be expired yet.

Just to add a counterpoint, I was hired as employee #3 in 2011. In 2020, I was able to sell 5.8% of my stake for $200K (as part of Series C). In 2021, I sold another 4.4% for $500K (Series D on terms too good to refuse). I still hold equity or options in nearly 0.5% of the company (which is still private).

My wife and I used about half the proceeds of those sales to buy a house (cash offer) in late 2021.

I don’t know what proportion of early employees get screwed, but people who do well are usually smart to avoid posting publicly about it (and I am apparently an idiot).

> employee #3 in 2011

Maybe I'm bitter from getting burned but I don't think this is really counterpoint. Employee #3 you're just shy of being a co-founder and 2011 was an era where equity grants were real and companies weren't yet so clever about handing out Leprechaun gold.

EDIT: Random aside, but I looked up "leprechaun gold" and I guess the trope of a gold-like substance that disappears from your pocket when you're not looking is actually from Harry Potter and not a part of the traditional folklore.

I worked at one in the 2010/2011 time frame where I did not, ironically one where I made no effort at all on negotiation on options and assumed the options would be worth zero. A year later Google bought us.

I didn't get "I'm retiring now" money, not even close. But consider I expected nothing, was only a senior-level IC there for a year, and remained an IC after, it made appreciable change in my life and got me a good paying job at Google after.

But I think in that case it had more to do with the parties involved (our management were great people, and Google was motivated to treat us well).

I'd love to replicate this experience, but it ain't gonna happen.

It's always been the case that FAANG or whatever are not always the "best" home for the "best" engineers. Many do not/did not feel comfortable there, especially as they became more and more corporate and slow.

But unfortunately the answer now is that "best engineers" can't work there either because the layoff / employment-squeeze is in full swing.

You're right that the equity packages offered by startups to engineers are generally insulting. Every time this has come up in negotiation in the last few positions I've interviewed for the founders won't even tell you what % of shares they're offering, nor any sense of what the real value is, just pretend nonsense.

In my experience startups have as much bullshit as FAANG companies, it’s just different bullshit.

Absolutely, I agree. A few years ago I walked away from 10 years at Google hoping to rekindle some excitement in exchange for losing out on money. I hated the way things ran at Google and only lasted there so long because of the money.

So far I've mostly found different (often worse) kinds of dysfunction and not really much better velocity.

There are broader dysfunctions in our industry.

In hindsight, would you have stayed at Google?

Probably. I was going crazy working there, I grew to really dislike it. But from a purely selfish $$ POV, it's likely I would have got caught in one of the rounds of layoffs or been able to take this latest voluntary layoff package.

Unless the frustration led to bad performance reviews, which could have happened.

My mental health would have suffered, but holding on another 1-3 years would have probably led to me being 5 years closer to early retirement.

It was also 2021/2022, when the job market was completely bananas. The temptation to leave and get a decent paying remote job was very high. And at the time I felt Google was doing a very poor job of remote work, at least on the teams I was on. And they made the hybrid in-office unpleasant (floating desks, nobody else there, just a weird vibe).

Hindsight 20/20, etc.

My story is the same as yours, and the same timing, but it was Meta. I missed out on a LOT (!!!!) of money by quitting, but I don't regret it at all. The place was rotten.

I'm actually now at Google and things are just fine and peachy.

Everyone struggles to keep top talent engaged anyway. You can't move fast enough and don't have any problems that need fixing (other than the crippling tech debt you managed to accumulate already).

Large corporations are probably the worst place actually. You get slotted into some random project treadmill (which will be completely different from whatever position you interviewed for) where most of the decisions are made by middle managers at least one or two levels above you. Going out of your way to solve problems will be ignored at best and my even result in a reprehend.

These places are for people who hate thinking but are good at pretending otherwise.

Top Talent won't be leveled such that PMs can be 1 or 2 levels above. They'll be high enough that the project plan heavily consults them from inception.

I was working for a large company with great pay and incredible benefits. I was fucking miserable. I took a 35% pay cut to go to a small company with basically no benefits. I'm so much happier now. I live in a rural area and work remote. I live reasonably. I don't need all the money I can possibly get.

why would an engineer work for a fraction of a percent of equity and a below market salary when they can take a job at FANG?

Once you hit a few million in the bank, have a house, priorities kind of shift. Not for everyone, but for those that would work elsewhere for reasons not money.

The problem you'll find (I've found) in this case is that management in many of these "startups" expect a certain kind of ... ahem... motivational/authoritarian structure ... that lacks effectiveness or sense with someone who has paid off their mortgage and is mainly there in order to ship things and enjoy crafting software.

Put it another way, there are people in every company whose reasons being there can conflict with the motivations of an engineer with the priorities you describe. Often those people end up being your manager.

Doesn't have to be a startup. Can be something _not your own_ but aligned with your interests. Maybe you care about the environment, or you're fascinated with weapons and don't particularly like people or whatever.

In my experience, every single time a company has hired one of these “best engineers” they are not actually good at engineering or delivering anything.

It’s always someone who has some credential that makes them look like the most amazing engineer around. It could be someone who was engineer #7 at a unicorn startup. Some times it’s a person who got famous for speaking at conferences or launched a podcast that caught on. Other times it’s someone who has engineered every aspect of their appearance, from having an Ivy League university degree to having a professional smiling headshot on their professionally designed personal website. In one case the engineer was assumed to be amazing because he claimed to have an offer for a million dollar compensation package from another company so the executives thought they were getting a great deal at a lesser valuation.

Then the pattern is that they spend a couple years in meetings, writing proposals, and doing greenfield initiatives that don’t go anywhere. They get special exemptions to work remote on unique hours and everyone is expected to work around the superstar. Then two years later they disappear, off to the next company for another raise, without having done anything useful for you.

I’m guilty of hiring people like this, too. At one job the CEO reviewed high compensation hires and provided feedback but wouldn’t get in the way. I remember one candidate he flagged as sounding like a “prima donna”, which the hiring team scoffed at. Turns out, yes, he wanted everyone to cater to him, wanted to rewrite everything, and left before delivering anything of value or contributing to existing projects in a meaningful way.

Although I agree with the overall sentiment of the article, the reality in 2025 is that it is a totally dead market and we are still trying to figure out WTH is going on.

Some companies are holding their breaths due to political instability, others are in sectors that are already getting decimated (likely from the same instability above), yet others have reached a point where they (and "they" appear to be in a majority in their respective industries) are more centered on efficiency than headcount.

I'm employed and I'm grateful... I know plenty of people searching and are getting nothing but silence in their search. I think both sides of the hiring equation are getting a hard reset right now.

Yes and No... My take on the current job market is this has been a slow-slide into oblivion. When I was a kid, we used something like engineering practice to develop software. You would have someone across the hall with a title of "product manager" or something who understood the business and the problem they wanted to solve (and how much money people would likely be willing to pay for it.) Then you would get a set of 15 requirements, 5 of which needed to be met before the product could be shipped. As an engineer, you put your head down and thought about how you would build each feature and there was a back and forth about which features got built at which time and you built something that looked like a product roadmap for the next three to five years. [ This was in the commercial embedded space. Aviation, government and banking all lived in slightly different worlds. ]

Around 1999 there was so much money in the dot-com run-up that the only thing that mattered was shipping something quick before the investors wised up and sued you for fraud. Engineering methodology took a back seat to expediency and this crazy bunch of weirdos practicing eXtreme Programming were used to demonstrate the spiral methodology the big guys used wasn't the only game in town. People took time out from their lunch meetings with VCs to read books by Fred Brooks and Tom DeMarco, if for no other reason than to memorize phrases like "Technical Debt" and "Mythical Man Month." If you say "Fail Quickly" and "Show me your flowcharts..." and you'll sound like a mysterious, wizardly futurian with a deep understanding of the hidden world of the matrix. But most of the people in the 90s in sili valley were ponces.

So where was I? Oh yeah... what we're seeing is the eventual end of a 25-30 year slide away from anything resembling "engineering" and "engineering practice". And I'm not saying that's completely bad. I mean... yes... please hire "real" engineers to design, build, test and deploy avionics firmware. You do not need an engineering degree to create a vibe coded web page that texts your fiends with name suggestions for their children or pets. MyTripToSacramento.Com can probably get by with a product manager and a dog. The dog is there to bite the product manager when they try to change the web site.

The 2025 job market has been dead for 30 years, we just didn't notice it until today.

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.

No offers here, local or remote. Hoping Section 174 fix helps.

To where are you local, what are your desiderata, and what does your resume look like?

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.

SoCal... I'll email ya, thanks!

I always chuckle when I see a posting where the "BUSINESS" founder says something like "looking for a founding engineer to define our tech stack, but we've already decided we're going to use Python 2.8, Solaris, Azure and a custom build of VIM." [Obviously this is a bit of an exaggeration.]

Only mild. They'd be using Arch Linux and Rust.

Why do we go to work?

- Sense of value and worth to society? Go volunteer.

- Wanting to help make someone else's dreams come true? Probably not.

- They pay us!

Ummmnnn. I may or may not be a top engineer. But, in large part for most people the big reason is: They get paid.

You could also ask the question for "why do founders even bother with startups", and you'll get the exact same answer. It seems selfish that they then expect their employees to work for them, not for money, but rather for love and exposure.

Startups can be for a variety of reasons, not everyone who starts a business wants to make billions. Sometimes they just want to have a nice life doing something they enjoy, find value in, or can just make money at.

Then again, I'm on HN. Show me the Benjamins. ;)

It's always about the money. And when someone says it's not about the money, it's absolutely about the money. Once people understand that, the world becomes much easier to navigate.

Yes, I work for a sense of value and worth to society, and I would accept being paid less if it meant a greater sense of worth. Think about it this way: I have about 40 productive hours per week (young kids, otherwise it'd be more). I could spend 30 hours at a worthless, pointless job that pays well, making enough money for my family, and then 10 hours volunteering on something I care about that makes a difference; or I could spend 40 hours at a job that pays only 3/4 of the former but also achieves my goal of producing valuable things for society. I get paid the same per productive hour, and the latter is much healthier for my psyche.

I currently make around the 20th percentile for my level of experience. I do look for higher paying jobs, but they're all at stupid boring companies doing fintech, adtech, or trying ineffectually to position themselves as middlemen in whatever the latest tech trends are. I don't love my job, but at least I'm making real things that actually help the world.

You are trying to derive emotional value from your job. I did that for a long time.

I don't anymore. I learned it actually made me worse at the job, and didn't allow me to contribute to the things I DEEPLY care about, because I'm actually just pushing work.

It is not an easy lesson. But I'll take the money, and derive my value to society elsewhere. Alot easier that way.

Ask the people who worked at Bell Labs in its heyday, or at NASA during the Apollo program, or who make a modest living earning a salary for a charity or organization they care about -- ask them whether it's a mistake to try to derive emotional value from their jobs. The problem isn't that humans become invested in their work, the problem is that almost all jobs are stupid meaningless bullshit. It might seem like a monumental task trying to reinvent the economy so that most jobs aren't just fucking awful mind-prisons, but it's actually easier than changing human nature. Humans want to care about their work, it's just that the parasitic, psycopathic caste of C-suite "Business Leadership" nepo-babies who currently run the entire economy don't give a shit about what humans want. People in the 1950s were largely proud of their jobs, and not because they were morons, but because their jobs actually mattered, they contributed real things to the company and the world, and they were paid well -- within a factor of 10x what the CEO was paid. None of that is true anymore, and it's not human nature's fault. It's the fault of a small percentage of very specific psycopaths.

The best people have the best options which may be leaving the company only a few weeks to months when their ‘dream offer’ comes in. In addition most work doesn’t need the ‘best people’ but consistent and dedicated people. I think this was even in a Dale Carnegie course. I’d have to look it up. My point is ‘qualified’ people with good values are mostly want companies need.

Just to complicate things, "best people" also means "best fit for an organization's culture." I know several HIGH FUNCTIONING engineers from Amazon who went on to startups and failed miserably. But then again, I know several HIGH FUNCTIONING engineers from Amazon who founded startups and did pretty well. But my point still holds... just 'cause you're doing well in one organization doesn't mean you'll do well in a different organization.

One of the best games programmers I know went to [[very large video game company]], but didn't do well. They then went to [[different very large video game company]] and knocked it out of the park.

I have seen organizations that actually want "the best" developers almost never.

They may say this, but what they are looking for are "the most compatible" developers. The distinction is monumental. The best developers are at the top 15% of a bell curve where the line is very close to flat, but what they are actually looking for are people in the range of 45-70% of the bell curve where there are the most people doing the same exact things as each other.

Conversely, I have seen many developers actually take lower paying jobs to get away from the bell curve stupidity.

Seems like the author is a bit frustrated from unrealistic expectations. Hits home as we’ve not filled a role for over six months.

If you don't mind me asking, what's the role?

AI Engineer. Lots of candidates that want to be one but not many with actual experience, is the problem I’ve heard.

In a new field, one needs to look forward rather than backward.

Ah, that makes sense. I have no experience in AI, and wouldn't even consider applying to those jobs. Although it seems like most jobs are for AI these days. Maybe I should learn.

Honest question: if you'd hired someone who wanted to be an AI Engineer and had plenty of experience with general software engineering, and was of roughly the median quality of the engineers you've hired for other positions, do you think you'd be better or worse off than you are now?

> Lots of candidates that want to be one but not many with actual experience, is the problem I’ve heard.

And you haven't had a single candidate that could possibly pick up the missing skills[1]?

==================================================

[1] I don't know what those are. There are two extremes here:

1. PhD level Maths is involved.

2. You require them to have experience in a specific product (anything from a Python library to a framework like HF)

If your requirements are closer to the first extreme, well sure, you're gonna have to wait for someone that has that.

If your requirements are closer to the second extreme, why not just take a candidate? If it takes 2 months to skill up on whatever product you need them to skill up on, right now you would have had that position filled for the last 4 months with your ideal candidate.

Otherbranch is the recruiting firm Triplebyte employees started when Triplebyte wound down. This is a pretty standard recruiting lament!

If you can't fill a role in this market that's definitely a you problem.

I've been in recruiting for seven years! If I weren't frustrated with clients sometimes, there'd be something deeply wrong with me :)

> Hits home as we’ve not filled a role for over six months.

Sounds like a you problem, TBH. To be even more honest if, after six months, you haven't yet realised what the problem is, your company has deep self-awareness issues.

It's quite simple: if the candidate you want is not applying for your open position, then that's on you; increase the comp, the benefits, the work environment, anything, until the candidate you want sends you a CV.

You're bidding on an open market for talent. I find it hard to believe that the talent you want does not exist.

What most companies consider to be the "best" engineers is different from what engineers would consider to be the best.

Companies want engineers that get the job done the way they want it. Building a structurally sound product is so far off their radar that actually being a good engineer isn't that important. Unless you're good enough that you have clout, you're better off focusing on your interpersonal skills and marketing yourself to these companies; even clout often isn't good enough.

When an employer says "we only hire the best", the most that can truly mean is they want to hire engineers who will play by the rules of their game. That's it. They can't define "best" beyond that without contradicting their other corporate values.

Treat empty statements like "we only hire the best" the same as "are you a coding rockstar?" and "bachelors required, masters preferred"; horsecrap to be ignored.

The best companies hire relatively green engineers and develop them.

Not as their first 4 engineers.

The fifth engineer can be a junior. Once you've built a base you can start expanding and hiring on potential.

I dont know about that! In theory it sounds good. I know a company that hired a very good hands on cto who then hired 5 50k entry level engineers that was largely the extent of their team for 1-2 years. Then they started to hire more senior people.

I'm sure the cto did a massive amount of training early on but this is a near billion dollar company in a fairly complicated industry. You dont HAVE to have 4 incredibly senior super engineers as your first hires. It might make coding easier early on, but its going to make hiring much much harder.

I don't think you need "super engineers" either. They just should have made it through their first mistakes on someone else's money. If your founding team is not technical, it's important that one of them has seen the problems that will come up in your first 5 years.

No matter what you do, you will make wrong decisions and need to fix things once you need to scale. That's the way of startups. However, you also need to prevent the high level footguns such as OWASP top 10 and exponential algorithms with minimal supervision.

This is the answer

As a startup you don't have Google's money. You don't have Google's employer brand. You don't have Google's work environment.

in fact as a (hopefully) fast-growing startup the only thing you really have to offer is growth. So make it clear how you are going to help the candidate grow their career and experience faster at your startup than at the established company, and offer the best you can do on comp and work environment.

This doesn't mean fresh grads, but more like someone with a bit of experience who's ready to jump into a team lead or architectural lead role.

When JavaSoft spun out of Sun to build Java, they hired recent graduates, many out of CMU: Mark Reinhold, Josh Bloch, Anand Paliswamy (?), David Connelly, et al. The exception was the Swing team, who had done GUI frameworks before (though never in just one year).

Their key virtue (imho): no politics. They hadn't learned to play the game, buy time, pad estimates, defend their technical choices, and so on ad infinitum. Instead they mostly tried to gain the respect of each other.

Granted as the team grew into 2D and the 10K API's of Java 2, some political teams came on board. sigh.

And it wasn't "companies" hiring and developing them. It was 1-2 senior managers with long histories who managed to extract JavaSoft from Sun to get some breathing room.

IMO there's two reasons you'd want the very best engineers.

A) you're working on one of the hardest engineering problems in the world.

B) you've a track-record of failing to deliver with merely competent engineers.

But in the second case it's invariably incompetent management that's the problem.

I think this framing is exactly right: once you cross the threshold of intelligence and work ethic, “best” stops being a single axis and starts becoming contextual.

In practice, the engineers who end up being game-changers aren’t necessarily the ones with the cleanest codebases or the fastest prototype cycles — they’re the ones whose strengths match the moment.

A few real-world examples come to mind:

Linus Torvalds didn’t just write code; he created a system of distributed collaboration (Git) because the scale of Linux demanded it. His engineering contribution was partly social architecture.

Margaret Hamilton at NASA defined entire disciplines of software reliability and safety at a time when “software engineering” wasn’t even a recognized field. Her context required meticulousness and systems thinking over speed.

James Gosling’s creation of Java wasn’t just about syntax, but about building a portable runtime when fragmentation was the biggest pain point in the industry. He solved the problem the world cared about most at that time.

Guido van Rossum intentionally designed Python to be simple and approachable, betting on readability over performance. That “engineer as teacher” quality ended up seeding one of the most important ecosystems today.

The “best” engineer isn’t universal; it’s the one whose particular strengths — whether speed, rigor, clarity, or community-building — align with the bottleneck you’re facing.

So maybe the hiring question isn’t “Who’s the best engineer we can find?” but rather: “What kind of engineering excellence will unblock us right now?”

A more generalizable approach might be to consider - what are you looking for that most other companies either are actively putting off or passively neglecting, and what's the best way to identify the best engineers in that group. To use examples in the post, if you're remote then you can get "startup experience - hard worker - impressive project - aces your 20 ridiculous interviews" by getting in front of people who live in Ohio and people who live in the Bay Area and low key hate Caltrain. If you're willing to pay top of band salary all cash, ala Netflix, then you can be a Bay Area Only Senior Elites Need Apply type startup.

What about other things? What if you are, in fact, willing to let engineers decide whether they address tech debt, like the post calls out? Or, you don't overvalue confidence and talking and can appeal to female engineers, quiet engineers, or in general less competitive types? What if you want hard worker startup experience passes pseudo-IQ tests, but they don't need actual coding experience measured in years and you think AI and training can bridge the gap?

Note, I'm not saying any of these companies will necessarily be more successful with their hires, but they're being intentional with who they hire and how that fits the company's advantage in a way that the "you and everyone else" profiled in the post do not. Like, figure out what makes you different. Figure out how that will make your people different. Then write it in the job description, black text on white background (or the reverse in dark mode), plain language, so it's obvious.

> You're acting like a replacement-level employer and expecting more than replacement-level candidates.

There are probably a lot of people who need to hear this.

these discussion are so repetitious, and so many opinions (which are all welcome, they are opinions) seem so personally motivated. I want to read about some contrast, some "I expected this, but I've learned this"

I really only want to hear from people who announce first

"I went to elite schools, but I prefer hiring journeymen" or "the best I've known come from the unlikeliest places"

"I'm self taught, but I'm a good worker with some projects to show and talked my way into some great situations, but I realized I had to go back to school, I didn't have the horsepower"

Here's how I've learned to knit a team together, here are the types of diversity (of skills, habits, temperaments, experiences, raw iq, or educations) that will make a team successful.

it's boring to read over and over "mine owne education is that of a young prince, and I will only work with yon other princes" or "me learn code with sticks in cave, no code cave, no code with me"

don't simply justify yourself, that's only what survivor-bias or failure bias "teaches"

Would the "best engineers" even be grinding through applications or 7-8 round interviews?

I thought these folks had headhunters working for them because they were in demand. The jobs came to them. Not the other way around. Or if the product or area was interesting they would seek them out through back channels.

The entire article to me sounds like it hinges on having a very unrealistic and singular definition of "best", that I would bet money does not even align with the people they are talking about.

Of course people don't need or want rocket scientists to work on their facebook clone, isn't that obvious? Why does the whole article center around this one interpretation of a subjective term?

Their website advertises a service that provides 90-minute live-coding interviews. Maybe if I actually was looking for a rocket scientist, that might be a good idea, but otherwise that seems incredibly excessive to me.

Personally I've been in this industry almost 30 years and I would never take a live-coding interview for a job, but maybe that's just me.

A mistake most founders make is they want someone as motivated about their company as they are. But things have changed since even 15 years ago. Back then, the machinery for startups wasn't as available, so many people would work for someone else to do something.

As the machinery has become more available, all those highly motivated people would rather compete with you than work with you.

So founder-level motivation is only available if you give something else up: cash (as opposed to delayed equity), large amounts of equity (2% or more), desirable working environment (close to home, remote, etc) or something else they can't get and can't just get by competing instead.

But the most founder-level motivation guys will just start a competitor. That's life.

I've considered "great engineer" a hiring anti-pattern for a decade. (Specifically in the space of product-focussed pre-pmf startups, through into early scale-ups).

I'll take "great communicator", "great co-ordinator", "great collaborator" and "great technical designer" over engineering prowess any day of the week. That's where the 10x gains come from in a team.

Though, on that last point, I think most great engineers I've met are that way because they are great technical designers. It's not something that usually gets filtered for in hiring in my experience.

We have a career framework that I've refined across 4 teams now. 6 areas, and only one of those is "Coding and testing".

Hire the Best Crypto Recovery Experts for Fast Recovery: VISIT CERTIFIED RECOVERY SERVICES

I honestly never thought I would be sitting down to write something like this. A couple of months ago I fell victim to a really convincing phishing scam. Within minutes I watched 4.2 BTC basically my entire savings vanish from my wallet. The feeling was indescribable. My stomach sank and all I could think about was how stupid I was for clicking that one link. Everywhere I looked online said the same thing: crypto transactions cannot be reversed. That made me feel even worse like everything I had worked for was gone forever. In my desperation I started looking for help. I came across a few so-called recovery services but they were shady right from the start. Most of them demanded huge upfront payments sometimes even in gift cards which only made me feel like I was about to get scammed a second time. At that point I had almost given up hope until I found Certified Recovery Services. From the very first conversation Certified Recovery Services showed me they were different. They did not promise miracles and they were upfront about how difficult the process could be. The best part was their payment structure no recovery no fee. That gave me confidence because I knew Certified Recovery Services was not just out to take advantage of me. The team at Certified Recovery Services especially my case manager was incredible. They were patient explained things in a way I could actually understand and kept me updated regularly. Even though I was anxious the whole time I felt like I had real professionals in my corner thanks to Certified Recovery Services. After about three of the longest weeks of my life I got the message I will never forget We have successfully frozen the assets. I cried when I read it. Certified Recovery Services had traced my stolen Bitcoin through different wallets and managed to get it locked down by working with an exchange overseas. In the end Certified Recovery Services recovered 3.9 out of the 4.2 BTC. Losing a little was tough but getting almost everything back felt like a miracle. The fee they charged was completely fair and worth every bit of it. Certified Recovery Services did not just return my crypto they gave me back a sense of hope I thought I had lost. If you are ever in the same awful situation I was in do not hesitate to reach out to Certified Recovery Services. They truly are the real deal. Here's Their Info Below: WhatsApp: (+1(740)258‑1417 ) Telegram: https: //t.me/certifiedrecoveryservices mail: (certifiedrecoveryservices @zohomail .com, certified @financier .com) Website info;( https: //certifiedrecoveryservices .com)

Of course, running a business is not like saving the planet. Tech companies are companies that make money by means of tech - it doesn't matter how sausage is made but that you are compensated for sausages delivered.

Which is why personal hobby projects are awesome!! No one is going to make a bank building an example of Federation standard issue phaser pistol as close to forms and functions as issued, but it'll be awesome nevertheless and regardless of quality. But it won't make a bank. But it'll be absolutely awesome.

If you want the best engineers, you also need to be the best employer.

Loved this article, funnily enough I wrote something in a similar vein, due to my frustrations with nonsense requirements, yesterday: https://gilli.is/journal/the-best-designers-know-nothing-abo...

The whole truth:

When the average pre-revenue startup says:

> "We need the best engineers"

What they really mean is this:

"We really need ex-FAANG engineers from Ivy League, Stanford, MIT and Oxbridge for close to below market rates."

*6 months later:*

"We have a skills shortage of the best engineers"

What they really mean is this:

"No one wants to accept our below market price offers, even with 0.01% equity which may be worth something one day."

If the startup cannot offer a competitive compensation to FAANG or the big AI companies, just walk away. Likely dodged a bullet anyway.

ngl - the worst times I ever spent was in companies that did not care about tech or what they were doing. The thing is, *i'm* a tech profile ; I like doing deep tech - going to the heart of the tissue. I learned with difficulty that it's sometimes better to not be open-minded, to not go for companies that "just get shit done" etc... - because the realities is that, most of the time, people do what they like, and it just happens that they can latch on something that make them earn money. And we forget that's it's actually a multiple body problem, and that we therefor need to have a strong focus in order to be competitive. But I don't want to be competitive doing php, or staying on the same Django framework since 2012 ; or sticking do doing the same job for the next 2 years until the HR is done with me because they got that smart idea. The truth is ; everybody has to cross the market somehow to be competitive. So you better find a way to be part of the best engineers - and I don't want to be in a company where this is undervalued - because *I know* that in 6 month to 2 years - my skills will not have increased, my competivity on the market would have decreased ; my profile won't sound as strong - and the economics just don't math out.

Let's compare the salary of a back-end engineer with a distributed engineer - it's literally 3x to 4x as much in Europe. If you have no job ; it's literally an opportunity to multiply your salary, improve, know the stack better, etc... - The end-goal is not to be part of a company that stagnates both in technology and ideas for many years - that's already a waste of time and money.

The "Extra details that didn't fit in the post" at the bottom of the post are very much worth reading, even if they didn't naturally open themselves up.

Linus Sebastian, from LTT asked Noctua CEO if they had the best engineers. He said they had good engineers but also give them time and resources to develop good products.

The irony: while you're waiting 4 months for the perfect engineer, your competitor shipped with a good-enough one who's now senior-level from the experience.

That's definitely a valuable take, but it's worth noting that not everyone will make better decisions just by sitting through enough fires, and it's also possible that your good enough person will fail to notice some larger risk or market shift that the person you could've waited for would have, because they'd have seen it before.

Hiring decisions tend to be a hindsight is 20/20 proposition.

Exactly - you never know either way. You hire the senior, might be useless. You hire the mid-level, might be great. At least with the faster hire you're making progress while finding out.

Um. No. You don't become a senior engineer in 4 months.

Fair point about 4 months, I was thinking longer term there. But the original post was about finding the 'best' engineers, not necessarily senior ones. Either way, you can't know what's best for your situation until they're actually working.

"best" engineers vs "senior" engineers is a valid point. I think a lot of my comments on this thread are of the mode of "best engineer" should also be thought of as "best engineer for this environment / culture." I tend to stay away from people who say things like "top talent" and "10x engineer" and (worst yet) "Unicorn." You can't really make a judgement about an engineer without describing the environment they'll live in.

And also... maybe more importantly... there's a saying (almost a joke) in the military: "You don't go to war with the forces you want, you go to war with the forces you have." (or maybe it was "people" instead of "forces" and no doubt the Air Force replaces "forces" with "very expensive weapon system manufactured by lowest-bid contractors by people who happen to live in districts represented by members of the congressional armed forces committee.") And that might be what we're getting at here.

While it would be great to get the absolute best engineer at day one, it's more likely you're going to get an engineer that requires a fair bit of training and in-the-trenches experience.

Great point about environment fit. I've seen a wonderkid with amazing potential but no drive, and a solid engineer who maximized their potential through pure effort. Hard to say which was more valuable - depends on what the team needed.

Recruiters can’t tell a good engineer from a a bad engineer

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.

> Would you rather spend four months in stasis waiting

This is a false dichotomy. Hiring slowly doesn't mean doing nothing. It's really more like "do you (CTO) want to slow down on building and become a manager now?" Waiting and finding someone who doesn't need managing can be way less distracting than going for someone imperfect because you've convinced yourself you need to hire now.

The author's point, though, is that folks tend to wait four months and then hire "someone imperfect", which they could've done now.

If you find you're shooting yourself in the foot, do not reload.

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).

Hiring committees want people who can execute their vision no matter how poorly or well conceived it is, that’s it. Everything else is noise and you shouldn’t take it too seriously. There is a ton of bullshit floating around the industry, calling it out is an endless and ultimately fruitless exercise. Get paid and get out with your sanity/health in tact and you win.

A good rule of thumb as a founder and someone that's worked in big tech;

Big tech rules out any red flags. This means any engineers that get a passing grade across all interviews are in. Anyone that fails one of the multiple interviews is out, despite possible strengths.

Small tech should hire on the green flags. This means you can tradeoff weaknesses if they can do a job that needs to be done.

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.

The general goal of hiring for startups is, essentially money-ball or finding value. You could pay market-rate for a tenured senior engineer from a top tech company or you could pay a lot less from someone out of a state school that might fly under the normal resume screen but is otherwise highly motivated and high agency.

This is really well written. Great read.

What’s with the pivot away from the purely speed based testing? I recall getting the ick when I saw it as your primary metric for engineer goodness not too long ago and I don’t see any mention of it anymore on your site. Have you pivoted to something more sane?

Most companies want a tailored Savile Row suit, but only budget for supermarket polyester. Don’t worry though - I’ve got a warehouse full of polyester, and for £40k I’ll happily convince you it’s bespoke.

One thing I learned from working on a remarkably good team—at Target of all places—is that you can hire great people as long as you can demonstrate (show-not-tell) that you're doing something different and interesting. How you demonstrate this can take lots of different forms (the whole point is that there is no one way to do this!) but just saying "we have high standards and work hard" is never enough on its own. Everybody says that.

You'd think that startups would be the best-positioned organizations to do things differently in the name of hiring. When you start your own company, you don't have to answer to management or HR, and you don't have to follow trends for political reasons. ("We can't let your team do X differently from everybody else, people are going to talk...") But I rarely see this in practice. Most startups seem intent on having a pretty standard approach to management and work; there's clearly some pressure, whether directly from investors or just purely sociological, to be like every other startup.

This seems like just a purity spiral effect. What do you expect recruiters to say, that they hire medium engineers? I think this is mostly just performative

Wouldn't it be refreshing to have the bullshit laid bare for once?

Reminds me of that post explaining how to make "stupid" LLMs work together to make something more useful. Maybe it works with engineers too.

The term you're looking for is "development methodology."

It reminds me of what a recruiter once told me something among the lines of:

We ask for god in person, hoping for a prophet, we are happy when we get the faithful.

Why does no one ever seem to apply early stopping theory to hiring even though that's the canonical example of early stopping theory?

Not mentioned enough: watch out for engineers (or any hires) who will take zero interest in helping the business succeed.

You can try and hire for brains and experience, say. And have your business constantly undermined by empire building, "just collecting a salary", resume building, and other popular nuisances. Attitude and alignment matters.

If you are yourself "empire or resume building", nevermind, carry on.

> watch out for engineers (or any hires) who will take zero interest in helping the business succeed

To my experience, 80% of software developers are like this. May be each 5th bothers to ask "what are we building and for whom?"

Many engineers want to deliver good products, not many care about the bottom line of the business. So instead of wanting them to care about your money, try to make money out of good products and engineers will happily take money to help you deliver that.

This does mean that when engineers have to choose between company making more money or a better product for users they will pick the users almost every time, that isn't a bad thing, just try to work with that rather than say such engineers are unhireable.

> Many engineers want to deliver good products

Yes and that's a great start.

> they will pick the users almost every time

Empire building is very common (and other nuisances). SOME engineers will pick the users, yes. Thankfully. But many others do not care one bit about the users. Empire building is certainly not about caring about the users. Are empire builders still hireable? Unfortunately they seem to do great at interviews.

Let's make this hit LinkedIn somehow, along with the "why we hate recruiters" submission :p

There is no universal "best" anything. It's all subjective situational evaluation.

reminds me of the obnoxious Ramp ad about how they only hire the best engineers with a very low hire rate

I wonder if they considered that they simply hired people who are just really good at interviewing, and not necessarily actually the best engineers?

I mean, you don’t hire the best engineers by just blasting off a LinkedIn ad. Or by cold-emailing them. You hire them by already being their friend and offering a massive chunk of cash and equity to work on an interesting project, plus a variety of other concessions, as needed.

The best companies don’t generally do this, because it doesn’t scale. You can scale “find strong talent that hasn’t had its big moment yet, and teach them the trade” a little bit farther.

The whole tech recruiting and hiring process is bonkers. But in terms of "finding a candidate":

1) there's no way to know if somebody is skilled, since the industry don't require degrees, titles are absolute bullshit, and "years of experience" is frequently "spent 3 yrs maintaining other people's code and manually running deploys". the interview and take-homes are a bad pantomime. it's mostly vibes.

2) nobody asks the candidates what they want ahead of the interview. I'll gladly tell you what my ideal job would be, ideal culture, day to day requirements, etc. If 90% of those seem to match a trend... maybe change your company to match the trend? Then you get 90% of the hires.

3) on compensation, know what you're offering and go after people looking for that. A) terrible job, amazing pay, B) decent pay, decent job, C) terrible pay, amazing job. A) is golden handcuffs. B) people bail on you whenever a better gig shows up (or retain terrible/lazy ppl). C) is you've got a hire for life. which do you wanna be?

You don't want to hire the worst engineers either.

This guy will have trouble hiring best engineers

To quibble on a point the “best” egineers don’t have a lifestyle that most people would consider work life balance right? For them engineering is life. (Mild exaggeration)

Another aspect of this that bothers me is starting off the employer/employee relationship with a bald-faced lie.

I'm not a stickler for rigorous honesty in what is essentially marketing materials -- sure, present your strengths, not your weaknesses; fine, be aspirational. But to start right off with something you know isn't anywhere close to the truth sets a pretty bad direction.

Probably the best case is that people -- some of whom will become your employees -- realize it's BS and learn not to take what you say at face value in the future.

I haven't read an article this on-point in a long time. As someone comfortably working remotely at BIGTECH it's actually really frustrating.

OK you have a 60% pay cut and forced relocation back to the Bay Area. Let's jump right into the conversation about how you're going to make up for that to attract talent. Don't tell me it's a virtue because I'm not stupid and you're not stupid.

I appreciate where the author is coming from, but I think when people say they want the best engineers they sometimes mean the top 25% or something. They don't always have a delusional belief that the top 1% are just sitting around waiting for their amazing company to come along.

There's a bit of doublethink involved.

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.

"only hire them if they raise the bar of the current team"

Yeah don't need best engineers to build another CRUD app.

100% this. Unless a startup is doing something truly novel from a technical point of view, what you really need at the early stages is someone who can glue together CRUD apps.

Later you might have to worry about how to make sure your system can scale, how the overall architecture fits together, etc etc.. but even _having_ those problems is already somewhat of a luxury as it means your startup hasn't died yet.

Everything is CRUD

>Would you rather be a green bar in this chart, or a red one?

LMAO with the cult of "No False positives". They'd rather never hire anyone at all.

I mean...you should probably hire good enough engineers that a website can withstand a pretty small amount of HN attention...

...I kid!

But seriously, though, how is it possible in 2025 that websites can still collapse from the relatively minuscule traffic that an HN front page sends? Are people upvoting this submission without having actually seen it?

EDIT: For the "works for me" people, the site's host, framer.app, uses Amazon's cloud and whole regions are getting SSL errors for this domain.

I would bet HN's readership are majority lurkers and not signed in.

I know how much of a traffic pump HN is, having had a number of pages front-page here during prime time over the years. It isn't that big of a traffic spike at all. It's a much more interesting and interested group than many sources, but a single-core min-scale cloud compute can handle it presuming you aren't doing something silly.

In this case their hosting app has screwed up SSL configs for some of their GeoIP served options.

Out of curiosity: what error are you seeing?

That site appears to be running on an Amazon IP (on my traceroute, in the block https://ipinfo.io/AS16509/52.223.48.0/20). If it didn't load immediately, I wonder if you got unlucky enough to catch an autoscaler napping (or maybe they aren't autoscaling; sometimes dodging the hug of death completely isn't worth the cost, depending on how cost-sensitive a firm is).

(ETA: However, the DNS entry is willing to give some wildly different IPs for the lookup, and at least one of them appears to be flagged as abusive, so if you're behind a corporate firewall it's possible an auto-protector is blocking you).

From my normal desktop it is resolving as 18.204.152.241 / 18.204.152.241 which seems to have misconfigured SSL. From a cloud instance it is drawing 52.223.52.2 / 35.71.142.77 which load properly.

Let me translate this article. "Just hire my fucking candidate, this week. Thank you." --your recruiter

"A jack of all trades is a master of none, but oftentimes better than a master of one" - A dude.

+1 for the generalists

you dont understand. that requires training and i dont want to train a midlevel because:

- theyre just going to hop

- i suck at teaching

- vcs want me to hire an ex-faang

- all of the above

Straight up recruitment bs

Counterpoint: You want to hire the best engineers and empower them to work how they are most effective, remotely or not.

how is that a counterpoint

I'd say that you want to choose whether the company is remote vs. office-based, then filter on that before choosing who is "best", in order to hire a team of engineers who all agree on such fundamental choices. A cohort of engineers that has a split decision on where to work never forms a cohesive team. Both ways work... but they don't mix.

You're right, don't hire the best engineers - let them create a startup instead with more VC funding than you've ever dreamed of, then watch as they erode your market share through aggressive marketing, better features, and faster release cycles as they slowly displace you by siphoning off your second-best engineers and eventually get bought out by your biggest competitor.

Did you read the article?

Yes, the points are valid but over-generalized. I've met many engineers that I would consider are "the best" which aren't whining remote prima donnas the article makes them all out to be.

I am also getting a 'these are not the droids you're looking for' vibe from this

Okay

Reply on news.ycombinator.com