Nov 10, 2013

How-To: Test-drive Software Developer's Skills BEFORE Hiring the Candidate

The Problem...

In a previous post, we listed out some thoughts and considerations about hiring the ideal candidate for a job opening at your IT shop.  In there I made my lame attempt to coin a phrase: Hypothetical Scenario Modeling or HSM for short.  While it is probably a very long shot for this to become a "coin-able" phrase, with this post, I'll attempt to describe how to use the HSM approach.

Let me tell you a short story of how this approach evolved. Our IT shop had a new opening for a developer and I was asked to conduct the interviews. So my in-box got filled with resumes from many individuals. I needed to narrow down the list to start the interviewing process. We reduced the original list down to 3 candidates and conducted the conversations with them. They all seemed very nice people and seemed knowledgeable on the topic. They also were very eloquent and gave us the impression that they could be a good fit within our shop. So we made our decision and and finally narrowed down to 1 person. It was hard to do! After all, they were all knowledgeable and sounded like they knew their "stuff." Right?

After a few weeks, which turned into months, we realized that the candidate we picked was not the right choice. The person struggled to follow our ERD models. They claimed they knew UML. They had no clue what a UML was. Clearly, we should have chosen a different candidate, but which of them was the right choice?  We wished we could peek inside the brain of the person and really test drive their skills. How could we do that in a 60 minute interview?

 A proposed solution...

Come up with a made up scenario, a short story if you will, that can be analyzed in a short span of time and a quick design could be derived from it. It does not have to be THE perfect design. Just something that can allow you an objective picture of what it would be like to work with this candidate and a peek at whether or not the candidate has the skills or techniques listed in the resume they gave you. The way to use this aproach goes something like this:

Prior to the interview

  • You, and whoever else will participate in the interview, should read the short story
  • Come up with your own representation of the model - how you would design a system to support the situation described in the short story
    • ERD or
    • UML Conceptual Model
  • Come up with some assumptions you are making about the situation
  • This exercise works best when you and at least one (at most 2) of your colleagues participate in the interview with the candidate.

During the interview

  • Ask the candidate if they would play along a small exercise. Explain to them that you have a short story that you were hoping they would read and then participate in mock-design session
  • If they say "no", then you have some part of the answer on whether or not you would want to hire this person. You also have the choice to continue with the interview at that point.
  • Assuming the candidate engages in the discussion
    • Allow some time for them to read and become familiar with the scenario described in the story. Allocate between 15-20 minutes for this part. The story has to be short enough to allow ample time for the candidate to read it and think about it for a few minutes
    • Have the candidate sketch their proposed design on the whiteboard or a piece of paper
    • Ask them to come up with a design (expressed as an ERD or a Conceptual Model) that could support the scenario the story describes
    • Listen to them as they walk you through it
    • Do not argue about a better way to do something. Remember the goal here is to see how they think and how well the can apply the concepts / techniques they listed on their resume
    • Ask questions if you need to clarify something the candidate said (remember no arguing)
    • Take notes about things you liked / disliked 
    • Ask the candidate what assumptions they made as they thought about the design they came up with. If they bring up the assumptions they made before you ask (or even better if they start their discussion with the assumptions) award big bonus points for it! 

After the interview

  • Huddle up with your colleagues and discuss what you thought about the candidate:
    • Do you see yourself working with this person
    • Compare your interpretation of the design with the candidate's. Award points for the interesting differences between their interpretation and yours. Avoid awarding points for the similarities. You do not want 2 of you at your IT shop. You want diversity of perspectives
    • Compare the design that the different candidates came up with
    • Look for elegance and simplicity

There you have it: a way to test-drive the skills of a software developer candidate who is applying for a development position at your IT shop.

May the best candidate win!

For ideas of modeling scenarios that you can use during your interviews, please, consider the ones listed below:
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)