Hire for slope, not Y-Intercept(matt-rickard.com)
matt-rickard.com
Hire for slope, not Y-Intercept
https://matt-rickard.com/hire-slope-not-intercept/
94 comments
> A metaphor or analogy greatly oversimplifies reality and will lead you to make terrible decisions.
I think I disagree with this. Metaphors and analogies provide interesting ways to illustrate principles, and good decisions are often rooted in good principles.
Attempting to model human behavior as a one dimensional line? Yeah, not good. But remembering a person is more than the moment you meet them in? Great advice.
I think I disagree with this. Metaphors and analogies provide interesting ways to illustrate principles, and good decisions are often rooted in good principles.
Attempting to model human behavior as a one dimensional line? Yeah, not good. But remembering a person is more than the moment you meet them in? Great advice.
I think the vast majority of metaphors are pointless and end up in most of the discussion being about how the metaphor doesn't make sense or how the magnitude doesn't make sense. They are very frequently used on topics which are quite simple to understand and need no metaphor at all.
The place where I find they make most sense is explaining certain incentive structures. Take for example the Prisoner's Dilemma, you could use this as a metaphor to explain a multitude of situations where people or companies are acting in a way that seems illogical from your perspective but when you simplify it down you can see how each actor has particular incentives.
The place where I find they make most sense is explaining certain incentive structures. Take for example the Prisoner's Dilemma, you could use this as a metaphor to explain a multitude of situations where people or companies are acting in a way that seems illogical from your perspective but when you simplify it down you can see how each actor has particular incentives.
I don't think the problem is metaphor or analogy - both of these can be persuasive, and both of these can be used to illustrate complex things.
The problem is this particular kind of tech-messiah metaphor, assuming that mathematics is the only useful lense, over-simplifying everything and not even understanding what is lost [1].
Metaphors aren't the issue; metaphors crafted by people who don't really understand them are.
[1] https://xkcd.com/793/
The problem is this particular kind of tech-messiah metaphor, assuming that mathematics is the only useful lense, over-simplifying everything and not even understanding what is lost [1].
Metaphors aren't the issue; metaphors crafted by people who don't really understand them are.
[1] https://xkcd.com/793/
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.
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.
also, how would you measure someone's slope? would it even be fair to evaluate them by it?
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.
And even if you could, once interviewees know you're doing this, they could easily game it by intentionally bombing the first interview.
> You’d need two interviews separated by some time, which is obviously impractical.
My experience with multi-round interviews being stretched across multiple weeks strongly suggests otherwise.
Further, this is kind of the whole point of a probationary period, no?
My experience with multi-round interviews being stretched across multiple weeks strongly suggests otherwise.
Further, this is kind of the whole point of a probationary period, no?
My feeling is that multi-round interviews and probationary periods are less about getting a more precise view of a workers growth, and more about being extremely risk adverse in hiring.
Agreed. It wouldn't be so hard if things were linear.
All models are wrong, but some are useful.
All models are wrong, but some are useful.
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.
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.
> 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.
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.
Older people are around just as long as young people, and learn just as much (yes, in some cases more, though in my experience as a manager that is not the usual outcome, it usually falls off slightly). The difference is the baseline: a person 1 year in should at least double their experience within the first year of working for you, whereas a person with 10 years experience will increase it by around 10%. Any way you cut it, measuring the current state matters a lot more for the more experienced person than the young one (current skill is an estimator of how fast the more experienced person has been learning, whereas for a new grad it's on you to estimate that based on other factors, and current skill doesn't matter much because it will change so fast).
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.
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.
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.
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.
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.
> 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...
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...
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.
Yep, your interpretation is correct, I was sloppy with my wording.
I've seen 10+ year engineers grow at the same pace as 3-year engineers. I think this generalization is too broad.
I'm talking about improvement on a percentage basis, not absolute: even if your productivity is improving linearly at 1 awesomeness-point per year, your fractional improvement ("% awesomeness gain per year") is going to trail off over time, which means where you are when hired really does matter more the more experienced you get. Based on informal observation, most (not all) good engineers tend to improve slightly sub-linearly, so it's even more tilted.
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.
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.
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.
I posted the reply as a top-level comment, but the very questions you bring up are issues that some econ fields have taken seriously and have tried to model it empirically and test parts of it empirically. The observing all of this is a lot of where the complexity lies, as you rightly point out. If you care at all to poke further, I posted a link to a lecture series which will talk far more about this than you'd ever want to hear.
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.
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.
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.
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.
This is stupid model that mistakes brevity for insight.
But for the sake of argument Let’s assume the function metaphor to be true. The value of the employee to the firm isn’t the value of the of f(x) at a given point in time, it’s the value under the curve for an expected time horizon, so given the f’(x) and f(0) and the time horizon it’s not clear that either is better. Apart from that it’s very unlikely that f(x) is linear. It’s very unlikely that f(x) will grow to infinity. More likely is that the improvement will top out somewhere and maybe you should think about higher derivatives.
But for the sake of argument Let’s assume the function metaphor to be true. The value of the employee to the firm isn’t the value of the of f(x) at a given point in time, it’s the value under the curve for an expected time horizon, so given the f’(x) and f(0) and the time horizon it’s not clear that either is better. Apart from that it’s very unlikely that f(x) is linear. It’s very unlikely that f(x) will grow to infinity. More likely is that the improvement will top out somewhere and maybe you should think about higher derivatives.
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."
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."
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.
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.
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.
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.
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."
Yep. I think we run into a different problem, which is the diminishing return to the employer.
Even if a person's growth is linear, most companies' ability to realize a return on that growth probably isn't.
It's not that the companies couldn't benefit from experience if they knew how to realize that benefit. It's more that their processes are set up in a way that prevents the benefit from being realized. I'm thinking about heavy-handed architectural diktats and constantly changing priorities when I write this.
Even if a person's growth is linear, most companies' ability to realize a return on that growth probably isn't.
It's not that the companies couldn't benefit from experience if they knew how to realize that benefit. It's more that their processes are set up in a way that prevents the benefit from being realized. I'm thinking about heavy-handed architectural diktats and constantly changing priorities when I write this.
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.
> and then in a few years be getting intermediate value for that same entry level rate.
If you're expecting to pay someone an entry-level rate ~3 years into their career you're going to be getting exactly zero value out of them as they will get a job at a company that pays them what they're worth.
If you're expecting to pay someone an entry-level rate ~3 years into their career you're going to be getting exactly zero value out of them as they will get a job at a company that pays them what they're worth.
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?
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.
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.
In my experience, the short run is always longer than we think, but the long run is always shorter than we think.
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".
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".
I have a slightly different experience, things always take longer and are less work than we think.
Two brilliant comments right away. Wow!
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.
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.
Spherical weightless employees in a perfect vacuum.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.)
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.)
[deleted]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
Better yet, hire for area under the curve
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.
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.
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.
Whether or not this is a good idea can be debated, as demonstrated by the plethora of commentary here.
Nevertheless, this corresponds well with my lived experience in BigCo on both sides of the candidate / interviewer table. People who are almost qualified for a job, and show progression, get given the job aa a "stretch". People who have done the same job before don't get the job.
This can be interpreted as "ageism", but it's more a reflection of companies wanting to hire people that will progress (possibly into management), and not just perform the initial job at hand.
Nevertheless, this corresponds well with my lived experience in BigCo on both sides of the candidate / interviewer table. People who are almost qualified for a job, and show progression, get given the job aa a "stretch". People who have done the same job before don't get the job.
This can be interpreted as "ageism", but it's more a reflection of companies wanting to hire people that will progress (possibly into management), and not just perform the initial job at hand.
If folks are at all interested, ideas that are directly related to the point the author brings up have been studied quite in-depthly, both theoretically and empirically, in the human capital econ literature.
Gary Becker's lecture on Human Capital is a fantastic survey of the field (which he in part invented):
https://www.youtube.com/watch?v=QajILZ3S2RE&list=PL9334868E7...
Gary Becker's lecture on Human Capital is a fantastic survey of the field (which he in part invented):
https://www.youtube.com/watch?v=QajILZ3S2RE&list=PL9334868E7...
Addendum: There's also a humongous literature on organizational economics which also addresses implications of the observability of these "slopes" or "intercepts", etc.
How do you tell slope from one point?
[deleted]
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”.
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”.
“CS professor at Stanford” a place that does admissions exactly the opposite of the article.
If they are so good at potential, then why haven't they proven it yet? It's an overly simple question, but if there are many potential reasons, accept that you may be wrong about hypothetical potential.
[deleted]
This feels like something you'd find on linkedin.
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)
Because performance is linear in time, independent of anything else?
Without reading the article, I think I get it! Lol.
why use lines when you can use trigonometry? aren't we all made of waves anyway?
Ha, I've used a very similar analogy where Y-intercept represents privilege.
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.