When you let doggies into your doggie park, there are a couple of things you want to look for. First, you want to weed-out the bad-doggies. You want to make sure that you dont' let in any kitties by mistake. And you want to make sure new doggies are going to get along with the doggies you already have in your doggy-park.
The same is true with teams. When you staff your team, you'll want to make sure that you don't bring in anyone that will cause problems for your existing team. To do this, first and foremost, new members need to be technically competent. Unless your new position is for an intern, you don't want to do on-the-job-training unless that is the specified role for that position on your team.
Once you've weeded out the candidates that aren't technically able to do the job, the leader should do a qualitative interview. A qualitative interview is where you determine whether or not the personality of the individual will fit in well with the team. There are a couple of techniquest used to perform this kind of an interview, and its important to understand what each technique is attempting to do before you choose the technique that fits your personal style.
A scenario driven qualititative interview is one in which the interviewer describes a specific scenario and then asks the interviewee what they would do in that situation and why. A classic example of a scenario is: "You are walking along the street and see a wallet on the ground. You pick up the wallet and see the contact information of the wallet owner and a $100.00 bill. What do you do?"
Now, this example is very simple but it showcases a basic flaw in this technique. Its very easy for the interviewee to guess what the "correct" answer is, and to respond accordingly. And on scenarios where the answer isn't obvious, interviewees tend to become somewhat defensive. So, I'm not really a fan of scenario driven qualitative reviews.
The technique I use is to find out what things the interviewee likes to do in thier free time that enhances thier technical ability. This is based off of the idea that folks who do what they love at work are going to be most productive. If someone is spending thier free time doing something that is very similar to what they do at work, that indicates a true love for thier profession. This is an extension of the "Love" concept described Open Agile.
Most of the interviews I conduct are for folks in the software development field. In that field there are applications you can buy, and then applications you can download for free called "open-source software". Open source software is written by folks in thier free time. So, when I interview folks, in the qualitative portion of the interview, I ask them "What open-source projects do you work with and what do you do?"
To be clear, there are a lot of good reasons for folks not doing stuff in thier free time that enhances their technical capability. For example, a person may have kids, or they may have hobbies that have nothing to do with thier work. Those are all fine. However, if I have two resumes in front of me for a software development position and the resumes both represent a similar amount of technical ability,I"ll do a qualitative interview. In this scenario, lets say one person is involved developing open source software and the other likes rock climbing. No offense meant for rock climbers, but I'm always going to go for the open-source developer. Remember, we want the best possible people in our doggy-park. And things like loving your job so much that you do it in your spare time are what really matter.
How much does it matter? It sometimes is even more important that being fully technically qualified. I had an opening for mid-level developer with experience in the Java programming language. There are a number of languages that are very similar to Java, including C# (pronounced "See sharp"). When I interviewed for that position, I had one candidate with no Java programming experience but they did have C# experience.
However, during the qualitative portions of the interview, it became very clear that this developer had a deep love for software development and was actively pursuing learning opportunities to become a better developer, on his own without his company's support. I also interviewed a couple of folks who were technically qualified, but I didn't see that passion for thier work. So, to make a long story short, I invited the passionate developer into my doggy park and within weeks he was my strongest performer.
In my next blog, I'm going to talk about doggy-traits and kitty-traits, and how to use them to decide who to invite into your doggy park.
The same is true with teams. When you staff your team, you'll want to make sure that you don't bring in anyone that will cause problems for your existing team. To do this, first and foremost, new members need to be technically competent. Unless your new position is for an intern, you don't want to do on-the-job-training unless that is the specified role for that position on your team.
Once you've weeded out the candidates that aren't technically able to do the job, the leader should do a qualitative interview. A qualitative interview is where you determine whether or not the personality of the individual will fit in well with the team. There are a couple of techniquest used to perform this kind of an interview, and its important to understand what each technique is attempting to do before you choose the technique that fits your personal style.
A scenario driven qualititative interview is one in which the interviewer describes a specific scenario and then asks the interviewee what they would do in that situation and why. A classic example of a scenario is: "You are walking along the street and see a wallet on the ground. You pick up the wallet and see the contact information of the wallet owner and a $100.00 bill. What do you do?"
Now, this example is very simple but it showcases a basic flaw in this technique. Its very easy for the interviewee to guess what the "correct" answer is, and to respond accordingly. And on scenarios where the answer isn't obvious, interviewees tend to become somewhat defensive. So, I'm not really a fan of scenario driven qualitative reviews.
The technique I use is to find out what things the interviewee likes to do in thier free time that enhances thier technical ability. This is based off of the idea that folks who do what they love at work are going to be most productive. If someone is spending thier free time doing something that is very similar to what they do at work, that indicates a true love for thier profession. This is an extension of the "Love" concept described Open Agile.
Most of the interviews I conduct are for folks in the software development field. In that field there are applications you can buy, and then applications you can download for free called "open-source software". Open source software is written by folks in thier free time. So, when I interview folks, in the qualitative portion of the interview, I ask them "What open-source projects do you work with and what do you do?"
To be clear, there are a lot of good reasons for folks not doing stuff in thier free time that enhances their technical capability. For example, a person may have kids, or they may have hobbies that have nothing to do with thier work. Those are all fine. However, if I have two resumes in front of me for a software development position and the resumes both represent a similar amount of technical ability,I"ll do a qualitative interview. In this scenario, lets say one person is involved developing open source software and the other likes rock climbing. No offense meant for rock climbers, but I'm always going to go for the open-source developer. Remember, we want the best possible people in our doggy-park. And things like loving your job so much that you do it in your spare time are what really matter.
How much does it matter? It sometimes is even more important that being fully technically qualified. I had an opening for mid-level developer with experience in the Java programming language. There are a number of languages that are very similar to Java, including C# (pronounced "See sharp"). When I interviewed for that position, I had one candidate with no Java programming experience but they did have C# experience.
However, during the qualitative portions of the interview, it became very clear that this developer had a deep love for software development and was actively pursuing learning opportunities to become a better developer, on his own without his company's support. I also interviewed a couple of folks who were technically qualified, but I didn't see that passion for thier work. So, to make a long story short, I invited the passionate developer into my doggy park and within weeks he was my strongest performer.
In my next blog, I'm going to talk about doggy-traits and kitty-traits, and how to use them to decide who to invite into your doggy park.
No comments:
Post a Comment