How to Hire a Programmer

blog
64

Interesting article. As a general matter, I don’t look for programmers - I look for problem solvers.

While much of what I read in this post is good in theory, practically, it is not workable. Too much effort on the part of the interviewer.

You want to learn about skills? Post a repo on github with problems. Direct the candidate to that. There will be a readme. The code should have problems as to not working and not compiling. Instruct them to fork, fix, and submit a patch. Did they write tests? Did they make one big checkin or several? You can also add hypothetical use cases and problems for them to answer. Writing is a key skill in this industry. Do they just answer in tech terms? Or, do they mix in business analysis.

Through this process, which takes no time on the part of the interviewer - except to review the submission - you can learn a lot. The candidate may be a senior developer - but through this process - you will have a gauge of what kind of senior dev he/she is.

John
codebetter.com/johnpetersen
@johnvpetersen

65

Hi,

What you say is very interesting. I’m a passionate software engineer but I have a problem. I stutter a little when talking to people and I have fear to not pass my future interviews due to this problem and because I think I have some kind of social anxiety disorder… What can you say to me? Thanks.

66

These methods only fit if you’re a google level company. i.e. you can
1.) Afford the risk of filtering out a good candidate (which is bound to happen with the way you interview)
2.) Afford the high paycheck that anyone who passes this gauntlet deserves.

If you’re not, then please burn in hell. I always hated small-time startups taking more time to hire than it would to actually develop their project.

67

Ask the candidate to provide code samples of their work… work that they are proud of.

I’ve never understood this. I’ve been asked for code samples a couple of times in the last twenty years of developer interviews, and I just don’t get it.

I work for companies, producing software that they own. So I have no rights to that software and would be violating my contract if I was to show it to anyone outside the company. Not only that, but in any company with a long-lived code base it will modified and rewritten by numerous other developers, so finding a self-contained piece of code that I wrote by myself would be difficult, to say the least.

I can pull some code from the open source projects I’ve worked on, but that’s hardly representative of what I’d be writing in a professional job with budgets and deadlines. So unless you want to hire people who’ll walk out the door with code you’ve paid them to write, you’re basically asking me to sit down and write some dummy code which will never be used for anything other than a talking point in an interview. I don’t get it.

68

@Clarence Risher

Then you are doing something wrong with your resume. Ask some help around to see if you have something on your resume that makes HR bin it.

@ThomasB

#1 is not ridiculous at all, as Jeff mentioned. It is trivial and takes no time to solve it, but it proves you have rudimentary coding skills.

If you as a candidate have problems with this test, it would be a red flag for me. But for totally different reason - attitude problem. No task should be “below you” to perform, no matter how trivial. It shows how good a team player you are.

I would never focus attention on CODE, because it is learnable. Problem-solving and designing good solution is critical and scarce.

69

I guess this applies only to the “junior programmers” that sometimes are sent to the customer by large organizations, honestly, if after 31 years and millions of lines of codes written in a dozen different programming languages somebody asks me to write a program to display “hello world”, it means only that I am in the wrong job interview and I should immediately locate the nearest way out.

70

I like to see if the candidate can type. I give them the keyboard and ask them to show me what they’ve done. If they look at the keys, its off to a bad start.

71

Right on Martin. If you can’t touch type, then you can’t code!

We have established gurus teaching our teeks (IT learning units), so we don’t worry too much about an immediate type test, but our business is virtual and international, so a touch test is less important than a portfolio. Great article!

72

This sounds exactly like the interview process for big corporations such as Microsoft.

73

“At some point in the process you might want to think about how to convince that awesome programmer to work for you and not for somebody else.”

This.

The strategy you’re outlining is extremely risk averse (mostly to the benefit of the company), heavyweight, and is going to lose a lot of good people. Maybe all of them. Personally, I would immediately conclude my time was being wasted, there was a cultural mismatch, and I would head elsewhere.

74

I am grateful for the sample phone screen questions, especially number 5. If I’m ever asked that question in a future interview, I’ll have the answer, but only because I read your blog. I haven’t messed with octal values in over 20 years. It’s a fine brain teaser; I might change it to “How is Halloween the same as Christmas”.

I really do enjoy your blog.

75

Hiring for cultural fit is very important - but you can’t really determine cultural fit unless you meet someone face-to-face first.

