Let me start this by saying that I do not consider myself one of those “10x” programmers. I am also a technology generalist, which means I may know how to use specific technologies but I am not considered a guru in many. However, I have been in the software and services industries for over 15 years and I have had my share of success. Today, my point is not to talk about me, but I wanted to give some background on where my ideas may be coming from.

Yesterday, I read a great post by Jeff Atwood on Coding Horror about The Nonprogramming Programmer. In the post, Jeff laments the fact that he wrote a post back in 2007 about the same problems:

I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later “the vast majority” of so-called programmers who apply for a programming job interview are unable to write the smallest of programs.

Part of this problem is that interviews are hard. Most people tend to get very nervous during an interview which makes even simple programs somewhat difficult to write. Obviously, this means we need to take this into consideration when we are trying to make a hiring decision. So, assuming we upgrade the interviewer’s skill based on the fact that there were interview jitters, how do we appropriately rate skills? Do we rate based on how well they know a specific technology, like Java? In my past experience, this is what most companies do because they want to hire people that can be immediately productive in some way. However, does this really lead us to build great teams? Jeff makes a very appropriate comment regarding the industry’s hiring practices as well:

Three years later, I’m still wondering: why do people who can’t write a simple program even entertain the idea they can get jobs as working programmers? Clearly, some of them must be succeeding. Which means our industry-wide interviewing standards for programmers are woefully inadequate, and that’s a disgrace. It’s degrading to every working programmer.

Part of this problem is that most companies are driven by needs. If they really need a new employee to help them finish (or even start) a project, their hiring standards will likely go down. Obviously, this desperation is bad, leads to bad hires and can cause bigger problems within your teams.

How do we fix this? You need to find a system for rating your interviewees. One problem is that interviewing is a very subjective exercise. One person may see a lack of knowledge, while another may see someone lacking experience but full of potential. This is potentially a problem of differing expectations, but you can set a level of expectations after the interview as well. So, what kind of rating system am I thinking of? There are a few things you can do to make this interviewing problem simpler.

Set Position Expectations

If you are interviewing a software engineer, you probably have a title associated with the position, like senior software engineer. In order to really rate the prospect, you need to know what you expect from someone in that position. Even basic roles and responsibilities help in this regard. If you can not point to recommended years of experience, and daily tasks people will be doing, how do you know if someone fits the role you are hiring for?

Determine Why You Are Hiring

You have an open position that you are hiring for, and now you know what type of role this is. The question you have to answer next is why are you hiring this position? Are you trying to fill a particular role on a team? Or are you trying to build a team to create a new product? These are considerably different positions that may have the same title of software engineer. If you are hiring for a specific project, you may want to look for experience with specific languages and technologies. You would also need to answer the question of what this person will do when the project is completed. Will they continue to maintain the software or do they need a new role?

If you are building a team, specific experience is not as much of a concern. You really want people that are intelligent, can quickly learn new technologies and fit the culture of your team. This is where those weird puzzle questions and general programming theory can come in handy. You really want to see how a person thinks about problems and how they handle the stress of the interview.

Can They Work On Your Team?

The last major requirement in the interview process is where your opinions really matter. In many organizations that are larger than 200 people, you may be interviewing someone that will probably work for a different team. I have seen standards lowered in these cases because people think the requirements in other teams are lower than theirs. In these cases, you really need to be honest and ask yourself whether you would want this person on your team. If not, then why hire them for another group? If you do hire a questionable prospect, what happens when that person is transferred to your team after 6 months? If you are interviewing someone it is because there is a chance that you will have to work with them at some point.

This is not much of a framework for interviewing candidates, but I have seen many people go into interviews with much less thought. Employees are a major asset of every organization, so you should treat interviewing as critical a task as you treat development, QA or production support. You should treat interviewing like everything else, like your job depends on it, because some day your job may depend on that interviewee working on your project.

http://static.zemanta.com/readside/loader.js