> What I do know, however, is that for every 1-hour interview where I evaluated if someone knew their data structures, I could have just taught them.
I don't really hear much about training. I doubt it's because we don't do it, but maybe it's not an interesting topic for discussion.
But I stopped worrying the more I worked with software engineers. They were just people, some sucked, some were great, their education almost never had anything to do with the bracket they fell into. The worst one I've ever met has a PhD. The best one I've met also has a PhD.
Then I found more people in these positions that have degrees or no degrees, and the people that work well both with degrees and without had something in common. They can more or less be taught to do anything, they can extrapolate and apply knowledge outside of the specific example initially given, and they understand the big picture/desired end results. I hate to say it so crass, but they are good at identifying the trivial bullshit and addressing it or cutting through it rather than sitting in it. They "Get it." From the ideal to what the business demands, they just get it.
Training competent people is a boon. I don't know how you seek out interested/curious competency and then train it, but if we can figure that out, it'd be cool. I'm really tired of working with people who have degrees and jobs because their mothers told them it pays well. Computer Scientists with no interest or curiosity about computers.
It also ignores the breadth of knowledge you likely want a candidate to have (and are just trying to sample at through a short few interviews). How many hours of training are you willing to sign up for? How confident are you that the knowledge will "stick" for any given candidate? Are you going to fall back to GPA and school prestige to measure how well they've retained knowledge in the past? That seems like a step in the wrong direction.
I do agree that the "stickiness" is iffy, but it usually sticks pretty well. You then have a second problem that can be described as "when you have a hammer, everything is a nail" as they use their new fancy hashtable everywhere.
Also the role specifics matter here. It might be ok to bring in a junior who needs lots of mentoring onboard. For a tech lead who is going to be driving the direction of a team, I'd expect them to be up to speed and autonomous very quickly.
And it's a pretty insightful comment, because being able to be taught a practically useful algorithm, and use it on a question, in just an hour is a sign of a good candidate. Interviews should often be run just like that.