[HN Gopher] Hire for slope, not Y-Intercept
___________________________________________________________________
Hire for slope, not Y-Intercept
Author : rckrd
Score : 88 points
Date : 2021-08-18 14:27 UTC (8 hours ago)
(HTM) web link (matt-rickard.com)
(TXT) w3m dump (matt-rickard.com)
| dyeje wrote:
| 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?
| rckrd wrote:
| Two lines to represent the difference between (high slope, low
| intercept) and (low slope, high intercept)
| dyeje wrote:
| I see. When would the low slope ever seem attractive though?
| When its Y starts out higher?
| rckrd wrote:
| Yep. We all start from different starting positions. That
| makes a big difference early on (what school did this
| person go to? what have they already accomplished?) and
| less later on
| onion2k wrote:
| 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.
| rckrd wrote:
| I actually think the advice is aligned with that. Young
| candidates have high slope and low intercept. I don't think the
| aim of ambitious young developers is to move jobs and maximize
| pay, but rather to be in a role where they can continue to
| optimize for slope. That's the kind of company you want to
| build and the kind of developer you want to hire.
| kbenson wrote:
| I'm pretty sure it's both. The problem with a company being
| both is that it generally seems very hard for companies to
| promote to market value. This makes sense to a degree when
| you consider that the company has to be a bit discerning as
| to what it trusts in those negotiations. I can say I've
| gotten an offer for anything I want. I can say the going rate
| for my position is what I see being offered on the market,
| even if I might not be hired for those positions. There will
| most likely always be a tension between what a company thinks
| someone is worth and how they value themselves, so there will
| always be the risk that someone believes they can get more
| elsewhere. I'm not sure overpaying would even help this,
| people might just adjust perceived their self worth
| accordingly.
| evgen wrote:
| 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.
| efitz wrote:
| How do you tell slope from one point?
| [deleted]
| sokoloff wrote:
| 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".
| BossingAround wrote:
| It's kind of interesting many commenters here _require_ a _proof_
| during an interview.
|
| So, while this can be highly flawed, how about asking the
| candidate? I find more often than not that if I ask the candidate
| how excited they are about learning stuff, they tell the truth.
| Especially when I probe a bit deeper, what do they want to learn,
| why, and, most importantly, what is their learning process.
|
| If someone indicates they have a periodic study system in place,
| that's a strong indicator in the right direction. If someone
| tells me they have a goal they are achieving right now, that's
| amazing. If they can even estimate how long it will take them
| based on previous data, that sounds like a winner to me.
|
| At that point, I am confident that they want to learn, and I have
| to assess other things, like what's their starting point,
| personality, etc.
|
| I don't have a proof of their slope for learning. They could very
| well be lying just to get the job, but it's way better than
| disregarding slope because you can't prove it.
| mcherm wrote:
| Suppose my interviewing process is rather limited and I can only
| measure the y-intercept with pretty severe error bars... like to
| within +/- 30%. Also, my interviewing process is even MORE
| clueless at measuring the slope... it could be tilted +/- 30
| degrees from where it is (note: that means the slope might well
| be negative) and also THAT measurement is especially subject to
| unconscious racial and similarity bias.
|
| Then what do I do?
|
| I might choose to focus more on the y-intercept because I at
| least have a vague idea of what that is by reviewing the resume
| plus a few hours of writing code on a whiteboard (which is a
| terrible assessment), whereas my ability to measure slope is
| almost meaningless.
| lumost wrote:
| TBH every time I've been in a debrief where someone was pushing
| to hire an individual who didn't quite clear the bar it's
| because the candidate "reminded them of an earlier version of
| themselves". This reminder is the most biased form of hiring
| I've encountered, as it's almost entirely based on the
| interviewer assuming context about the candidates background
| and assuming that that background leads to success.
| Dumblydorr wrote:
| How does poaching relate to this? Obviously higher Y intercepts
| will get a lot more done initially, but they'll then be poached
| away. Same could be true of the slopey person, who may show more
| drive in their career and want to hop out once they've sloped up
| through your training.
|
| Also, will that Y intercept person come at a huge premium? Can
| you afford that initial added burst of capital, or can you wait
| longer and hopefully see return on the sloper?
|
| Anyway, you can't know someone's slope in the future at your job,
| as if that slope is even a constant value. It's much easier to
| know someone's Y intercept, you look at what they've done and
| what they can do now. That's the actual facts of hiring, vs a
| belief in potential slope, where uncertainty is more dominant.
| ilc wrote:
| You CAN estimate slope. Look at past performance.
|
| If a person switches from a role doing front end, to a role
| doing back end... what does that say about their slope? Now
| they goto DevOps/SRE? What about shifting towards UI Design?
|
| What do you do when you are in a situation where near nobody
| knows your tech stack... you'd better be able to estimate
| slope.
| BossingAround wrote:
| > If a person switches from a role doing front end, to a role
| doing back end... what does that say about their slope? Now
| they goto DevOps/SRE? What about shifting towards UI Design?
|
| Absolutely nothing.
|
| I've seen people switching from role to role because they
| were bored, and because they got an opportunity elsewhere,
| while not learning much in their short 6-12 months on the
| previous role.
|
| I'm not saying that one can't learn a lot within 6-12 months
| on a job. I'm saying you won't know as an interviewer if this
| is your only data point.
| hdjdkdkd wrote:
| "CS professor at Stanford" a place that does admissions exactly
| the opposite of the article.
| whatshisface wrote:
| 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.
| kzrdude wrote:
| It's far from the only facet, but slope vs y-intercept could be
| recast as young vs old or newly graduated vs tenured.
| vp8989 wrote:
| 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.
| murderfs wrote:
| > I think this is a false axiom that young people have more
| potential. You actually have very low signal about people
| that age.
|
| That's _exactly_ why they have more potential: they 're
| much higher variance. A lot of the "high-potential" people
| that have a bunch of experience will have already
| demonstrated this, and they'll be making $500k+ at a FAANG,
| which most companies won't be able to compete with.
| [deleted]
| jerf wrote:
| 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.)
| tommysydney wrote:
| In our interview set, there is always a question that requires
| expert-level knowledge about a topic that the interviewee
| likely not know (well we'll ask them an easier question first
| and see if they can answer), then allow them to Google, and we
| watch the way they do it, their reading comprehension,
| analytical skills, generalization, assumption checking, .etc
| will all review. Harder to fake than leetcode questions.
|
| Edit: our assumption is that someone can pull that off in 40-60
| second Googling is a super-fast learner. So far we're doing
| great with our team.
| Panini_Jones wrote:
| Internships are a form of interviewing and provide a duration
| over which you can test how fast the person learns.
| whatshisface wrote:
| 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.
| sokoloff wrote:
| Never giving raises and expecting 2-year turnover are
| pretty much one thing rather than the two that they might
| initially appear to be.
| Panini_Jones wrote:
| Your parent comment states that there exists no known form
| of interviewing that captures the trajectory of the
| candidate. I stated the existence of one, thus showing that
| there exists a known form of interviewing that captures the
| trajectory of the candidate.
|
| I didn't state that internships solve all of your hiring
| problems. I also seem to work in a different company than
| you because our tenure is higher than 2 years and many
| interns make it to the senior level.
| AvocadoCake wrote:
| 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.
| flashgordon wrote:
| 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.
| nitrogen wrote:
| _penalizes asking too many questions_
|
| Nothing was more frustrating when interviewing a candidate
| to be given like 5 minutes notice, put in a room to pair
| interview with a fellow engineer, and the fellow engineer
| running things like a pop quiz gameshow mixed with a
| courtroom interrogation, while I was trying to more subtly
| coax the candidate into comfortably showing their skill
| level and working style. The candidate basically shut down
| and stopped answering my fellow engineer's questions, but
| still answered mine. My colleague interpreted this as
| personal hostility, and things went downhill from there.
|
| All that is to say, you will definitely learn more about a
| candidate if you take an interactive, rather than
| interrogative, approach, and you really need to be on the
| same page with your fellow interviewers about that.
| HugoDaniel wrote:
| why use lines when you can use trigonometry? aren't we all made
| of waves anyway?
| [deleted]
| sweetcheekz wrote:
| A lot of the comment section highlights the obvious problem: this
| is fine theoretically (maybe even obviously correct), but much
| harder to get right in practice.
| yashap wrote:
| On top of that, it's only even maybe-obviously-theoretically-
| correct if the employee stays a long time. If they stay for
| 5-10 years, I'd think rapid improvement tends to beat current
| ability. If they only stay for 1-3 years, though, the quick
| learner likely provides less value. Even if they catch up after
| say 2-3 years, they were providing less value while catching
| up.
| kazinator wrote:
| Hire for polynomial degree, not slope! But watch for negative
| coefficients, particularly on the highest powered term.
|
| Wow, this shit writes itself.
| pavas wrote:
| Hire for O.
| tootie wrote:
| Ha, I've used a very similar analogy where Y-intercept represents
| privilege.
| agallant wrote:
| 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.
| autokad wrote:
| also, how would you measure someone's slope? would it even be
| fair to evaluate them by it?
| ashtonkem wrote:
| Even if it was linear, you can't tell the slope of a line
| from one measurement, and an interview is one measurement.
| You'd need two interviews separated by some time, which is
| obviously impractical.
| rckrd wrote:
| Agreed. It wouldn't be so hard if things were linear.
|
| All models are wrong, but some are useful.
| cornel_io wrote:
| Nitpick: you're usually not measuring y-intercept, but y value at
| a point in time. For young people the two are pretty close, but
| for older ones not so much.
|
| And for young devs, I 100% agree that slope is more important:
| the 1-3 years they're with your company will be ~half their
| careers or more, and they will hopefully grow quite a bit.
| Whenever you hire someone green you're betting almost exclusively
| on growth as opposed to current skillset.
|
| For seniors (say 10 years and beyond), they're not going to be
| with you long enough for progress to make a huge difference,
| especially if they're decent to start out with - maybe that's not
| true 100% of the time, some people will stay around longer than
| expected and some people really do keep growing rapidly even into
| late career, but it's a reasonable guess. You're paying them
| primarily for the growth they've already done.
| dharmab wrote:
| I've seen 10+ year engineers grow at the same pace as 3-year
| engineers. I think this generalization is too broad.
| saurik wrote:
| > the 1-3 years they're with your company will be ~half their
| careers or more
|
| I am misunderstanding something seemingly-fundamental... are
| you saying that the average career of a software developer is
| only 2-6 years? If so, I guess I need to feel much older than
| I'd ever previously have thought...
| abrokenpipe wrote:
| Thats how I read it at first, but I think he is saying if
| someone has 2yrs experience then working another 2 years
| somewhere else would make that second job half of their
| current career. I think "work experience" would have been a
| better term to use.
| chongli wrote:
| Nitpick of a nitpick: for an interviewer, t=0 is right now.
| They're interested in predicting your future performance on the
| job, assuming they hire you, and so it makes sense for positive
| t-values to be the future and negative t-values to be the past.
| monocasa wrote:
| Yeah, exactly what I came in here to say. It's more vectors
| than slopes. You add the vectors of where they're at and where
| they're going.
|
| You don't count against someone for absolutely already killing
| it even if you don't expect them to have the same increases in
| ability as a fresh grad with a lot of basics still to learn.
| dimal wrote:
| > For seniors (say 10 years and beyond), they're not going to
| be with you long enough for progress to make a huge difference,
| especially if they're decent to start out with - maybe that's
| not true 100% of the time, some people will stay around longer
| than expected and some people really do keep growing rapidly
| even into late career, but it's a reasonable guess. You're
| paying them primarily for the growth they've already done.
|
| I strongly disagree. Why would I not be around as long as a
| younger person? Most young people last about 3-5 years in a job
| as far as I can tell. As I get older, I'm jumping around less.
| And I'd say that my skills are growing faster than I was when I
| was younger. I don't waste time on a lot of fluff that I would
| have when I was younger. I focus on areas of growth that are
| more likely to have an impact, not only on myself but on the
| rest of my team. I see the same patterns in other older
| engineers I work with.
| ashtonkem wrote:
| I don't think there's any evidence that senior devs stick
| around longer than junior devs. Senior devs are often in
| extremely high demand, and can change jobs more easily.
| YZF wrote:
| Senior people will still learn the domain unless you're hiring
| them to do something they already know and/or is trivial. I
| think even for the most senior it's like 6-12 months to really
| come up to speed in a new role and then over the next few years
| there's still growth that is related to the growth of the
| project. The senior person is still going to be a lot more
| effective 3-5 years in assuming you can keep them engaged.
| lxe wrote:
| It always depends on the context.
|
| You can hire a senior IC who specializes in one thing only and
| that one thing is what keeps your business running -- doesn't
| matter if they don't progress further faster.
|
| Or you can hire someone inexperienced and spend X years training
| them until the intercept. But how long is X? There's a lot of
| risk to take on here.
| rckrd wrote:
| In my experience, the short run is always longer than we think,
| but the long run is always shorter than we think.
| wcarss wrote:
| related, people over-estimate impacts in the short run and
| under-estimate them in the long run.
|
| For example, a common 2015 sentiment: "self-driving cars are
| going to put everyone out of work imminently", compare to a
| common 2021 sentiment: "self-driving cars still aren't fully
| ready -- they likely never will be".
| js8 wrote:
| I have a slightly different experience, things always take
| longer and are less work than we think.
| russfink wrote:
| Two brilliant comments right away. Wow!
| dasil003 wrote:
| This article is ambiguous. Are we talking about the ramp for
| onboarding and productivity within a specific company/role, or
| are we talking about some measure of absolute skill and
| productivity? The former is a legit consideration, the latter is
| meaningless without knowing the ceiling (ie. a very senior person
| is not growing fast is not a problem if they already have
| exceptional abilities).
|
| Also, in either case, it's very misleading to show a linear graph
| as presented here. These graphs will be much more curved in both
| cases. The entire trick of hiring is anticipating what those
| graphs will look like down the line.
| bitwize wrote:
| Companies usually want new hires to "hit the ground running" with
| projects in $MAJOR_TECHNOLOGY and usually don't really care about
| employee growth. Corporate Agile processes are there, in part, to
| mitigate the effects of mediocre programmers and drag their bog-
| standard enterprise applications across the finish line _in spite
| of_ the competence, or lack thereof, of developer staff. In that
| environment, yes, you want to filter out anyone who doesn 't meet
| some baseline threshold of facility with your tech stack. But you
| don't really care how they grow as developers; someone with a
| steep "slope" may be a net negative as they're at risk of growing
| bored and leaving when the business needs them most.
| kizer wrote:
| Without reading the article, I think I get it! Lol.
| ebiester wrote:
| I dislike this in that it promotes ageist thinking in many
| people.
|
| There is a presumption that younger people will have a higher
| slope. In one sense, it's true. Consider the weightlifting
| analogy. It is easier to train to deadlift from half your body
| weight to 1x your body weight, than is is to deadlift 2x your
| body weight to 2.5x your body weight.
|
| Similarly, capable junior developers become "mid-level" and
| sometimes "senior" developers in two years. They learn how to
| build a system. They learn how to be on a team. On good teams,
| they learn good design principles. Fast forward and take that
| same developer with 18 years of experience. In the next two
| years, how much are they stretching?
|
| Or maybe, we can consider the intercept. It takes that developer
| 2 weeks to become proficient in a new library, and it takes a
| junior developer of similar general aptitude 2 months. How do you
| consider growth there? For the more experienced developer, their
| actual slope is pretty low: they didn't learn any new concepts,
| they just learned a new syntax. The junior developer has a high
| slope: they learned entirely new concepts.
|
| So, we will diminish the slope of an experienced developer in
| most cases.
|
| So, don't use this as an excuse to discriminate against the 60
| year old developer because you're "worried about the slope."
| slumdev wrote:
| A lifelong learner with decades of experience will outperform a
| 5-year "senior" many times over, not just in output but also in
| the headaches and mess that they save you from having to
| experience.
|
| What we need is better titling. There's nothing shameful about
| being a junior or a mid-level for multiple years each. Until we
| get that, one can usually tease out the "seniorness" of the
| position by discussing salary.
| ebiester wrote:
| So, that's an orthogonal problem. I was pointing to the
| direct advice and suggesting that people will look at this
| advice and their prejudices will lead them to hire a younger
| person over an older person because the older person will be
| mispercieved as having a "lower slope."
| karmakaze wrote:
| I don't find this at all. Myself as an experienced developer
| can drop into any situation, survey the terrain, not knowing
| any of the terminology or idioms same as with a junior. I would
| much more quickly be able to map out what I find into parallels
| of what I already know and be proficient much faster than
| someone who's climbing slope quickly. Basically I was high up
| on one hill and merely learned to translate (shift over) to
| another one.
|
| The way to deal with this and the other is to think of the
| y-axis in terms not of learning, but of becoming proficient.
| The better job posts are clearly aware of this, stating what
| stack they use, but that they're open to experts on any stack.
|
| There's also actual benefit to having a lot of high slope
| interns. They are sponges and learn fast, have the least to
| unlearn or conflicting past knowledge, and together with high
| y-intercept experts is the best combo I've found.
| cortesoft wrote:
| This is all about value to the company... they have to pay the
| 60 year old the actual value of their work, because it is
| established and known. The 22 year old they can pay at an entry
| level rate, and then in a few years be getting intermediate
| value for that same entry level rate.
| ebiester wrote:
| How often are early developers staying for long enough to
| realize that value anymore? Or, alternatively, how often are
| they given pay bumps because it would otherwise be logical
| for them to leave?
| adverbly wrote:
| Seriously?
|
| What are you are hiring using y=mx + b?
|
| I suppose you also assumed that all employees are mass-less,
| friction-less, perfect spheres as well?
|
| If you are gonna oversimplify, why not just say "Hire for
| integral"?
|
| I can't even.
| TheOtherHobbes wrote:
| Spherical weightless employees in a perfect vacuum.
| SuboptimalEng wrote:
| Better yet, hire for area under the curve
| beebmam wrote:
| Stop believing metaphors and analogies are persuasive.
|
| There's no reason to think that company performance is linear, or
| fits any basic function at all. Reality is far more complex than
| this. A metaphor or analogy greatly oversimplifies reality and
| will lead you to make terrible decisions.
|
| Please, please stop believing things just because the person who
| is making the claim sounds confident. I'm begging us, as a
| culture.
| chmod600 wrote:
| That's kind of an odd way to look at things, because people are
| on some kind of curve.
|
| A steep slope today might plateau very soon due to various
| limitations. The projects that seem great today might bog down in
| technical debt before release. The project that just launched
| with great reviews might have operational problems as people
| start using it.
|
| All of these things will take the shine off the potential you see
| today, and make a track record with actual results seem
| appealing.
|
| And it also explains why people stop learning new tech: because
| they are learning from the mistakes they made earlier, which will
| make them better at seeing projects through the entire lifecycle.
|
| But if you are trying to impress investors today, then yes, you
| need a lot of steep slopes that are visible now. And hopefully
| your company reaches escape velocity before those limiting
| factors creep in.
| callmeed wrote:
| This is a nerd way of saying what I already do, which is
|
| "hire people with a high ceiling"
| aeternum wrote:
| As we all fool ourselves into thinking we have any capability
| whatsoever in predicting that ceiling from a few hours of
| interview.
| yobbo wrote:
| Because performance is linear in time, independent of anything
| else?
___________________________________________________________________
(page generated 2021-08-18 23:01 UTC)