How to Hire a Programmer

Without going into how much I agree or disagree with whats been said, this article is making the bold assumption that a company gets flooded with applicants for a programming position, ranging from useless to awesome. This is so far from reality that I find it obsolete to form an opinion on the validity of the further arguments.

It’s like writing about how guys can weed out all the chicks offers in a club and pick the best one. How’s the weather on the planet you’re on?

While I agree with the need to test coding skills with all due respect I think a lot oof the ideas presented here are archaic at best. I think the more real world interaction you can get with the person the better.

Give them a quick project to work on a couple of nights before the interview and then do a ccode review. The process you describe above takes hours of time from the Candidate and the staff. You can do a code review in an hour and know more about the Candidate than you do by the above.

And a project? I would question anyone who would or would even ask someone to work for free and any senior level developer would laugh.

I went over this in some detail at this post. http://www.lonestarprod.com/?p=22

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.

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.

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.

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”.

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.

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

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

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

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

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

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.

1 Like

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.

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.

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.

1 Like

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!

1 Like

I strongly agree to your first point of testing the skills of candidates at an initial level. Gone are those days when employers used to hire candidates depending on their theoretical knowledge and one’s gut feelings. There should be a metric to validate the candidate’s coding knowledge that he/she has mentioned in the resume. Thus, coding skills tests provided by Interview Mocha, an alternative to Codility, proves to be helpful in validating the same and helps employers to screen only relevant candidates.

The third point regarding finding a cultural fit is also as important as finding a skilled candidate. It’s really important to check whether the candidate you are hiring can thrive in your organization’s environment.

These are decent tips for candidates with no experience. If you can’t look at my resume and see that I’m qualified, I’m not going to give your company the time of day. I don’t have time for that. I’m not straight out of college. If you give me a fizzbuzz I’m going to chuckle and ghost you. If you ask my to draw a database on the whiteboard (yes, its happened), I’m going to decline and leave the interview. If your requirements for the position are more than 5 years experience, and they have been working the entire time, there’s no reason to believe they aren’t up to snuff. Supply and demand–the developer holds all the cards. If you want to hire the best, you better understand them.

1 Like

If I seek employment, I will send applications to several companies, better to say to all that seem like they might fit. I am not sure that I want to start at a given company yet, and a part of that will be about questions I would ask in person and in place. Especially if I like the working environment and culture.

So, I would write several companies, and want to visit several of them.

Now imagine if every of those gave me a programming task that requires several days. And for which I am not paid. And which you seem you want to use, without us having a contract that gives you any copyright over my code. And for which I would probably need to see your code base, for which I did not sign a waiver of nondisclosure.
Yeah, no.
Maybe if you are THE company I want to work for. Chances are that from my viewpoint, you are merely one entry on a big list of possibilities. Of which the rest won’t ask me for several days of unpaid legally sketchy work.

1 Like