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