What's your approach to sourcing Engineers?
Specifically, hiring managers at startups. I presume you begin by targeting other startups with tech stacks matching up with yours?
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.
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_...