The article basically says, as I'm reading it, that it's good to use the perfect technical solution to a problem. However that is a very short sighted and narrow look at software engineering. Software engineering is a team effort, a business effort and filled with unknown unknowns.
If you've written everything in X then ensuring that your next project is also in X (even if X isn't perfect for it) has many advantages. Your bus factor is high since your whole team is familiar with the technology. There are fewer unknown issues that you'd hit versus a new approach. You'll be able to re-use already written code so getting things running will be faster. There'll be fewer drawn out arguments and discussions on technology choice at every juncture. There will be more eyes able to properly review the code and choices made.
Hiring and overarching technological decisions are as much about business as technology. I've seen many engineers hired who want to rewrite everything in Y because they're not familiar with X. The business gain of it is negative but they still push for it.
I'm not saying that hiring only X is the best choice all the time but rather that a middle ground based on the specifics of the business is necessary. A flat out decision to never hire explicitly for X is as blind as one to without thought always hire for X.
the article isnt suggesting you should hire people who only know a different framework from the one you are using, but that you should hire people who are capable of being productive in all sorts of frameworks.
If they've used a variety of frameworks and worked on a variety of different projects with varied architectures, it's pretty easy to assume they're not only willing but capable of learning new things. I can pickup pretty much any framework in any language and start utilizing it, but I can assure you it will take me at least a few weeks of learning and using examples/templates to get in the groove of things and a month or so to start really getting into leveraging capabilities. If it's a terribly designed framework, API, or very oddly structured language, it may take a bit more time--or if its leveraged in a massive codebase you need to understand that's poorly documented (were no longer talking about the framework itself though).
Of course if you're trying to measure how quick someone can pickup a framework or if they're capable of "hitting the ground running" on arbitrary framework X with arbitrary existing codebase Y with deliverables/output that assume no learning curves while having no desire investimg in long term talent retention, this approach isn't for you. If minimizing time to market is your main goal, this approach isn't for you. If you want to produce something different where time to market can still reasonable but a bit slower, this approach may be for you.
Exactly - I would have said "how do you measure that" is the fundamental problem with tech hiring. That's an incredibly hard thing to judge by any measure short of "hire them and see".
Its an indirect measure of learning ability rather than directly asking for skills on 300 different frameworks.
I say indirect because I do not see any evidence of any firm hiring this way...yes MS has stories of hiring someone based on CS or Math level skills BUT we are at a place in time where in fact due to emphasis on UX and cognitive science where Liberal Arts skills is a more important gauge of learning abilities when facing new frameworks and challenges. IMHO
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.
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.
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.
Last time I did 'HR' training. They told us all about how to judge people.
You can't hire someone who doesn't have a firm handshake.
You can't hire someone with typos on their resume.
You must have that university degree right.
You can't hire someone who is a convict.
You can't hire old people.
So after HR has already eliminated all these people. They are left with the bottom of the barrel people who are apparently superman with no character flaws.
Hiring is inherently discriminatory, you're trying to pick the best person for the job. Of those examples, I think only the age one falls under title VII. Some states have more protections around convicts I think.
spell checkers are not magic though, and can be fighting with auto-complete and other auto correction processes.
I think it's more common than ever to be typing correct phrases in English be have it replaced by something else matching the user's native language, or a more common word that just doesn't fit in the phrase that was written.
Of course it's a good sign if someone reread everything before it gets submitted, but otherwise having some minor typo shouldn't stop a developper for instance from getting an interview IMO.
> Hire people with fundamental skills, not framework or technology skills
I think this is the most important advice for employers. Companies often hire people that have experience in as many tools in their current stack as possible. Few of them realize that in 5 years their stack can be entirely different, and that more important than knowing current tools is the ability to learn the new ones.
The problem is that this is less and less feasible. More and more I see candidates that come just from "Angular Bootcamps" and similar who do not know fundamentals. Even people with a degree struggle with them.
Following Sijin´s competency matrix, most of the people I interview fall in the first level, not really knowing much about stuff.
This article is basically a complaint masquerading as advice.
> There once was a company with 34 employees and 34 different titles
Don’t be coy with us ;) We know who you’re talking about.
Presuming that all tech hiring is broken, and that your article is for people who think tech hiring is fine, without any data to support your claim is going to get your advice ignored.
Long ago, I designed and developed a medical computer for a well-known manufacturer. If you walked into any eye doctor or surgeon today and mentioned its name, they would know what it is.
I started my own company but over the past five years, I would consistently see three former co-workers from that same company. I told them I was thinking of selling out and--jokingly--said I would re-apply for my old job. The response was always positive. "You should!", they'd say, "Put me down as a reference!".
Last October, I sold out. Last January, I ran into one of those co-workers. He's now a project manager. The other two co-workers were actually my bosses, one of whom is now a "Fellow". "There's an opening," he said, "Come apply at put me down as a reference."
So I did. Never heard anything back. I called my friend who talked to the "Fellow". That guy gave me the email of the headhunter who was now in charge of all hiring and told me to mention all three of their names. The headhunter replied and told me the job was, essentially, working on the same product I designed and would I be interested in working on a new version of that.
So I sent my resume which shows that I've been working on almost the exact same thing and that I had worked for that company for seven years on that exact same product and have three high level managers and former bosses who all encouraged me to apply for that job.
Never heard from him.
My former boss, who was the Director of Engineering and is now a "Fellow" is actually now retired and only works there part-time. He said he has no say into how they do things now and all hiring is done through the headhunter. The project manager is in a different department now so they don't care what he thinks. The other engineering manager also retired and, apparently, no one cares about his thoughts either.
I think, based on similar experiences, this happens when the organization is either not actually hiring for the position or is dealing with severe internal political conflicts.
He seems to miss a point about the "meta" of hiring when avoiding framework experience vs design.
Namely that how canidates advertise and actual talent and abilities may not align fully. It doesn't make sense to emphasize their bests if nobody is interested or it is taken for granted. Besides they have to try to play to more than you and filtering on arbitraries is how you miss talent, boost expenses and increase delay.
Even working on the core team at some of the world's most prestigious software companies, most of the work I've seen has been completely doable by any competent programmers who can communicate with their teams and organize their own time. I've only run across maybe a single bug per 3-4 years that actually required a superb coding prodigy to fix.
Interview coding tests select for gladiators when these companies actually need legionnaires
I'm going to borrow your gladiators vs. legionnaire analogy. Legionnaires need leaders and leaders need followers. There's something in those thoughts. Thanks.
This is good advice. However, unless it can be rewritten to appeal to a CFO, the important guidance will never reach the people who define the positions and filter candidates.
Executive management needs to understand WHY fundamental/generalist skills are more valuable than specialized skills (or at least are of comparable value except in rare cases). And the "why" that most executives understand is "because it results in more profit long term".
Few executives or hiring managers are technically experienced enough to really know what skills are required to do a certain job. Since they know they don't know, they make effort to be very specific and target the technologies (and frameworks) that the person they are replacing was known to be using. If it's a new position, they have selected a popular stack based on what other people in their industry are using. In the mind of the manager, it makes practical sense to aim for exactly what they believe they need.
Successfully delivering this message to the right audience would require a great and charismatic communicator. Unless this leader is already famous, I don't see the advice having a lasting impact. Heck, even if... I still don't expect lasting impact. Companies have been getting by ok (measured by executive compensation and shareholder value) so far, so putting in the extra effort and risk for possibly a better long term result isn't likely to happen.
There is a bright side to this situation: some very talented people who don't fit the current hiring process may go off and do something on their own (or with others like them), resulting in great new things. In fact, that's usually how innovation happens.
It is easier to train the technology than the business. Understanding the business and it's needs is usually more valuable than a tech stack. I do not see that being mentioned at all.
40 comments
[ 7.4 ms ] story [ 120 ms ] threadIf you've written everything in X then ensuring that your next project is also in X (even if X isn't perfect for it) has many advantages. Your bus factor is high since your whole team is familiar with the technology. There are fewer unknown issues that you'd hit versus a new approach. You'll be able to re-use already written code so getting things running will be faster. There'll be fewer drawn out arguments and discussions on technology choice at every juncture. There will be more eyes able to properly review the code and choices made.
Hiring and overarching technological decisions are as much about business as technology. I've seen many engineers hired who want to rewrite everything in Y because they're not familiar with X. The business gain of it is negative but they still push for it.
I'm not saying that hiring only X is the best choice all the time but rather that a middle ground based on the specifics of the business is necessary. A flat out decision to never hire explicitly for X is as blind as one to without thought always hire for X.
Of course if you're trying to measure how quick someone can pickup a framework or if they're capable of "hitting the ground running" on arbitrary framework X with arbitrary existing codebase Y with deliverables/output that assume no learning curves while having no desire investimg in long term talent retention, this approach isn't for you. If minimizing time to market is your main goal, this approach isn't for you. If you want to produce something different where time to market can still reasonable but a bit slower, this approach may be for you.
The right tool for the right job AND shop, or you end up with a major maintenance nightmare.
Because any developer with a breadth of experience and a solid foundation can instantly see the intended use cases for said toolkits.
I say indirect because I do not see any evidence of any firm hiring this way...yes MS has stories of hiring someone based on CS or Math level skills BUT we are at a place in time where in fact due to emphasis on UX and cognitive science where Liberal Arts skills is a more important gauge of learning abilities when facing new frameworks and challenges. IMHO
I don't think this even scratches the surface of what's hard about tech hiring and where the flaws are in practice.
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.
It’s not a problem, once firms realize what business problems they need to solve.
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.
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.
You can't hire someone who doesn't have a firm handshake.
You can't hire someone with typos on their resume.
You must have that university degree right.
You can't hire someone who is a convict.
You can't hire old people.
So after HR has already eliminated all these people. They are left with the bottom of the barrel people who are apparently superman with no character flaws.
Then we wonder why we can't seem to hire anyone.
This one I can kind of agree with. Should really double check before you send something like that around. Spell checkers exist.
I think it's more common than ever to be typing correct phrases in English be have it replaced by something else matching the user's native language, or a more common word that just doesn't fit in the phrase that was written.
Of course it's a good sign if someone reread everything before it gets submitted, but otherwise having some minor typo shouldn't stop a developper for instance from getting an interview IMO.
but also: 'API Influencer' as job title? wow.
Make sure the person writing it has at least one interesting insight.
I think this is the most important advice for employers. Companies often hire people that have experience in as many tools in their current stack as possible. Few of them realize that in 5 years their stack can be entirely different, and that more important than knowing current tools is the ability to learn the new ones.
Following Sijin´s competency matrix, most of the people I interview fall in the first level, not really knowing much about stuff.
> There once was a company with 34 employees and 34 different titles
Don’t be coy with us ;) We know who you’re talking about.
Presuming that all tech hiring is broken, and that your article is for people who think tech hiring is fine, without any data to support your claim is going to get your advice ignored.
Long ago, I designed and developed a medical computer for a well-known manufacturer. If you walked into any eye doctor or surgeon today and mentioned its name, they would know what it is.
I started my own company but over the past five years, I would consistently see three former co-workers from that same company. I told them I was thinking of selling out and--jokingly--said I would re-apply for my old job. The response was always positive. "You should!", they'd say, "Put me down as a reference!".
Last October, I sold out. Last January, I ran into one of those co-workers. He's now a project manager. The other two co-workers were actually my bosses, one of whom is now a "Fellow". "There's an opening," he said, "Come apply at put me down as a reference."
So I did. Never heard anything back. I called my friend who talked to the "Fellow". That guy gave me the email of the headhunter who was now in charge of all hiring and told me to mention all three of their names. The headhunter replied and told me the job was, essentially, working on the same product I designed and would I be interested in working on a new version of that.
So I sent my resume which shows that I've been working on almost the exact same thing and that I had worked for that company for seven years on that exact same product and have three high level managers and former bosses who all encouraged me to apply for that job.
Never heard from him.
My former boss, who was the Director of Engineering and is now a "Fellow" is actually now retired and only works there part-time. He said he has no say into how they do things now and all hiring is done through the headhunter. The project manager is in a different department now so they don't care what he thinks. The other engineering manager also retired and, apparently, no one cares about his thoughts either.
Good luck proving it, though.
Namely that how canidates advertise and actual talent and abilities may not align fully. It doesn't make sense to emphasize their bests if nobody is interested or it is taken for granted. Besides they have to try to play to more than you and filtering on arbitraries is how you miss talent, boost expenses and increase delay.
https://daedtech.com/programmer-skill-fetish-contextualized/
Even working on the core team at some of the world's most prestigious software companies, most of the work I've seen has been completely doable by any competent programmers who can communicate with their teams and organize their own time. I've only run across maybe a single bug per 3-4 years that actually required a superb coding prodigy to fix.
Interview coding tests select for gladiators when these companies actually need legionnaires
I get it that you don't expect me to be honest and I can use words entrenched in so much honey that even your mother will get diabetes.
Executive management needs to understand WHY fundamental/generalist skills are more valuable than specialized skills (or at least are of comparable value except in rare cases). And the "why" that most executives understand is "because it results in more profit long term".
Few executives or hiring managers are technically experienced enough to really know what skills are required to do a certain job. Since they know they don't know, they make effort to be very specific and target the technologies (and frameworks) that the person they are replacing was known to be using. If it's a new position, they have selected a popular stack based on what other people in their industry are using. In the mind of the manager, it makes practical sense to aim for exactly what they believe they need.
Successfully delivering this message to the right audience would require a great and charismatic communicator. Unless this leader is already famous, I don't see the advice having a lasting impact. Heck, even if... I still don't expect lasting impact. Companies have been getting by ok (measured by executive compensation and shareholder value) so far, so putting in the extra effort and risk for possibly a better long term result isn't likely to happen.
There is a bright side to this situation: some very talented people who don't fit the current hiring process may go off and do something on their own (or with others like them), resulting in great new things. In fact, that's usually how innovation happens.