You "source" parts for a machine or boxes of cereal for a store. "Sourcing" people communicates perfectly how you think of them: interchangeable resources.
Matching people based on "tech stacks" rather than building a team that multiplies individual talents describes poor hiring priorities. Ideally hiring focuses on adding business value and finding people aligned with the product or service goals, not on languages and tools. Smart and gets things done, as Joel Spolsky aptly put it. Not "has React on resume." Try using an AI. Good luck.
This is how the recruiting profession functions. Sourcing is first step of the recruiting process, whether or not you personally don't like the term.
I should clarify that I'm referring to startup recruiting (which is why I posted on HN).
Most startups do not have the time or resources to train engineers who aren't skilled in their primary technologies. Sourcing for stack-match is the most efficient way to hire engineers who can dive into the codebase ASAP.
You’re arguing with someone who has 40+ years in the software business, including hiring and building teams. And 15 years freelancing, so I know about diving into code with no training.
The process implied by the post may represent the most efficient way to fill chairs. It does not, in my experience, describe an effective way to build a team or a product. Putting the focus entirely on “tech stacks” backgrounds the actual goal of adding value to the business. Competent programmers can learn new tools quickly, I have never observed that as a blocker.
Programmers complain constantly about job postings that focus exclusively on very specific technologies, as if knowing Postgres excludes them from learning MySQL in a week, or having used Python means they will need years to get up to speed with Ruby. I agree. Cast a wider net selecting for competence and experience and curiosity rather than a shopping list of mostly ephemeral languages and tools.
The extremely high failure rate of startups, and dissatisfaction with hiring and retention practices, should give hiring managers and recruiters pause. No one you might want to hire likes the tech stack focus, and it doesn’t seem to work very often.
You're arguing against the system, not me. And I completely understand where you're coming from.
Nevertheless, it is what it is.
I simply created this post to hear from Hiring Managers that recruit engineers using this method, not to make a statement on/defend company hiring practices.
It is what we make it. I know matching keywords and "stacks" has turned into the norm but we don't have to perpetuate it. A hiring manager or recruiter who uses a better approach will attract more programmers, and better quality programmers. Many senior people I know won't even respond to buzzword-heavy job postings, nor will they tolerate stupid interviews copied from what Google did a decade ago.
Not blaming you for "the system," just suggesting you prod your clients to try something more effective.
Exactly. And more fundamentally, tech "stacks" don't make or break a team or project. Projects fail and teams disintegrate because of poor management, incoherent direction and specifications, lack of domain expertise, inexperienced developers, etc. Mostly people problems, as Brooks documented in The Mythical Man-Month decades ago.
The single-minded focus on specific languages, tools, frameworks, and buzzwords plagues the tech industry, and the tech hiring process. Right here on HN people bring this problem up all the time -- the disconnect between what talented programmers can do regardless of the languages and tools and what hiring managers and their recruiters select for. If I want to develop an application for the trucking industry, for example, I want people with logistics domain expertise who can also pick up this or that programming tool fairly fast.
One of the easiest things a recruiter or hiring manager can do during an interview is show the candidate some sample code (if they have that -- if not why have they already picked their stack?) and go through it to see if the candidate can at least read and understand the code and ask relevant questions. I would put much more value on that compared to quizzing someone to see if they've memorized algorithms or esoteric details of some framework.
I would often put out feelers on upwork, asking for a 1 hour project in the expertise area. Interview 100 people, hire (for the hour) 10, make offers to the top 1 or 2.
11 comments
[ 4.9 ms ] story [ 44.4 ms ] threadMatching people based on "tech stacks" rather than building a team that multiplies individual talents describes poor hiring priorities. Ideally hiring focuses on adding business value and finding people aligned with the product or service goals, not on languages and tools. Smart and gets things done, as Joel Spolsky aptly put it. Not "has React on resume." Try using an AI. Good luck.
This is how the recruiting profession functions. Sourcing is first step of the recruiting process, whether or not you personally don't like the term.
I should clarify that I'm referring to startup recruiting (which is why I posted on HN).
Most startups do not have the time or resources to train engineers who aren't skilled in their primary technologies. Sourcing for stack-match is the most efficient way to hire engineers who can dive into the codebase ASAP.
The process implied by the post may represent the most efficient way to fill chairs. It does not, in my experience, describe an effective way to build a team or a product. Putting the focus entirely on “tech stacks” backgrounds the actual goal of adding value to the business. Competent programmers can learn new tools quickly, I have never observed that as a blocker.
Programmers complain constantly about job postings that focus exclusively on very specific technologies, as if knowing Postgres excludes them from learning MySQL in a week, or having used Python means they will need years to get up to speed with Ruby. I agree. Cast a wider net selecting for competence and experience and curiosity rather than a shopping list of mostly ephemeral languages and tools.
The extremely high failure rate of startups, and dissatisfaction with hiring and retention practices, should give hiring managers and recruiters pause. No one you might want to hire likes the tech stack focus, and it doesn’t seem to work very often.
Nevertheless, it is what it is.
I simply created this post to hear from Hiring Managers that recruit engineers using this method, not to make a statement on/defend company hiring practices.
Not blaming you for "the system," just suggesting you prod your clients to try something more effective.
The single-minded focus on specific languages, tools, frameworks, and buzzwords plagues the tech industry, and the tech hiring process. Right here on HN people bring this problem up all the time -- the disconnect between what talented programmers can do regardless of the languages and tools and what hiring managers and their recruiters select for. If I want to develop an application for the trucking industry, for example, I want people with logistics domain expertise who can also pick up this or that programming tool fairly fast.
One of the easiest things a recruiter or hiring manager can do during an interview is show the candidate some sample code (if they have that -- if not why have they already picked their stack?) and go through it to see if the candidate can at least read and understand the code and ask relevant questions. I would put much more value on that compared to quizzing someone to see if they've memorized algorithms or esoteric details of some framework.
Here is a good read:
https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...