4 ms·

Yep, I think this is either ignoring the main problems or mistaking a symptom for the disease. Certainly, people try to hire for "Ember gurus" or "10 years expe

Yep, I think this is either ignoring the main problems or mistaking a symptom for the disease. Certainly, people try to hire for "Ember gurus" or "10 years experience in Swift" or whatever else, and that goes poorly. But it's one of a dozen serious problems with tech hiring, and not near the top. If anything, I think people end up hiring for framework experience because tech hiring is hard and broken. If you're relying on outside recruiters who can't read a resume, much less evaluate somebody's past projects, then hunting specific framework keywords at least gets you relevant candidates. If your interview sensitivity is terrible, then you can't accurately gauge whether someone will pick up your language/framework quickly, so it makes sense to only hire people who've already proven they understand it. And if your onboarding and codebase are a mess, you'll want people who know the language well enough to e.g. troubleshoot a broken build on their own. Hiring people who already know everything isn't the problem with tech hiring, it's a weak effort to paper over the more fundamental problems.

nobodyandproud 7y ago
The closest profession to software is law. It’s not a problem, once firms realize what business problems they need to solve.
- Bartweiss 7y ago
  This is a good point, although I'm not sure how it transfers cleanly. Hiring lawyers seems to have two elements lots of people desperately don't want to import to hiring software devs. First, the credentialism in law is extreme and getting worse. It used to be that most states would at least let you sit the bar freely; these days becoming "self taught" or even "correspondence course" lawyer is usually prohibited by law. This is sort of understandable given the stakes of malpractice and the difficulty of judging quality, but it also implies that the bar isn't an adequate measure of skill, and creates a limited supply of law degrees at extremely high prices. Second, the desirability of lawyers is basically exponential: there are schools with graduates commanding $1,000/hour rates while other capable attorneys go unemployed. For law, this again makes some sense: lawyer-hours are not usually additive, most clients can't judge what they're getting, and buying a bad legal 'product' is usually revealed in the form of a massive expense after it's too late to fix. Software has shades of this with the "10x programmer" stuff, but only security and maybe architecture design actually reproduce the 'too late to fix' issue. Paying a CMU programmer 10x what a state-school programmer gets isn't usually going to be an effective strategy. Hiring programs like lawyers would probably lead to fewer screwups, but I think it would also waste a huge amount of money and expertise. And I'm not sure that splitting the difference is a coherent option.
  - nobodyandproud 7y ago
    I never said the hiring of lawyers is a good example :) The practice of law and law school are two completely separate things. This is something that I think Med School has done correctly. Once you finish school, you must do your residency and the school provides this. This is whete you actually learn how to practice your profession. Law school, from what I understand, doesn’t provide this crucial step. Software development does not either, and perhaps this is one of the problems. School teaches the fundamentals, but it doesn’t provide the necessary tradecraft training. So the only metrics to go by are buzzword tests, or arbitrary algorithm tests divorced from the actual job. It’s the rare interview where they test CS fundamentals—which most people should remember, unless they ask for implementation—and coding best (and worst) practices, which is currently lacking.

nobodyandproud 7y ago

The closest profession to software is law. It’s not a problem, once firms realize what business problems they need to solve.

Bartweiss 7y ago
This is a good point, although I'm not sure how it transfers cleanly. Hiring lawyers seems to have two elements lots of people desperately don't want to import to hiring software devs. First, the credentialism in law is extreme and getting worse. It used to be that most states would at least let you sit the bar freely; these days becoming "self taught" or even "correspondence course" lawyer is usually prohibited by law. This is sort of understandable given the stakes of malpractice and the difficulty of judging quality, but it also implies that the bar isn't an adequate measure of skill, and creates a limited supply of law degrees at extremely high prices. Second, the desirability of lawyers is basically exponential: there are schools with graduates commanding $1,000/hour rates while other capable attorneys go unemployed. For law, this again makes some sense: lawyer-hours are not usually additive, most clients can't judge what they're getting, and buying a bad legal 'product' is usually revealed in the form of a massive expense after it's too late to fix. Software has shades of this with the "10x programmer" stuff, but only security and maybe architecture design actually reproduce the 'too late to fix' issue. Paying a CMU programmer 10x what a state-school programmer gets isn't usually going to be an effective strategy. Hiring programs like lawyers would probably lead to fewer screwups, but I think it would also waste a huge amount of money and expertise. And I'm not sure that splitting the difference is a coherent option.
- nobodyandproud 7y ago
  I never said the hiring of lawyers is a good example :) The practice of law and law school are two completely separate things. This is something that I think Med School has done correctly. Once you finish school, you must do your residency and the school provides this. This is whete you actually learn how to practice your profession. Law school, from what I understand, doesn’t provide this crucial step. Software development does not either, and perhaps this is one of the problems. School teaches the fundamentals, but it doesn’t provide the necessary tradecraft training. So the only metrics to go by are buzzword tests, or arbitrary algorithm tests divorced from the actual job. It’s the rare interview where they test CS fundamentals—which most people should remember, unless they ask for implementation—and coding best (and worst) practices, which is currently lacking.