Learning (even more) from Dan Ashby about interviewing testers
Today Dan Ashby hosted a webinar masterclass on his process for interviewing testers. I've been a big fan of Dan's thoughts on the subject ever since he put out this gorgeous mindmap last summer.
I don't think I've gone into a phone screen or an interview since then where I haven't reviewed this. I'm actually a terrible environmentalist for how many copies I've printed out over time. Dan went over his philosophy for each of the areas above and had time for a lot of great questions as well.
So what did I learn hearing about this from Dan himself?
- Interviews are about the conversations that happen between two people, not about checking off boxes on a checklist. Be in the moment, go with the flow.
- When probing on testing knowledge, don't just focus on what they know, focus on what your org actually needs. If a person is a massive Android expert in waterfall environments, how much does that matter if you're hiring for an agile web tester? Understand where the tester is coming from, but also understand how prepared they are for what they are walking in to.
- Also, don't be afraid to ask big picture open ended questions to see where they go. What is testing to you? What is quality? One of my favorites is "who owns quality?"
- It was good to hear Dan walk through the misconceptions block as well. This section is all about deep diving in some areas to see where you might disagree with the interviewee, or in some cases where they are wrong. These moments aren't interview killers, they are just things to consider. Are these healthy disagreements that could lead to progress? Are the misconceptions things that are easily taught, or is this person going to be a drain on resources to train when they are brought on board?
- When going into Agile experience this is a great chance to probe on specifics. What do you like from an Agile board? What's your take on swimlanes? Walk me through your ideal retrospective. What is the sweet spot for sprint length? What kinds of info do you expect out of a bug report?
- Remaining relevant is a subject I haven't often interviewed on, but am going to start to. This could be anything from asking about books or blogs they've found helpful to hearing about skills they've been developing (development, project management, etc). This can obviously vary depending on what you're looking for in a role, but learning = good.
- If at any time the interview has reached the point where you know are not going to hire the person, consider whether it's worth going into mentor mode. Is this an opportunity to teach? This might not work out well if you are part of a full day interview panel, but if you are a solo interviewer, or are on a phone screen consider your options.