a companion discussion area for blog.codinghorror.com

How to Hire a Programmer


#82

I believe the dichotomy between Jeff’s post and the various comments/blogs is partly reconciled by keeping in mind two things.

  1. Job candidates break down into:
    a. People for whom programming is just a job.
    b. People for whom programming is a career.
    c. Contractors.
    A career programmer will have a portfolio, will play with open source projects, will study programming in their off hours and constantly improve themselves. A job programmer codes during core hours and that’s it. A contractor might be either.

  2. As the hiring party, keep in mind what kind of programmer you need. E.g. if you are an enterprise, a hardware company, a services company, or a manager that thinks programmers are interchangeable, then don’t follow Jeff’s suggestions. You are looking for a job programmer, not a career programmer. Following Jeff’s ideas will annoy your candidates, the interviewing staffers, and HR.

If you are a hiring for a company that writes software for a living (the product is the software), and/or an entrepreneur company, than the suggestions here work: you are looking for a life partner, not a jobber. The interviewer(s) will be working closely with the interviewee for a long time and must have a high confidence level that there is a fit.

For contractors, no matter what your company, the suggestions are overkill. You want someone that a. Can do the job; b. Is not an asshole. You need to pass/fail a contractor with a single interview and get them on board ASAP. They’d better be gone in 6 months, this isn’t a lifetime commitment.


#87

Great post! I like the idea of an audition project, but have some concerns. Many companies have substantial code libraries and frameworks. If the goal is to produce code that you would want to see integrated and used in your production environment, then that code will probably need to use your code libraries, frameworks, and databases. So, the first problem is providing access to that code base and sample data. Are you really prepared to do that for a potential new hire without actually hiring them? Think about all the issues involved there - legal, potential competitor stealing / copying functionality, obtaining the code, providing a test environment, providing enough good data to test on, etc… It could take a few days to a week just to set up the environment - depending on the company. The second problem is that getting up to speed on some projects is much, much tougher than others. C++ programming jobs in general take a longer time to come up to speed on than say Java or C#. I had a tough time coming up to speed in one of my C++ jobs in the past. Fortunately, the managers knew it was a difficult environment to learn so they did not expect very much from any of their developers for the first month or 2.

I thought Roloc (who I have never met by the way) made a good comment and from his blog post:

http://www.lonestarprod.com/?p=22

"1. A night or two before the interview give the person a problem. Something like, parse this file of words and print out on the screen the count of all the words that start with each letter, and end with each letter. Now it doesn’t have to be this specific problem, that is just one I came up with as I was typing it. Realistically, pick a problem that your company has recently had to solve, and won’t take hours to complete. Something simple yet forces them to cover the concepts that are important to you. For instance the above example is obviously going to need some loops and show file reading, inspection of strings etc etc.

  1. Ask the person to bring the solution to the interview on a thumb drive or email it to you earlier.

  2. Sit down with a projector or just around a monitor and do a code review! Let them describe what in detail the code is doing and why they chose to solve it that way. Ask them clarifying questions just like you would if you were helping out a peer."

I would add if algorithms are important, then ask the candidate to find all the possible combinations that 8 queens can be placed on a chessboard without attacking any other queen. Mix it up for different candidates. Change it to 8 rooks, 8 nights, or a mixture of pieces that don’t attach each other.

I would also add a debugging problem or 2 as well as a few simple object oriented programming tasks that shows the candidate understands how to take a non-oo solution and turn it into a well designed oo solution. Whatever tests you come up with, also give them to your best developers to see how long it takes them. Don’t be surprised if it takes most candidates anywhere from 3 to 5 times longer. But, I would not be discoraged by how long it takes them, especially if they completed most tasks and they were for the most part correct. Speed comes with experience.

During the interview, I also would not ask the developer to write any code on a whiteboard or a piece of paper. Again, Roloc’s blog explains the reasons for this quite well.


#89

When a company is so proud of itself that it can’t settle for less then 5 recruiters and 200 resumes (supposedly), I wish there was time for them to follow this recipe… My own experience: 1. The majority of companies ask for links but never checks portfolios and blogs of a candidate (I have a little software bird to tell me). 2. Every step except the f2f interview is replaced by a few phone screens, 40-60 minutes each, by people comparing answers with cheat sheets. It really puzzles me why it should be more then 1 of those and why it should be done over the phone, not in writing. 3. Asking for a test project is likely to result in an HR/manager permanent disappearance. 4. If a candidate brings a demo project to an interview (a short pitch) they are told there is no time to look.


#94

Some good info here, but be careful asking questions like this:

Bits and bytes. “Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?”

Cultural and locale differences may leave the candidate totally confused and you thinking they are worse than they really are just because they didn’t get your “geek joke”.


#100

Ask to see their portfolio? That’s now even possible when someone is working on proprietary applications such as internal payroll systems etc. What if you are developing Middleware and backend systems? All of those are proprietary and companies have strict rules about what can be shared on social networking sites.

As for an audition project, our employee guidelines quit clearly state that working for another company at the same time is subject to disciplinary actions even possible termination.

Finally, if you think I’m leaving a PERM job for a 6-8 week contract to hire opportunity you can forget about it. Typically, corporations do 6 month contract to PERM opportunities. It can take 3 months just to become productive unless you are just cranking out emails or making DB changes.


#103

Very interesting topic!

I have met different approaches in hiring process. However, sometimes it’s just waste of time! From my perspective it’s also very important to have a preliminary phone conversation to avoid wasting of time for both: programmer and employer.

