I kind of agree with you. I don’t care if a new hire has deep experience in every part of the team’s tech stack. In interviews I look for four things:
1. Do they know the fundamentals of each domain they mention in their job application? How well do they understand and how well can they explain core concepts?
2. Do they have an attitude to learning and teaching that will make it possible for them to pick up the gaps between what they know now and that they need for the job? Will they be able to keep going past that? Will they be able to support co-workers on their journeys?
3. What are the specific gaps between what they know now and what they’d need to know to work in our tech stack? This isn’t to exclude them from the role, more to understand what support they’re going to need and what the ramp up might look like. I try to keep it away from trivia and more general. Eg. “tell me a time you had to debug a problem in go code. What was the initial bug report and how did you get from there to solving the problem? What did you do to make sure it didn’t happen again?” Those open questions can lead to some good conversations and give a good sense of how well a candidate understands an area.
4. By now I’ve made my mind up about whether I’m going to say yes or no. Now I see if I can convince myself the opposite (without being a jerk).
1. Do they know the fundamentals of each domain they mention in their job application? How well do they understand and how well can they explain core concepts?
2. Do they have an attitude to learning and teaching that will make it possible for them to pick up the gaps between what they know now and that they need for the job? Will they be able to keep going past that? Will they be able to support co-workers on their journeys?
3. What are the specific gaps between what they know now and what they’d need to know to work in our tech stack? This isn’t to exclude them from the role, more to understand what support they’re going to need and what the ramp up might look like. I try to keep it away from trivia and more general. Eg. “tell me a time you had to debug a problem in go code. What was the initial bug report and how did you get from there to solving the problem? What did you do to make sure it didn’t happen again?” Those open questions can lead to some good conversations and give a good sense of how well a candidate understands an area.
4. By now I’ve made my mind up about whether I’m going to say yes or no. Now I see if I can convince myself the opposite (without being a jerk).