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

311–320 of 326 posts

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

#311

Post by VirusNewbie »

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…

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

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

#312

Post by VirusNewbie »

jcheng wrote: post #170
GCA10 wrote: post #107

Earlier quoted context omitted.

Hire people on the way up. Hire people who are going to do their best work ever, for you, after having partially but not fully mastered everything you want, via their previous jobs. It's easy to evaluate a resume. It's harder -- but not impossible -- to assess potential. Working inside a big tech company for six years, I saw that PM hires were done almost entirely on pedigree: find me another Stanford grad. These ten…

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

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

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

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

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

#313

Post by creer »

Jensson wrote: post #258
creer wrote: post #235

Not mentioned enough: watch out for engineers (or any hires) who will take zero interest in helping the business succeed. You can try and hire for brains and experience, say. And have your business constantly undermined by empire building, "just collecting a salary", resume building, and other popular nuisances. Attitude and alignment matters. If you are yourself "empire or resume building", nevermind, carry on.

Many engineers want to deliver good products, not many care about the bottom line of the business. So instead of wanting them to care about your money, try to make money out of good products and engineers will happily take money to help you deliver that. This does mean that when engineers have to choose between company making more money or a better product for users they will pick the users almost every time, that is…

> Many engineers want to deliver good products

Yes and that's a great start.

> they will pick the users almost every time

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

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

#314

Post by threatofrain »

efavdb wrote: post #101
threatofrain wrote: post #68

Earlier quoted context omitted.

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

Why ever hire mediocre talent?

Because sometimes you know how to decompose a problem very well, and some problems are the nice kinds that have a nice horizontal scale-out for mediocre talent.

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

#315

Post by tom_m »

Centigonal wrote: post #182
glimshe wrote: post #116

Earlier quoted context omitted.

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.

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

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

#316

Post by jama211 »

CobrastanJorji wrote: post #306
jama211 wrote: post #269

Earlier quoted context omitted.

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!

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

#317

Post by monkeyelite »

Apocryphon wrote: post #302
monkeyelite wrote: post #301

Earlier quoted context omitted.

I didn’t say you couldn’t write a lot of code remotely.

I guess it depends on what you mean by “building a new CPU architecture.” Granted, porting an existing one to another existing one isn’t the same thing, but it’s as momentous an accomplishment, no?

Let me restate so there is no confusion.

Large projects, that require coordination with many people, are difficult to lead remotely. It tends to require building relationship and face-to-face problem solving to get alignment. The most valuable and well-paid engineers in the industry are these.

Projects which are technically difficult, but do not require leadership can often be done remotely. The best fit for a remote worker is someone using technical skills they already have, to further goals that are already defined. Many skilled engineers serve this function.

Does that clear it up?

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

#318

Post by dehrmann »

goopypoop wrote: post #217
osullivj wrote: post #189

Earlier quoted context omitted.

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?

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.

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

#319

Post by arandr0x »

VirusNewbie wrote: post #312
jcheng wrote: post #170

Earlier quoted context omitted.

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

I suspect part of the reason big tech has an arduous interview process is it approximates both intelligence and hunger/drive. Even very smart people aren't going to waltz in and be able to code fast enough to solve harder interview problems without practicing. So, people who can pass algorithmic interviews are smart people who also had the hunger/drive to study up/practice some.

It is possible to do leetcode without practicing, even before AI. That said the structure of the Big Tech process is also quite long/multi-step with many opportunities to give up during, which helps select for drive. It's hard to do this effectively with shorter processes. It is however always a good practice to 1) design very hard interviews but 2) give a lot of preparation to candidates beforehand, even for non-leetcode interviews, as it helps filter who can efficiently and diligently use provided information to increase their performance.

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

#320

Post by VirusNewbie »

arandr0x wrote: post #319
VirusNewbie wrote: post #312

Earlier quoted context omitted.

I suspect part of the reason big tech has an arduous interview process is it approximates both intelligence and hunger/drive. Even very smart people aren't going to waltz in and be able to code fast enough to solve harder interview problems without practicing. So, people who can pass algorithmic interviews are smart people who also had the hunger/drive to study up/practice some.

It is possible to do leetcode without practicing, even before AI. That said the structure of the Big Tech process is also quite long/multi-step with many opportunities to give up during, which helps select for drive. It's hard to do this effectively with shorter processes. It is however always a good practice to 1) design very hard interviews but 2) give a lot of preparation to candidates beforehand, even for non-lee…

>It is possible to do leetcode without practicing, even before AI

Back when people did in person interviews, people were writing psuedocode on whiteboards, so knowing the right algorithm and being a strong programmer was necessary, and I can see how one might not need to practice.

However, with the move to online interviews where people are expecting running and debugging some complex solutions (so you cannot hand wave trivial but potentially time consuming helper methods), coding speed can easily become the bottleneck.

> 2) give a lot of preparation to candidates beforehand, even for non-leetcode interviews, as it helps filter who can efficiently and diligently use provided information to increase their performance.

Yes, this reminds me of the netflix interview process where they told me to read the culture packet thoroughly, then quizzed me on it! It was quite easy, but you can bet that a lof candidates don't take that seriously.

Post reply on HN