Here is another view of the topic : http://www.myfirstwebapplication.com/post/16/how-to-interview-a-programmer


#104

What I’ve found is that in addition to theoretical questions, as little as 2-3 hands-on excersises can help to get much clearer picture of the candidate’s experience.

I’ve even developed an online tool to automate some basic PHP, JS, MySQL skill tests: http://codeskill.net


#106

i agreed with@Roloc but if you have seen in the programmer side then he/she also have some great views about to select the company ,
they looks the criteria for choosing any a company so here are mention only the process of hire the programmer .

anyway great post


#110

As an alternative for Codility and Interview Zen in the Step 1, please try our service for testing programmers online:
https://tests4geeks.com/

Of course it cannot replace the live interview, but could be a good filter if you have many candidates.

Please excuse me for this advertisement. In my defense, here is a promo code. First 20 registrants will receive 5 online tests for free:
https://tests4geeks.com/account/register?promo=ch60s


#112

Here I am nearly three years later replying to your post. While I do not disagree with everything you say here, I must protest against the huge barrier to entry you propose. As you said, hiring is hard. I have posted a new blog entry highlighting that fact. http://amish-programmer.blogspot.ca/2015/01/national-programming-league-draft-2015.html


#113

The author is 100% correct, and even those steps do not guarantee success. The software company I run (http://www.myprogrammer.com) is constantly looking for programmers, and we spend a tremendous amount of our time on interviewing, testing and trying programmers.

The first thing to understand is that you cannot have a bad programmer on your project. The mess they can create on 1 month will take 6 months to fix. The second thing to understand is that you need someone who is a great programmer involved heavily in the entire process. Here’s how we do it.

Round One: Interview 100 programmers

We find that we are lucky if 15 to 20 can pass the first verbal round. People have great resumes, but they never learned how to write really good code.

Round Two: Give 15 to 20 a real-world test

You need to give them something they can complete in about an hour. This is done while on the call, so we know they are the ones doing it. The problem is simple. The key is seeing if they understood the problem, asked questions, etc., and what solution they created to solve it. And, what does their code look like?

This process results in 1 or 2 good candidates. Now the fun begins.

Start them part-time, with lots of supervision

We put them on a low-risk project under tight supervision with one of our team leads. Do they show up? Do they get along with other members of the team? Do they take ownership of the tasks they are given? Is the code still good?

The good ones come on full-time

The key to this strategy is knowing who you have as fast as possible. The 1 in 100 who make it through are valuable. We pay them WELL above the industry average ($40,000+ to start, with paid vacation and holidays). What we are left with a great programmers who get work done properly, leading to more projects.

The alternative is just not acceptable. We’ve seen it too many times.


#117

Thank you for the article!
Our company uses skilleo to hire developers and it brought us really good people to work with.
After we assess their coding skills via the coding challenge platform we invite the best participants over to see if they fit in our work environment. No further work needed and great outcomes.
You might check the platform skilleo.me as it works similar to codility but is extremely easy to use.


#121

The ideas you shared are right. But I prefer the services having good reputations for respective services like Optimizepress Service or any others what I need.


#122

I have hired quite a few people many years ago in a previous job where there were a variety of different types of programming tasks to do, and two things stand out in my memory from that:

  1. They were all keen good programmers. Didn’t need anything like a “fizzbuzz” test, although I did actually give them one (create a simple menu interface, AFAICR)
  2. Having the luxury of fitting several people to several jobs was great… but I don’t think there is an exact algorithm to choose people in such situations… there has to be some “gut reaction” to the people, their skills, and estimate of how they will fit in with the rest of the team as it is being built.

Today, I’d have to put more effort into weeding out people that cannot program first, but I suspect the shocking statistics for how many fail simple fizz-buzz programming tests might have something to do with “nerves” and the interview situation. I also suspect teaching methods encourage complicated solutions to simple problems… sometimes the rules create good habits, but it all goes against being comfortable with small programming jobs.

My favourite test is to supply a program that has some faults… some obvious and some tricky, and get them to desk-check it as a first step, and only sit down at a computer to finish the debugging if they recognise at least the obvious logical bugs.


#124

I am a senior applications architect that has worked for several major corporations in lead roles. First of all, the projects I designed and developed won’t go into a portfolio. You use them every time you go to the airport or ride an Amtrak train etc…

I hate being subjected to tests and find it insulting. I have worked hard for the knowledge I’ve obtained and even have multiple patents to show for it. I don’t need to prove my skill set to anyone, especially someone that most likely has nowhere near the capabilities I do.

Employers need to respect programmers because exceptional programmers are hard to find. I’ve walked out on interviews in the past when faced with a barrage of technical questions from a panel. I don’t mind taking a test as long as it’s online and I’m not bombarded in an interview with a bunch of crap technical questions that some dude thinks up on the spot.

The interview process should be about seeing if you are a good fit for each other, nothing more. Oh, and respect my time because it’s just as valuable as yours hiring manager!


#127

Informative article.
In the digital age, fast moving organizations can no longer afford to hire employees just as per their resumes and the recruiters’ gut instincts. That’s why use of assessments in pre-hiring has become very popular, not just for IQ skills, but for coding skills as well. The goal here is to use an assessment which lets you dig deep into a candidate’s skills in ways that can’t be achieved through group discussions and long interviews, without bias.
In coding simulator based assessments, candidates are asked to write a code from scratch, and then the code is evaluated on various parameters.