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

Hire for slope, not Y-Intercept

matt-rickard.com

Post reply on HN
Print view View original

21–30 of 95 posts

Re: Hire for slope, not Y-Intercept

#21

Post by sokoloff »

whatshisface wrote: post #13
Panini_Jones wrote: post #9

Earlier quoted context omitted.

Internships are a form of interviewing and provide a duration over which you can test how fast the person learns.

People coming in from internships only make up a small portion of your staffing needs, and with the general practice of never giving raises and expecting 2-year turnover, you will never see your intern in a senior or even midrange role.

Never giving raises and expecting 2-year turnover are pretty much one thing rather than the two that they might initially appear to be.

Re: Hire for slope, not Y-Intercept

#22

Post by rckrd »

dyeje wrote: post #20

I don't get it. X is time, Y is progress towards some goal. What's the second line? The threshold at which the goal is achieved?

Two lines to represent the difference between (high slope, low intercept) and (low slope, high intercept)

Re: Hire for slope, not Y-Intercept

#23

Post by sokoloff »

efitz wrote: post #16

How do you tell slope from one point?

When you’re working with someone on a project, you get lots of datapoints, some of which are pretty close to a direct measurement of m (not y, but m directly).

When the team is discussing something, are they following along, contributing, remembering and integrating what they were exposed to last week? Or are you telling them for the third week in a row the exact same thing?

This is not anything like “once a year tell HR your estimate of the current y value and HR will use Excel to calculate the slope”.

Re: Hire for slope, not Y-Intercept

#24

Post by evgen »

onion2k wrote: post #5

This is great advice that entirely ignores the fact that the best way to progress as a developer is to change job (or at least to change team within a company). In a market where moving on every couple of years at most is the aim of young candidates hiring for anything long term is just silly.

Exactly right. It seems based on the unrealistic assumption that someone will have a long-enough tenure at your company for the two lines to cross. It is far more likely that they will jump ship for a better baseline assumption (and the base salary that goes with it) than that they will stick around for you to see the two lines cross.

When discussing lifelong learning and skill growth it is also worth being honest in the description of the lines. Few have a constant upward slope, they usually plateau for a bit and can even turn negative if you get stuck in an obsolete skill set. Just because someone's 'slope' looks positive now does not mean that will continue.

Re: Hire for slope, not Y-Intercept

#25

Post by agallant »

I'm a huge fan of lifelong learning, and overall agree with this post. But, from a hiring perspective, it is missing a few important details:

1. Sometimes you have things that need to be achieved in a time-sensitive fashion, i.e. the time to ramp up may be problematic, and "taking a chance" may have real business ramifications.

2. Even if you don't have anything urgent, naturally there should be some discount factor for future utility (due to intrinsic uncertainty, etc.) - it's still positive, but remember "I'll gladly pay you Tuesday for a hamburger today."

3. Learning is not a clean linear process, and is also hard to really suss out in a few interviews - I still absolutely look for it in people I hire, but it's pretty easy to claim you take a few MOOCs and harder to know if you really engage with new ideas on a regular basis.

Again, I still very much agree with the spirit and substance of the post, but hiring is complicated, and as with most complicated things there are multiple considerations to balance.

Re: Hire for slope, not Y-Intercept

#26

Post by flashgordon »

AvocadoCake wrote: post #15
whatshisface wrote: post #6

How do you tell who will learn faster, IQ tests and personality inventories? I don't see how you can put this in to practice when all known forms of interviewing test where the candidate is today, not how fast they can learn.

I think a large part of learning faster is having a better willingness/eagerness to learn. That's something that can be gauged to some degree during both the technical and non-technical sections of the interview.

Mostly yes but a lot of tech hiring interviews penalizes asking too many questions and expects you to solve x leetcode problems in y time.

Re: Hire for slope, not Y-Intercept

#27

Post by dyeje »

rckrd wrote: post #22
dyeje wrote: post #20

I don't get it. X is time, Y is progress towards some goal. What's the second line? The threshold at which the goal is achieved?

Two lines to represent the difference between (high slope, low intercept) and (low slope, high intercept)

I see. When would the low slope ever seem attractive though? When its Y starts out higher?

Re: Hire for slope, not Y-Intercept

#28

Post by rckrd »

agallant wrote: post #25

I'm a huge fan of lifelong learning, and overall agree with this post. But, from a hiring perspective, it is missing a few important details: 1. Sometimes you have things that need to be achieved in a time-sensitive fashion, i.e. the time to ramp up may be problematic, and "taking a chance" may have real business ramifications. 2. Even if you don't have anything urgent, naturally there should be some discount factor…

Agreed. It wouldn't be so hard if things were linear.

All models are wrong, but some are useful.

Re: Hire for slope, not Y-Intercept

#29

Post by vp8989 »

kzrdude wrote: post #8
whatshisface wrote: post #6

How do you tell who will learn faster, IQ tests and personality inventories? I don't see how you can put this in to practice when all known forms of interviewing test where the candidate is today, not how fast they can learn.

It's far from the only facet, but slope vs y-intercept could be recast as young vs old or newly graduated vs tenured.

Agreed. It's not explicitly stated in the post but why would amount of experience (aka age) and Y-intercept even be mentioned at all if not to imply that more experienced people have a less steep slope.

I think this is a false axiom that young people have more potential. You actually have very low signal about people that age. They just went from a very structured context to a very unstructured context, so you may be assuming a lot from how they operated in the former context that may not be true now that they are in a different one.

This kind of ties in with another thread on here about OP being disillusioned with the skill level of their FAANG colleagues.

Re: Hire for slope, not Y-Intercept

#30

Post by jerf »

kzrdude wrote: post #8
whatshisface wrote: post #6

How do you tell who will learn faster, IQ tests and personality inventories? I don't see how you can put this in to practice when all known forms of interviewing test where the candidate is today, not how fast they can learn.

It's far from the only facet, but slope vs y-intercept could be recast as young vs old or newly graduated vs tenured.

Technically speaking, it's true the slope must by necessity decrease as you get older, but the effect is grotesquely oversold. It can be compensated for by the fact that when an older person goes to pick up some new tech, they're quite likely to have some previous tech like it they've already picked up and just be filling in some gaps instead of starting from scratch.

I don't think the correlation is large enough in practice to be a useful metric. I'm pretty sure I learn new things faster than I did twenty years ago because usually I have a lot less stuff to learn. Learning how to spell queries for your tenth database is much easier than the first one, for instance, and I've got SQL, NoSQL, columnar, embedded, and I dunno how many other adjectives of experience vs. some relatively young programmer encountering their second database type. My slope on such a task can approach vertical whereas a younger person may need a couple of weeks.

(This example is on my mind because literally today I'm helping someone diagnose why a query is slow on a database I've never even used before. But I understand the fundamentals of how the DB works, and can read the docs really quickly now, because I don't even know how many DBs I've used at this point. Depends on how you define them.)

Post reply on HN