Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

otherbranch.com

Post reply on HN
Print view View original

221–230 of 326 posts

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

#221

Post by cmrdporcupine »

CobrastanJorji wrote: post #171
Centigonal wrote: post #37

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 (l…

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, th…

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

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

#222

Post by bluGill »

hobs wrote: post #202
Centigonal wrote: post #182

Earlier quoted context omitted.

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 prof…

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, becau…

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

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

#223

Post by swiftcoder »

eszed wrote: post #143
Centigonal wrote: post #37

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 (l…

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.

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

#224

Post by cmrdporcupine »

tikhonj wrote: post #201
CobrastanJorji wrote: post #171

Earlier quoted context omitted.

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, th…

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.

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.

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

#226

Post by rachofsunshine »

AnotherGoodName wrote: post #163

A good rule of thumb as a founder and someone that's worked in big tech; Big tech rules out any red flags. This means any engineers that get a passing grade across all interviews are in. Anyone that fails one of the multiple interviews is out, despite possible strengths. Small tech should hire on the green flags. This means you can tradeoff weaknesses if they can do a job that needs to be done.

This is a specific application of a good general principle. Big companies need to watch for failure modes. Small ones need to watch for success modes, because the default is always failing.

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

#227

Post by closeparen »

guywithahat wrote: post #103
fitzn wrote: post #13

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

The only addendum to this I'd add is the best engineers rarely have to go through the hiring process in a meaningful way, it's usually someone recognizes them from a previous job and vouches heavily for them. I say this because if you're going through the hiring process like a chump, I'd leave the ego at the door and not talk about compensation or try to demand remote work on a desirable position.

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

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

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

#228

Post by giancarlostoro »

j45 wrote: post #160
giancarlostoro wrote: post #111

Earlier quoted context omitted.

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.

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

#229

Post by mrbluecoat »

tmnvdb wrote: post #47
mrbluecoat wrote: post #24

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

Did you read the article?

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

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

#230

Post by tripletpeaks »

mac-mc wrote: post #210
hobs wrote: post #203

Earlier quoted context omitted.

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…

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.

Post reply on HN