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.
7 thoughts on “How Do You Hire Programmers?”
I’m always flummoxed when interviewers don’t ask the interviewee to write a bit of code. One of my favourite questions to ask a potential new hire is to get them to write a reverse string method. They get to choose the language and there is no time limit. It is a relatively simple test but it separates real programmers from the fakers.
Other than that I’m looking for people who are smart and have a track record of getting things completed. I’m never too concerned about a specific lack of knowledge in a language as that is a skill that can be learned.
The only issue with asking for code is ensuring that you don’t get caught up with language syntax too much. I like whiteboard coding as it gives the interviewee a chance to change things and you see the thought process in action.
I am a firm believer in the idea that anyone can be taught this stuff. Learning it is easy, becoming good at it is much harder.
Agreed. I don’t care if they forget a semi-colon at the end of a line. In fact I don’t care if they want to use pseudo code or invent their own language on the spot. The core thing I’m testing for is familiarity with programming concepts.
I’m the other way. I find it insulting when asked in an interview to write some code. It’s appropriate for a junior or perhaps intermediate, but if you don’t believe the twenty years experience I listed on my resume, then why waste my time? In those horrible cases where they’ve decided to give me a “test” I generally leave without filling in any of the questions.
Also for an interview I set myself into “talking mode”, so I’m really not too keen on switching back to “coding mode”. Most often, if they end up hiring me, they still have three months to fire me if it turns out I’ve overstated my qualifications (which I’m very careful not too). I’ll happily write code on the first day of work, but not in the interview.
When hiring other people I’ve often found that a happy personality and a desire to work outperforms initial technical skills. I can always find a place for someone who wants to be there, even if they aren’t the greatest, but a super-programmer with ‘tude can quickly become a disruptive royal pain.
I understand where you are coming from, but there are plenty of people with more than 10 years experience that still struggle with some of the simple coding problems. The personality thing is something that I tried to ignore as much as possible in this post. You have to build a team that will work together well. As you said, a super-programmer with an attitude can make an entire team unproductive.
For programmers with less than five I can understand, but you figure that they’d give up after 10 years of struggling 🙂
At least in my experience, here in the great white north, you can get a real sense of someone’s accomplishments by looking at the jobs in their resume. If they’ve been struggling for ten years, it shows in the companies they’ve worked for, their job lengths, and their bullet items. If they haven’t managed to sit tight and work on some pretty big projects over a ten year career, I’m pretty sure I’m not interested. If I want risk, I’ll take a junior 🙂
If they’ve been at one job for ten years, but only have a couple of bullet points (and that company is a known bureaucracy) I’m probably not going to be interested either.
If their resume is tilted to one degree or the other, and the cover letter doesn’t do a decent job of ‘massaging’ this, then they usually don’t even get past screening.
[…] is that interviewees may think they are harder than they really are. Just a few months ago, I wrote about hiring programmers and one statement is very relevant to this discussion, “Most people tend to get very nervous […]
Comments are closed.