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.