Hiring good programmers - Part 2

In Part 1 of my discussion on how to hire programmers, I outlined some problems with common practices in hiring programmers (or anyone else for that matter). But merely pointing out problems isn't useful. What can a manager do to hire good candidates?

I would start by defining the tasks the position requires as honestly, realistically, and specifically as possible. This isn't as easy as it sounds. For example, many openings that I've seen for programmers require someone who can complete code "on time, within budget, and bug-free". Unfortunately many problems that get in the way of delivering software with these criteria are outside of the control of a software developer. Yes, skill deficiencies in the programmers themselves can cause any or all of these issues. But so can poor requirements, poorly controlled scope creep, poor communication, etc. What exactly is the need?

A better approach might be identifying which aspects of the finished product are most important. A programmer trying to be one of the first to create a game for a new mobile system might be more focused on time and budget than bugs. To contrast, programming for medical devices would require much more focus on creating bug-free software. Along with this, be aware of any road blocks within your company preventing programmers from getting work done. Do the programmers frequently get poor requirements? While improving the requirement gathering and documenting process, I would focus on getting programmers with enough of a business sense to be able to extrapolate missing information from the requirements. Are projects frequently under time pressure? Then finding programmers who can get work done quickly should be a priority.

Once the tasks have been defined, I would then break each of the tasks down into Knowledge, Skills, and Abilities (KSA). For the sake of example, I'll start breaking down a few of the tasks and KSAs needed for a completely hypothetical mid-level ASP.NET developer position. This position might be for a mid-sized company looking to add onto a web application designed to track inventory within a supply chain looking to add a developer to a team that can handle simpler tasks to free up some senior developers to work on other projects.

Tasks:

1. Creates reusable, maintainable, reliable components in C#
2. Tracks down bugs with little assistance from more experienced developers
3. Integrates third-party components into web applications

Task 1 could be broken down into the following KSAs:

1. Working knowledge of Object-Oriented Programming concepts
2. Experience creating effective unit tests
3. Makes intelligent decisions as to when a component should be broken down into sub-components

Task 2 could be broken down into the following KSAs:

1. Can read and understand code in C#
2. Can read and understand documentation
3. Can refactor poorly written code into more usable/readable components
4. Can write unit tests to reduce the amount of time testing through the user interface

Task 3 could similarly be broken down into the following KSAs:

1. Can read and understand third-party documentation
2. Can integrate third-party code into a larger application as seamlessly as possible
3. Can anticipate problems with third-party components and comes up with reasonable work-around solutions

A real KSA breakdown would include many more tasks and KSAs, but I hope you get the idea. Now that the needed KSAs have been identified, it is time to identify the important ones. Reading and understanding C# and documentation are common KSAs, as is seeing how small pieces fit into a whole, and writing effective unit tests. Not found in this particular breakdown are the need for keeping up with the latest technologies or understanding large-scale structural issues, so despite the fact that these are common interview questions I wouldn't include them in an interview for this particular position.

With this information, you can design questions for interviews. Since we need to identify people with an understanding of creating reusable, maintainable components, here are some questions that we might ask:

• If you are asked to fix a method that has a return type of an object and returns a due date if the user is valid and 'false' if not, how would you go about doing so?
• If you have some functionality in one of your classes that is needed by another, what is the best way to move that functionality to the new class?
• If you are using a third-party library to send information from several different ASP.NET pages to a third-party store, where do you put the logic?

These questions are all specific and are all targeted to certain tasks I would need the interviewee to perform. I have my ideal answers for each and can evaluate all of the candidates consistently. Also, I make it a point to ask several questions that get to the same point because of the possibility of miscommunication or misinterpretation on either side.

It is also important to evaluate employees by watching them do work that is representative of the job they would be hired for. I have encountered people who can talk about different technologies or approaches fairly well, but when they get to doing the job, they fall short. The reverse is true as well. In designing tests, I would take a similar approach to designing the test as I would designing questions; I would identify important KSAs and create tasks that would require them. Taking this one step further, I also like to break down my tasks into three categories: tasks that every person ought to be able to do, tasks that require skills that are "nice to have", and tasks that I don't expect the candidate to complete. This way I can get a deeper sense of the understanding a candidate has for particular skills. A candidate who can complete some of the tasks in the last category will have an advantage over those who don't.

Finally, you may be wondering about how to determine cultural fit. Unfortunately, cultural fit is tough to pin down and therefore it is difficult to create good questions to get at it. To make it even tougher, many of the questions that could be asked to ascertain cultural fit open the door to discrimination lawsuits. When I figure out a way around this I'll write another blog post.