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

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.

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

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.