As an HR/Talent pro if you have been involved in the hiring process for software engineers or developers then it is likely you have run into this scenario when presented a hiring requirement from one of your managers:
Find me someone really proficient in (one from a long list, doesn't really matter which one), Node, Django, jQuery, AngularJS, Redis, Ruby, etc. and I need him/her right away. So you set out to examine your ATS, check LinkedIn, StackOverflow, GitHub, the Starbucks over by your local University - whatever, and you secure the person that is proficient in skill 'X' , just like your hiring manager asked for. 
Sean Scully, Maesta 1983
Everyone is happy, right? The candidate found an opportunity that matches their skills, the hiring manager got someone that knows the specific programming language that they need, and you can move this Req into the 'Closed' folder and see if anyone brought in any extra Halloween candy to the break room.
But there could be a longer term problem with this kind of approach to hiring, it can result in something called 'Resume Driven Development', a condition where the products that get ultimately developed and provided to customers become a reflection not of the requirements of the customers, but of the capabilities/resumes of the developers that work on the project.
What this looks like is pretty thoroughly explained in this piece from the O'Reilly Radar blog:
Resume Driven Development happens when your group needs to hire a developer. It’s very hard to tell a non-technical HR person that you need someone who can make good decisions about software architecture, someone who knows the difference between clean code and messy code, and someone who’s able to look at a code base and see what’s unnecessary and what can be simplified. We frequently can’t do that ourselves. So management says, “oh, we just added Redis to the application, so we’ll need a Redis developer.” That’s great — it’s easy to throw out resumes that don’t say Redis; it’s easy to look for certifications; and sooner or later, you have a Redis developer at a desk. Maybe even a good one.
And what does your Redis developer do? He does Redis, of course. So, you’re bound to have an application with a lot of Redis in it. Whenever he sees a problem that can be solved with Redis, that’s what he’ll do. It’s what you hired him for. You’re happy; he’s happy. Except your application is now being optimized to fit the resumes of the people you hired, not the requirements of your users.
The problem is that your team is optimized around the inability to communicate at a critical stage: the inability of a technical team to specify what they really want (a developer with good programming taste and instincts), and instead hiring someone who has a particular skill or credential. I suspect that Resume Driven Development is quite pervasive: an overly complex application stack that’s defined by the people you hired, and by the current toys that the “cool kids” on the programming block get to play with, not by the requirements of the application.
A pretty good example and reminder that in hiring, as in the rest of life, you get what you pay for, or in this case, what you ask for.
And I think this problem, or this tendency, might only get more likely over time as organizations try and move to more 'just-in-time' talent acquisition strategies that incorporate more and more contingent workers.
It is not an easy problem to solve for sure. The natural or easy tendency is to try and define or simplify the hiring process into simple or discrete definitions. Hire Person 'A' with Skill 'B', to code in Product 'C', that kind of thing.
But there is a definitely some advantages that can be accrued by expanding, at least somewhat, the requirements for both technical and even non-technical roles. The warning though, that Resume Driven Development suggests, is that unless you know exactly what you will need, for at least the foreseeable future, then you are going to get forced into being locked in to a set of people and technologies that you may not want to be locked in with.