You don't want to hire "the best engineers"(otherbranch.com) |
You don't want to hire "the best engineers"(otherbranch.com) |
I wonder if they considered that they simply hired people who are just really good at interviewing, and not necessarily actually the best engineers?
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.
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?
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.
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.
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.
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.
LMAO with the cult of "No False positives". They'd rather never hire anyone at all.
...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.
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).
In this case their hosting app has screwed up SSL configs for some of their GeoIP served options.
+1 for the generalists
- theyre just going to hop
- i suck at teaching
- vcs want me to hire an ex-faang
- all of the above
/s
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".
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)
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.
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.
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.
Hiring decisions tend to be a hindsight is 20/20 proposition.
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.
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.
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.
We ask for god in person, hoping for a prophet, we are happy when we get the faithful.
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.
To my experience, 80% of software developers are like this. May be each 5th bothers to ask "what are we building and for whom?"
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.
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.
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.
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.
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...
Clear communication and transparent accountability are the way.
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.
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".
So either you're correct, or all the top FAANG companies are...
And they probably won't use Jira. Or tickets.
The actual metrics (not necessarily easily quantifiable) are the desired traits you put in your job description; they don't correlate perfectly.
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.
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 :)
Curiosity, resourcefulness, empathy, being user-centric are all things to never stop developing.
The “best candidate” depends a lot on your existing organization.
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.
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.
/s
God i hate the tech world these days.
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?
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.
Yep
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/
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.
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.
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.
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.
- 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.
Then again, I'm on HN. Show me the Benjamins. ;)
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.
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.
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.
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.
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.
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 fifth engineer can be a junior. Once you've built a base you can start expanding and hiring on potential.
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.
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.
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.
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.
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?”
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.
There are probably a lot of people who need to hear 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"
or
"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"
or
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"
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.
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.
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 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-...
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.
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
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.
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.
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
> We hire smart people so they can tell us what to do
> Companies who generically look for "the best engineers"
> 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.
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.
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.
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 10 minutes later: "You did a terrible job because you are a terrible person and you should feel terrible you even exist"
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.
Not negotiating compensation just means you're paying a conflict avoidance tax.
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.
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.
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.
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)?
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 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.
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.
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.
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.
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.
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.
- 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]
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.
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.
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.
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.
These places are for people who hate thinking but are good at pretending otherwise.
Top talent that accept below-insanely-great pay start their own startups.
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.
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.
those qualities were over-developed by e.g. the cenobites
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.
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.
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.
> This has often led to some of the most productive conversations of my career.
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 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.
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.
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.
Senior Software Engineers should not promote bad habits to juniors.
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.
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.
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.
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.
* 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.
See this other post from us: https://www.otherbranch.com/shared/blog/would-you-still-hire...
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.
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.
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.
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.
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.)
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
Imagine formula 1 team. Should they hire top talent for every position? Like a delivery driver, for example
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.
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).
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.
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.
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.
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.
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 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.
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
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 actually now at Google and things are just fine and peachy.
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.
Jira might turn terrible managers into mediocre ones, but it also turns good managers into mediocre ones too.
The map is not the territory, etc. etc.
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.
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.
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".
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.
* - and the focus/determination/consistency with which you part ways with the D and F players.
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.
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.
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.
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.
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.
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.
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.
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.