Phone screening is a good way of ensuring that the person you want to interview isn’t a total monkey, but we’ve found that it doesn’t save much time in the end, as we still have to interview the candidates that pass phone screening anyway, so we might as well just interview anyone who we feel qualifies based on their CV and agent recommendation, as we can kill several more birds that way.

We’ve done a lot of dev recruiting recently, and have streamlined our process to the following, as an example:

  • Candidate is evaluated based on CV and agent recommendation. We try not to be too picky at this stage, depending on how many CVs we get.

  • Candidate has initial face-to-face interview with 2 senior developers (to ask technical questions) and dev manager (to establish initial cultural fit). Any interviewer can veto the candidate at this stage and cut the interview short.

  • If initial interview is successful, a standardised audition project is given. This enables us to compare developers against each other, if need be, whilst still establishing the candidate’s core competency and coding style. The project is tailored to the technical and business environment of the company.

  • If the audition project passes, then we invite the candidate for a final interview, where they will meet a wider range of staff in a more informal setting, including the directors of the company. At this stage the technical evaluation is complete, but staff members can still veto the hire if they find the cultural fit or personality of the candidate to be a real issue. It happens quite frequently, actually - I’ve had several candidates that I felt were technically strong and a good cultural fit get booted out at the last second due to poor performance in the final interview.

For our company, this process has resulted in the least involvement from both parties, as we establish the majority of what we need from the initial review. The audition project is very useful, but I do believe it needs to be standardised, otherwise you can’t see how different developers stack up on the same tasks and sometimes that’s the only way to choose between them! The final interview is really just a sanity check.

Your optimal process will be different of course, but it should be streamlined and consistent, and not waste anyone’s time, if at all possible.

76

I’m going to take a stab in the dark and guess that you’ve never actually done this process that you’re recommending. I don’t know if you caught it while you were writing, but you actually just recommended having people come into your office to do paid work for up to two weeks before you’ve even met them in person. Somebody correct me if I’m completely off-base here, but isn’t that completely absurd?

Not to mention that this method (step 5 specifically), is likely only going to get you two types of applicants: Those that are completely and utterly dedicated to getting hired to your specific company, and people with nothing better to do with their time. I don’t consider myself to be in the very top tier of programmers, yet months before I graduated college I had more job offers than I knew what to do with. Not just “job offers,” but good job offers with reputable companies and competitve salaries. If a company had required me to do several days of work for them before even considering giving me an interview, guess what I would have done? If you guessed “dropped everything (including school, several actual job offers, and my very fulfilling part-time programming work) to work for you for a week or more just to audition for your company,” you are sorely mistaken.

77

Yes Robert, it is absurd. This is the outcome that should happen.

Interviewer: “We see that you have 10 years’ experience as a corporate engineer… We need you to take a week off of your current job and complete this project for us. After that, please come back to our office for a talent show.”

Interviewee: “I’m leaving….”

Interviewer: “Your hired!”

If you want to hire the best, you should be marketing to them. Not making them jump through hoops for you. If I asked even a young develop/engineer to do all of these requests and they walked out of the interview, I would run out into the hall and hire them. They know the true value of what we are working for and creating, not all the fluff.

Better questions would be about application design, modeling, and testing. If your interviewee can carry a conversation then it’s pretty much implied that they can code what you need. If they start talking about CSS when you mention application design, then that’s the only filter that you need.

Its old programmers that forget they were once a 24 year old with no professional experience come up with these crazy interviews. It’s becoming unfair. I don’t think I could solve some of these programming mind games in high pressure interviews.

78

I’m not a fan of #1 and #4. I know how to program, but I’ve been on interviews where I’ve be asked to write code on a white board and I looked like an idiot. Programming is done with a keyboard, with your eyes on a computer screen and seeing what happens with it. Writing code out by hand feels unnatural and I can’t think straight if I’m asked to do it like that.

Same thing with answering random programming questions over the phone. It’s different to be writing code on your own to solve problems you’re working out, than to try to speak about it to someone and answer their gotcha questions out of context.

I’m sure you can find great candidates like this, but I think you’ll also be weeding out great candidates. It seems like you’re trying to find one kind of thinker, but there are people who can get the job done and have a different perspective on things that won’t pass these tests.

80

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?

81

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

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.