When I've been in this situation, I wasn't the one making the job description.
In general, I feel the hiring process focuses on the wrong things. Buzzword compliance is a major problem. Experience in problem spaces is much harder to capture in a resume than a list of technologies that can be software-grepped for the benefit of technically clueless recruiters and HR.
Similarly, I'm not a fan of most technical reviews. They tend to focus on gotcha questions and think-on-your-feet trivial programming exercises that have virtually no bearing on real life as an engineer. To be fair, they can help, but they often exclude excellent engineers who aren't as good at the on-your-feet game as they are at the big picture game.
When interviewing candidates, I tend to pick up on an interesting experience on their resume, and ask them to talk about it. What went right? What went wrong? What was your role in the solution?
Heuristic: Candidates who blame others for failures, especially when they don't praise others for success, get a big black mark. I don't usually like working with people who are looking for someone to blame, regardless of their skill.
Heuristic: When someone starts talking about some project and really geeks out about it, getting into the details of how the solution worked and why it delighted them, gets a huge plus. First, it means they were actually at the core and understood what was going on. Second, it says what they care about.
Sometimes, I'll get them talking about their best experiences as an engineer, or their worst, just to hear the geek come out. It's very telling.
And I have usually decided on a candidate in the first five to ten minutes of an interview. If it's no, it's no. If it's yes, the rest of the interview is mostly about validating my initial impression.