Help me hire a full-time programmer.
January 25, 2006 9:17 AM Subscribe
Help me hire a full-time programmer.
Right now I'm the sole developer in what should be a two-person team. It's been a few years since I was involved in the hiring process, and some of the people I hired were great but others just didn't work out. This time I want to get it right.
This is a small company, so we don't have an official HR or recruiting process, and I'm the only one who knows anything about software development. I'm going to be the senior developer responsible for training and guiding whoever we hire.
I'm not looking for advice on how to find candidates, as I'm sure we'll get more than I could interview. I'm looking for tips on how to judge programmers' skill and experience based on resumes and interviews, especially the interviews. Are puzzle-type questions useful? How about whiteboard programming questions? Is there a better way to find out whether someone will be a good match for the company?
Right now I'm the sole developer in what should be a two-person team. It's been a few years since I was involved in the hiring process, and some of the people I hired were great but others just didn't work out. This time I want to get it right.
This is a small company, so we don't have an official HR or recruiting process, and I'm the only one who knows anything about software development. I'm going to be the senior developer responsible for training and guiding whoever we hire.
I'm not looking for advice on how to find candidates, as I'm sure we'll get more than I could interview. I'm looking for tips on how to judge programmers' skill and experience based on resumes and interviews, especially the interviews. Are puzzle-type questions useful? How about whiteboard programming questions? Is there a better way to find out whether someone will be a good match for the company?
Honestly, the best test is seeing what they can do. Get examples of projects they've done, make a judgement. If they don't work out, they don't work out.
I'd be very put off if someone started asking me puzzle questions in a job interview.
posted by zerolives at 9:28 AM on January 25, 2006
I'd be very put off if someone started asking me puzzle questions in a job interview.
posted by zerolives at 9:28 AM on January 25, 2006
Also, making sure their personality meshes with yours is just as important as their software engineering skills. This will help to ensure a long, productive relationship.
posted by blueplasticfish at 9:33 AM on January 25, 2006
posted by blueplasticfish at 9:33 AM on January 25, 2006
I've hired a few programmers over the years, and never gave any interviewees anything more than a cursory tech check. They all worked out very well.
Have them talk through examples of what they did, and prod them about some of the choices they made (platform, code abstraction, etc.) and why they made them. Anyone can memorize the facts needed to pass tests covering hypothetical scenarios, but being able to describe real-world solutions to real-world problems is key. At the opposite end of the spectrum the "Impossible Question" (covered in the Joel On Software article) is another good tactic for testing creative problem-solving skills.
I also agree with blueplasticfish- unless you're working at a hard-core "development shop" (which it sounds like you're not), things like personality and ability to get along with "the business folks" at your company are just as valuable as coding skills.
posted by mkultra at 9:50 AM on January 25, 2006
Have them talk through examples of what they did, and prod them about some of the choices they made (platform, code abstraction, etc.) and why they made them. Anyone can memorize the facts needed to pass tests covering hypothetical scenarios, but being able to describe real-world solutions to real-world problems is key. At the opposite end of the spectrum the "Impossible Question" (covered in the Joel On Software article) is another good tactic for testing creative problem-solving skills.
I also agree with blueplasticfish- unless you're working at a hard-core "development shop" (which it sounds like you're not), things like personality and ability to get along with "the business folks" at your company are just as valuable as coding skills.
posted by mkultra at 9:50 AM on January 25, 2006
On the other end, as a software developer, I've had some good interviews, and some really bad. On the technical side, I always prefer it when asked concept questions, as opposed to "code me up something that does xxxxx". With a concept question, I have more of an oportunity to relate it to my experience, to discuss the bigger picture, and yet still show I know what I'm talking about. I HATE "code this now" questions. For starters - how often do you actually write real code (not pseudo code) on paper/whiteboard? And I don't code well under pressure, pressure being in this case someone standing over me staring. Tight deadlines and stress are one thing and relevant, that is not.
I second the idea of getting a potential employee to just talk about what they've done. If you get them down to the nitty-gritty details, it'll become quickly apparent when they're bullshitting. Also, especially for a small team, personality is so important, at least as important as a technical skill set. A competent developer can learn a new skill or technology. They can't change who they are. Ask them how they handle stress. Ask about how they handle conflict. Can they hold a normal conversation? Would this person drive you nuts?
I'm looking for work at the moment, so if by any chance you're in the Vancouver area, my email's in my profile. :)
posted by cgg at 9:56 AM on January 25, 2006
I second the idea of getting a potential employee to just talk about what they've done. If you get them down to the nitty-gritty details, it'll become quickly apparent when they're bullshitting. Also, especially for a small team, personality is so important, at least as important as a technical skill set. A competent developer can learn a new skill or technology. They can't change who they are. Ask them how they handle stress. Ask about how they handle conflict. Can they hold a normal conversation? Would this person drive you nuts?
I'm looking for work at the moment, so if by any chance you're in the Vancouver area, my email's in my profile. :)
posted by cgg at 9:56 AM on January 25, 2006
I would say that, since you'll be the only one working directly with the person, the trump card should be: Do you get along with them? You don't necessarily have to go out for a beer every week, but since there seems to be no dearth of programmers, make sure you like the person as a person.
posted by Alt F4 at 10:13 AM on January 25, 2006
posted by Alt F4 at 10:13 AM on January 25, 2006
Since you said you've hired a few people in the past, I assume you already know that personality trumps programming skill. Bad social skills are a problem with many coders.
Having hired many programmers I've found my biggest problem area was QA. Other than personality, the hires I regretted were always people who never seemed to do enough testing before moving on to the next task. "Did you even *try* this code you wrote???"
Asking questions designed to test their sense of professionalism and pride in ownership are good. Rather than asking them about how they'd code something, ask them to just describe the process. Good coders have a process more evolved than "I grab some boilerplate and start tweaking till it works right."
I've had real problems with every hire who mentioned they could code in every language. That's a flashing red light for me.
posted by y6y6y6 at 10:45 AM on January 25, 2006
Having hired many programmers I've found my biggest problem area was QA. Other than personality, the hires I regretted were always people who never seemed to do enough testing before moving on to the next task. "Did you even *try* this code you wrote???"
Asking questions designed to test their sense of professionalism and pride in ownership are good. Rather than asking them about how they'd code something, ask them to just describe the process. Good coders have a process more evolved than "I grab some boilerplate and start tweaking till it works right."
I've had real problems with every hire who mentioned they could code in every language. That's a flashing red light for me.
posted by y6y6y6 at 10:45 AM on January 25, 2006
There is controversy over whether the "Impossible Question" or "Microsoft Question" style of interviewing actually gives you anything good. I'm against it myself. Ask them how they would solve a real problem as it relates to your platforms, frameworks, business domain, etc., rather than how they would move Mt. Fuji.
posted by matildaben at 11:06 AM on January 25, 2006
posted by matildaben at 11:06 AM on January 25, 2006
I'd ask questions about their testing procedures, and their favorite test methodologies.
This should help you find somebody who understands and cares about reliability.
posted by I Love Tacos at 12:26 PM on January 25, 2006
This should help you find somebody who understands and cares about reliability.
posted by I Love Tacos at 12:26 PM on January 25, 2006
Forget "Impossible Questions". See if candidates can answer possible questions.
I remember I interviewed this guy with a Master's degree in Comp Sci, for a PowerBuilder position. PowerBuilder was (is) a RAD tool for building database querying and updating apps, and it included its own more-or-less C-like programming language.
This language didn't include bitwise (or bit-shift) operators. (Or pointers or pointer arithmetic.)
So I asked the candidate to explain how, in that language, he'd write a function that, passed unsigned integer and an offset in the closed interval [0,15], would return true iff the bit at that offset were set (that is, equal to one).
A solution, in this particular language, is inelegant and tedious, but rather obvious. I was looking for how he'd approach the problem, and a discussion of the (very simple) trade-offs involved in solving it. Or so I thought. I
The candidate had no idea how to proceed.
So I proceeded to make the question easier and easier, which only rattled him more.
Eventually, I was reduced to asking him, "ok, if the unsigned int is 2 and the offset is 1, what would the answer be, true or false?"
No answer.
Finally: "Well, ok, what's 2 in binary?"
No answer, just a looked of painful confusion.
So I asked him, "what was the subject of your Master's thesis?" and he couldn't answer that either.
So start off by asking a question that seems obvious, and see where it goes.
posted by orthogonality at 12:59 PM on January 25, 2006
I remember I interviewed this guy with a Master's degree in Comp Sci, for a PowerBuilder position. PowerBuilder was (is) a RAD tool for building database querying and updating apps, and it included its own more-or-less C-like programming language.
This language didn't include bitwise (or bit-shift) operators. (Or pointers or pointer arithmetic.)
So I asked the candidate to explain how, in that language, he'd write a function that, passed unsigned integer and an offset in the closed interval [0,15], would return true iff the bit at that offset were set (that is, equal to one).
A solution, in this particular language, is inelegant and tedious, but rather obvious. I was looking for how he'd approach the problem, and a discussion of the (very simple) trade-offs involved in solving it. Or so I thought. I
The candidate had no idea how to proceed.
So I proceeded to make the question easier and easier, which only rattled him more.
Eventually, I was reduced to asking him, "ok, if the unsigned int is 2 and the offset is 1, what would the answer be, true or false?"
No answer.
Finally: "Well, ok, what's 2 in binary?"
No answer, just a looked of painful confusion.
So I asked him, "what was the subject of your Master's thesis?" and he couldn't answer that either.
So start off by asking a question that seems obvious, and see where it goes.
posted by orthogonality at 12:59 PM on January 25, 2006
Read 'Good to Great'.
The analogy used in the book is that of a bus. Most businesses are concerned with getting the bus somewhere (a goal).
They frame their findings thusly: The most important step is to get the right people on the bus. Then get them in the rights seats (job positions). Then be concerned with where the bus is going.
A great business is all about the right people. So... who are the right people? Disciplined people with passion. This seems esp. true to me in a small shop.
With the ideal employee, not only will they posse the skill set, but you will have to do NOTHING to motivate them. You won’t have to watch them, or worry about what they are doing.
This has changed how I hire people. Skill set is one thing, intelligence and passion are another. If they don't quite have the skill set, fine... provided they posses the discipline required.
How do you find out about discipline? Conversation. Find out about the person. A casual meal is great for this. How were they raised? What did their parents do? How did they make it through school (if they did) or how did they come to their present position? Have they faced adversity? How did they handle it?
With my employees, I can give a task and know, just know, that it will be done, and done correctly. I also know what task will require them to expand their skill set. Their discipline and passion allow me to be hands off and nearly worry free.
posted by killThisKid at 2:53 PM on January 25, 2006
The analogy used in the book is that of a bus. Most businesses are concerned with getting the bus somewhere (a goal).
They frame their findings thusly: The most important step is to get the right people on the bus. Then get them in the rights seats (job positions). Then be concerned with where the bus is going.
A great business is all about the right people. So... who are the right people? Disciplined people with passion. This seems esp. true to me in a small shop.
With the ideal employee, not only will they posse the skill set, but you will have to do NOTHING to motivate them. You won’t have to watch them, or worry about what they are doing.
This has changed how I hire people. Skill set is one thing, intelligence and passion are another. If they don't quite have the skill set, fine... provided they posses the discipline required.
How do you find out about discipline? Conversation. Find out about the person. A casual meal is great for this. How were they raised? What did their parents do? How did they make it through school (if they did) or how did they come to their present position? Have they faced adversity? How did they handle it?
With my employees, I can give a task and know, just know, that it will be done, and done correctly. I also know what task will require them to expand their skill set. Their discipline and passion allow me to be hands off and nearly worry free.
posted by killThisKid at 2:53 PM on January 25, 2006
Response by poster: Thanks, everyone! Rather than litter the page with "best answers", I'm going to say that each and every reply here has been immensely helpful, because they all were.
posted by bigbigdog at 8:58 AM on January 26, 2006
posted by bigbigdog at 8:58 AM on January 26, 2006
This thread is closed to new comments.
Basically whiteboard tests are nothing to focus on. They can provide a nice demonstration of getting someone to think on their feet, but no-one really codes on a whiteboard in real life. It's hard to add in lines, it's hard to debug, and it's just not a good test of language knowledge. Flowcharting, however, is a different matter.
posted by wackybrit at 9:24 AM on January 25, 2006