What I find funny is how little time and effort is put in writing the job description. The interview process is mostly very generic and the questions hardly in alignment to the role. As a profession we try hard to be correct about creating clear specs that can be translated to unambiguous steps for a machine to execute, but when it comes to hiring - we write ambiguous specs, toss it over to recruiters who are poorly…
And as somebody with a past in technical recruiting, I really like your thinking. Indeed you're right: many recruiters are poorly equipped to actually understand the roles. We have non-coders as the first or second tier gatekeepers for development roles, which does not seem ideal.
Sometimes I'd get different signals from the job descriptions than the senior recruiters or hiring managers, which was frustrating. Other times, the requirements in descriptions were way too broad: like the team had an idea of what they wanted, but couldn't get it down on paper in a concise way.
Resumes can be a challenge, too: many engineers don't always give full details of their work. Perhaps because they're tired of getting recruiters reaching out for irrelevant roles (that happen to have a keyword match somewhere). Perhaps they don't have the time to always be updating and polishing.
A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier.
And then, of course - build the interview process around the shared skills / technologies / etc.
Hopefully I'll have something to share here soon, or perhaps do an ask HN to chat more about making hiring developers easier for everyone