Normally when we recruit someone it is because we:

• Have stuff we want them to do.
• Have ideas of the ways we want them to do it.
• Know why we want things done that way.

But we often don't put that in job specifications, because the people doing early CV filtering can't filter on those items, because the people filtering lack the required experience necessary to draw the above out of a CV to identify the people that we might want to work with who can add value in our teams.

I try to interview based on the person, and I will ask questions around the stuff we want them to do:

• How do they interpret what I have said?
• Have they done anything that they think is similar?
• What did they learn from doing that?
• What worked? What didn't?
• How would they do it next time?

There are no right answers, I have to interpret the answers based on my experience. I'm also looking to see what else this person can do, and determine if those experiences or thought processes could help us (perhaps what they offer is more important than the capabilities we were seeking).

A role-based approach will not help you hire people who can add value beyond what you were looking for, or change what you thought you were looking for.

During the questioning, I am building a model of this person and how I think they might fit into the team and do the tasks we want to get done. I ask questions to build this model. I want them to ask questions of me to question my model of the work and envisioned required capabilities.

I also have them engage in an audition, where I pair with them to:

• Do they type of stuff we want them to do, e.g.
  • Maintain code that automates the application.
  • Review code to figure out how it could be better.
  • Test the system.
  • Review the system to see what risks they identify.
  • Explain the system and engage in an iterative Q&A session so they can build a model of the system and explain how they might test it.

Rather than questions, I have samples of work and systems and I work with them or question them to see how they deal with the work and systems.

I might have a list of questions to prompt me during the interview to see if my model of the person covers these areas:

• How does this person stay up to date?
• What have they learned from their testing in the past?
• What have they learned from automating in the past?
• Do they have absolute and rigid beliefs or approaches related to the job?

I generally don't ask these as questions to them, rather, these are questions I pose to myself, to allow me to check my model of the person.

Sorry, I take a different approach and have no list to offer you. I don't have any questions, because I adjust the audition around the person based on the job, first by having them explore my model of the job and discussing how their experiences map to the model, and then a hands-on practical audition for aspects of the role.