Posted by rachofsunshine 9/2/2025
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...
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.
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.
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.
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.
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".
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.
So either you're correct, or all the top FAANG companies are...
And they probably won't use Jira. Or tickets.
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.
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 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 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.
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.
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.
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.
those qualities were over-developed by e.g. the cenobites
The “best candidate” depends a lot on your existing organization.
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.
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?
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
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
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.
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.
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.
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.
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.
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.
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.
> 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))
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"
Yep
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.
See this other post from us: https://www.otherbranch.com/shared/blog/would-you-still-hire...
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.
* 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.
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.
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.
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 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.
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/
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]
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.
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.
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.
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.
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.
I'm actually now at Google and things are just fine and peachy.
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.
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.
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.
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.
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.
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.