Hacker News Reader

Comment by Centigonal | Hacker News Reader

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

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

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

View on HN

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

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

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

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

Clear communication and transparent accountability are the way.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What kind of process was it?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Do you mean outside their job description?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The map is not the territory, etc. etc.

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

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

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

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

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

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

Fair enough, thank you!

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

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

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

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

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

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

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

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

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

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

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

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

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

Thank you kindly!

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

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

Guy?

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

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

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

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

There is some truth to this, but I would argue (with a considerable amount of data on both assessments and hiring behaviors) that it is less true than people might like to hope it is.

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

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

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

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

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

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

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

Senior Software Engineers should not promote bad habits to juniors.

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

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

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

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

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

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

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

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

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

It doesn't even need to be "good enough". People SHOULD be picky about founding engineers. But they should be picky about HIRES, not about top-of-funnel proxies for skill.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

God i hate the tech world these days.

Reply on news.ycombinator.com