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 equipped.

Here are some thoughts: - When the new position opens, the team (say the scrum team) collaboratively writes a job description based on the current backlog. Let's not leave it to a manager or recruiter who is writing the job description. Use the company/team's mission and values as guidance to see who an ideal candidate would be. This is like writing your stories.

- Then write the filtering criteria based on the typical day to day skills - what are must haves, what are good to have, what is ok to not have. This is like write your test cases.

- What are the areas where the team is lacking. Try to get skills/qualities that will, for lack of a better expression, raise the bar of the team. This is like your retrospectives - and if you have notes from your recent retrospectives, they should help you identify what you are looking for.

- This better spec should help the recruiters, and also give the candidates an honest look into the team.

- For the interview, go back to your previous sprints etc. and build questions that are simplified models of what a typical story would look like. Instead of asking to invert a tree, may be it would be better to talk about how a particular problem you solved and see the approach the candidate would take. Give the candidate all the tools - their favorite editor/ide or whiteboard, whatever they prefer.