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.
In my experience, the short run is always longer than we think, but the long run is always shorter than we think.
I have a slightly different experience, things always take longer and are less work than we think.
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.
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.
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.
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.
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.
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.