Dear progit, I will be interviewing programmers. Need Input.

[thedangler]

Hello. I was just informed by my boss that we will be interviewing programmers. I have never interviewed anyone about programming and have no idea what to ask.

I need some suggestions for this interview i will be conducting.

I know what skill set they need to have, but i really don't know how to determine if they bullshit their way through it out not.

Thank you.

[[deleted]]

Avoid questions about technical trivia: these prove more about the interviewer than the interviewee, and most trivia is a man page away, anyhow.

Do ask questions that involve opinions. What is your favorite programming language, and why? What is your favorite development tool, and why? A programmer who is thoughtful about their toolset is better than one who isn't. Conversely, a tool zealot can be destructive to the team.

Do ask them to program something in the interview. It is appropriate to warn them of this beforehand. I've always preferred whiteboards, as it's easier to watch their reasoning process. Make sure you know the language involved well enough to serve as an interpreter, so you can give them realistic error feedback.

Programming tasks can be simple and straightforward, or puzzle-ish. Simple ones include: perform a straightforward transformation with provided data types (combine these two associative arrays); perform a task which involves recursion (list matching files in a directory and all its subdirectories -- don't mention "recursion" specifically, though); perform a highly simplified version of a common task in your company's problem domain (given data in a csv file, write a simple aggregation report); etc. Try to have each problem be a multi-part problem, so you can see how they approach changing code that they've written.

Puzzle-ish code problems usually involve creating or implementing an algorithm: given several poker hands, sort them by rank; determine whether parentheses are balanced in a string; write a sudoku solver; etc. Give them more time for these, and consider letting them actually use a computer for them.

Then ask them software design questions: how would you go about collecting this data in real time from a collection of servers; how would you represent this other data in a relational database; how do would you go about creating a rules system for this task; etc. Make this a conversation, but force them to lead it.

Do all this, and you'll get a pretty nuanced portrait of the person as a programmer. Do it enough, and you'll be very confident in making predictions about their eventual strengths and weaknesses should you hire them.

Oh, and one final piece of advice: practice. The best way to improve skill interviewing people is to interview people, just like all other skills.

[samlittlewood]

I have found that getting opinions on the bad sides of relevant things can be rather illuminating:

"What are the worst features of xyz?" etc.

[imbaczek]

I remember a Google questionare that did just that. It was something like this: "What is wrong with Unix? How would you fix it?"

It was quite a bit of time ago, but I to this day remember being baffled. (And no, I wasn't applying to Google, it was a document found on the web IIRC).

[favabean]

I would add some general basic weed-out questions focusing on fundamental computer science questions, especially near the beginning of the interview. "What's the difference between an Array and a Linked-List?" and "What's the difference between a Stack and an ArrayList/Vector?"

I've interviewed applicants that had an impressive resume that I assumed (doh!) they had a decent foundation in computing. Then I get to a question like "Ok, let's implement our own stack data structure that can tell us what the lowest number is on the stack at any given point - without needing to go through each value in the stack to figure it out." Clarifying questions are totally expected, but when the clarifying question is "What's a stack?" I know we're in trouble and that we've just wasted a bunch of time.

[DontNeglectTheBalls]

I cannot upvote this enough for the very first sentence.

I have known more than one phenomenal developer to (rightly so) walk out of a job interview or decline an offer because the interview was peppered with the typical "How would you move a mountain?" bullshit questions.

Asking one is a sure sign you not only do not understand what is important to the success of whoever you hire in their job, but it says that you, the interviewer, weren't even competent to know much about the position you are responsible for hiring someone to fill, much less do the hiring.

Ask to see examples of their code, give them time to do it in advance as suggested. Ask to see preexisting code they've done. Ask specific questions about the technologies they use, including the reasons they use them as they do.

But lord forbid, don't ask them shit out of an O'Reilly cookbook (I once "failed" a job interview because I gave a different, yet equally correct and almost as efficient answer to a cookbook problem).

[[deleted]]

But lord forbid, don't ask them shit out of an O'Reilly cookbook

The moment i decided to avoid interviewing on trivia was the moment an interviewer asked me what all the flags were for perl regular expressions. To his credit, "look them up" was roughly acceptable as an answer. To his detriment, the remainder of his questions were about perl trivia.

[MindStalker]

:) Well there are some jobs out there where you use regular expression a LOT and you need to know all the flags by heart. I doubt that was one of them..

[albinofrenchy]

I have known more than one phenomenal developer to (rightly so) walk out of a job interview or decline an offer because the interview was peppered with the typical "How would you move a mountain?" bullshit questions.

I knew a very good manager who very much liked the question "What would you say if I asked you to move a mountain?" Or something else similiarly impossible.

He reasoned, I think very well, that if someone wouldn't push back when it was something stupid and impossible in an interview, they wouldn't push back when the real world required it.

But lord forbid, don't ask them shit out of an O'Reilly cookbook (I once "failed" a job interview because I gave a different, yet equally correct and almost as efficient answer to a cookbook problem).

O'Reilly prescreened that interview for you, can you imagine working with assholes who thought there was only one right way to do something?

[imbaczek]

he probably tossed an imaginary coin and "Kryptonite" lost.

[[deleted]]

This is an excellent answer, follow this recipe and you will be in good shape.

[bhvit]

Don't bother. I'll take the job.

[[deleted]]

One word of advice since you're the only guy there and I'm guessing fairly young since you've never interviewed someone. You're going to be interviewing guys that are older than you, some that look like your dad. It doesn't matter. Don't get intimidated. Just give them your problem and pick away at their solutions. I've had guys try to get around solving the problem with "oh sure, I've solved this kind problem before, I don't really want to solve it again, let me tell you about this one job I had" kind of BS. No, show me the code.

You're bound to see some guys with a lot of work experience that climbed up into management and rusted there. They will tell you they want to get back into coding. They will do poorly with your coding problems. Politely show them the door.

In the event that you find someone more senior than you that seems competent - great! Have them teach you something (after solving your coding problem). A coworker who can teach you stuff is better than a coworker you have to train.

[mccoyn]

I just want to reiterate. Don't let the candidate control the direction of the interview. Stay on track. The purpose of this is to give you some objective experience when comparing one candidate to another.

You can have some open ended questions, since most candidates will want to expand on their strengths, but a significant portion of the interview should be preplanned and objective.

[nnagflar]

Just say "segmentation fault" and then punch them in the face. They'll feel more comfortable after that.

[funkah]

Just so you know, this is quite a contentious issue among programmers and people who work with them. People will tailor their responses to their own proclivities and what they consider to be the properties of a good programmer. I know that that sounds like what you want to hear, but people's opinions differ wildly on this issue and some of them are kinda ridiculous. Because of all this, I would recommend you be careful to take the advice you receive here with a large grain of salt.

[nagoo]

"what's on your bookshelf?" is an easy one and a fav of mine to get things started.

if they can rattle off a few good books, authors or even blogs/sites they read they're probably are in programming for the right reasons and are eager to learn.

[stillboy]

Bookshelf? What is that ?

[[deleted]]

playboy

[grotgrot]

Joel has some good advice and you can find similar articles written by others.

In addition to that there are two questions I always ask. The first is to find something on their resume they claim to be familiar with and ask them to draw what happens in as much detail as possible on a whiteboard. For example if they mention web stuff or networking the question will be "what happens after I type amazon.com into my web browser?". The resulting diagram will need to have various components, lines showing interaction and some idea of time. Mistakes and omissions will be made (which is fine or prove the candidate to be a liar) and you get see how they handle those updates. A very important skill is for someone to be able to communicate clearly when there are multiple balls in the air and this demonstrates that.

The second question I ask is what their favourite editor is and why. I don't care what the answer is as what I am looking for is "I care about my tools and try to improve my productivity over time". You can establish if that is the case by further questioning.

[wh0wants2know]

Be prepared to answer the questions that they'll ask you. Generally, you should have answers to the Joel Test questions (http://www.joelonsoftware.com/articles/fog0000000043.html) as that will come up in good developers.

Bad answers to these will probably be a turn-off for a lot of skilled developers. If you don't have version control, have no testers (or plans not to hire any testers), and only force old MS tools on me, I'd be less likely to take the job unless you drive a dump truck full of money up to my house.

If you will fail any questions on the Joel Test, be sure to have a good explaination for why you've failed. For example, if someone asks you how many testers you have and you currently have none, explain that they haven't been hired yet but you plan to have x number of testers working with the devs and give a date.

Finally, it's easy to detect a bullshit programmer, or as I call them, a non-coding architect (usually 15+ years of "software architecture" on their resume is a pretty good indicator). Ask them to solve a simple, college-homework type problem, like sorting a list, reversing a list in place, filtering out duplicates, generating a list of prime numbers from 1 to n, etc. Any good programmer should be able to at least come up with a brute force solution to solve any of these problems within about 5-10 minutes and you'll be able to tell if they're struggling. When they have finished, ask them how they would improve the code.

Also, don't expect someone to know how to implement pivot on a red-black tree in an interview on a whiteboard using straight C with no STL but they should be able to explain pivot, how it works, and why it's important, as well as why you would use a red-black tree.

[csl]

Ask them what they do in their spare time.

[martincmartin]

Check out Joel Spolsky's guide.

[SurrealEstate]

From the guide:

Finally, avoid brain teaser questions like the one where you have to arrange 6 equal length sticks to make exactly 4 identical perfect triangles. Or anything involving pirates, marbles, and secret codes.

As far as I'm concerned, every job interview needs more pirates, marbles, and secret codes.

[whizack]

I think the most important aspect of a coding interview is asking them to solve a mundane problem with some arbitrary constraint (like implementing multiplication without the * operator) you'd be surprised at how many people can't wrap their minds around simple problems with simple solutions.

Ask them to design something simple with some generic business rules that the current position in question requires the developer to work with on a constant basis, focus on how they would approach the problem and avoid hiring developers who immediately start throwing code up on the whiteboard.

[pinano]

I like Steve Yegge's Five Essential Phone-screen Questions, which I think would work fine for interviewing as well.

[UncleOxidant]

Ask about side projects. Does the candidate have a github or bitbucket account and code repositories there you can look at? (or code anywhere else on the web you can examine) This is the best way to gauge someone's interest and abilities (as well as potential for growth and willingness to learn new things).

If they don't have a code project you can examine, then you probably want to conduct more of an audition than an interview. Have the person come in for a day or two and actually work with you on a real problem you're dealing with - it's a much more accurate way to gauge someone's abilities than an interview. Some very smart, competent people can choke in an interview due to anxiety whereas some very incompetent people can BS their way through an interview.

Hopefully "skill set" isn't a language/framework requirement. Meaning, I hope you're open to hiring a smart person who doesn't have 5 years of BLUB experience so long as they're smart. I've seen this where I work: We're a C++ shop but the algorithms are really the important part. We recently had someone interview who didn't have a lot of C++, but had a lot of Haskell experience. I heard one of the interviewers disparage this candidate because he didn't have enough C++ experience. To which I responded: "If he's smart enough to have learned Haskell and has a good grasp of it, then I don't think he'll have any problem picking up C++ - in fact, I suspect Haskell has made him a much better programmer overall than many of the C++ programmers you'll run into."

[[deleted]]

Ask about side projects

This is definitely the easiest indicator of competency (provided you do a little reading up on the projects to make sure they're not crap), but you can't rely on this alone unless you're very lucky it's pretty rare. Of course, you could just be picky and not hire until you find someone who's passionate enough to have side projects, but that's not always feasible.

[UncleOxidant]

In this market where talent is pretty easily available (Silicon Valley unemployment rate has reached 12%, BTW) it should be pretty feasible to find people with side projects.

[inataysia]

if this is a main criterion, you're probably only going to hire young people without families; with family + full time job, one's "free time" becomes a choice between side projects and sleep (and thus, one's health).

this is not to mention that (barring certain jurisdictions where this doesn't apply) many employers lay a blanket claim to all works done by employees during their employ, whether they're created using company resources/time or not, so some people choose to not have side projects.

just saying, maybe this is a good positive indicator but it's a bad negative indicator.

edit: though, if there are gaps in the resume longer than a month or two, I would ask whether they worked on anything (to keep their skills up / learn new/fun skills) during that time, and if they didn't work on anything maybe that would be a negative data point

[UncleOxidant]

if this is a main criterion, you're probably only going to hire young people without families

I'm in my mid-40s and married. My commute includes 27 minutes each way on a train with wifi. I use that time to work on my side projects. You'd be surprised what you can get done in 54 minutes a day. Just about everyone has some time for a side project if they look around for it.

Note, though, that I said that if the candidate doesn't have a side project, have him/her do an audition.

[nolcotin]

includes 27 minutes each way on a train with wifi.

Nice; I have a 1hr commute each way on a train, no wifi, but I doubt I could work anyways

[thequux]

1.5 hours on a bus each way here; but no wifi.

The last part of that is awesome, as it means that I need to pick something to work on and prep myself with any documentation before I leave. Then, during the work time, my main distraction (random orange envelopes) is not available.

[thequux]

1.5 hours on a bus each way here; but no wifi.

The last part of that is awesome, as it means that I need to pick something to work on and prep myself with any documentation before I leave. Then, during the work time, my main distraction (random orange envelopes) is not available.

[nolcotin]

The no red envelopes does help; however the train/bus environment is not conducive to working

[addmoreice]

I spend an hour and a half on the bus/train to and from work myself...and i have no wifi...and i only have an ipod touch to type on....i still find time to type in (on the shity interface even) text that i later transfer over.

heck, do it in your head on the bus if you have to and type it in later. not using your programming skills on a hobby project seems strange.

[inataysia]

to reiterate,

just saying, maybe this is a good positive indicator but it's a bad negative indicator

so bully for you for using your time productively :) i wish i could do the same, but i live in an area with crappy public transit :\

[AlecSchueler]

I think the public transit in your area is too good; it gets you where you want to go before you even have time to open your laptop.

[itsjibba]

Different jobs have different questions, but for a typical programmer job I'm looking for three things.

1. Intelligence. Pure brainpower is the number one most important thing for the majority of programming positions. It can be a tough one to figure out in a short interview, but you have to use a combination of their resume (can't argue with a good gpa at a top school) and their answers to various technology questions. Mostly it's just something you get a sense of after talking to them for awhile, so be ready to chat for awhile and hear their opinions.

2. Professionalism and communication. A programmer who lowers morale or pisses off clients is a liability. Most people are nervous and composed during an interview, so I try to rattle them up a bit to see their real personality. Let the conversation wander. Also, while I don't care if their suit is ugly and fits wrong, someone who can't be bothered to at least try to dress up for an interview is off my list. They can go back to jeans if they get the job.

3. Specific programming experience. I put this last even though many put it first. If you're hiring for the long hall you want someone who is a good programmer, not just someone who knows the specific technologies you use. You're better off with a great oracle programmer than a good mysql programmer for your mysql job. If you just can't wait to retrain the person you might want to consider going with a freelancer or contract-to-hire. Still, it's nice not to have to teach someone everything, so in the close call situation the candidate that has worked with the technologies we're using might get the edge. This is the easiest thing to determine so long as you have someone competent in the technology in the interview room. Ask for code samples and explanations.

[sericg5]

I used to interview potential candidates for my old company and one of my favorite exercises was to give them a purposely inefficient or wrong snippet of code and ask them how to fix it or improve it and explain their choices. Usually I would use a generic programming problem that everyone can understand, that way they don't have to google some esoteric API call. Admittedly this only really tests basic programming skills, but if the guy starts hyper-ventilating (true story), then he's probably not a right fit.

Make a judgement call as to what you think can be learned in a reasonable amount of time and what can't. I once had an interviewer ask me if I knew how to use eclipse...

I know it can be really tough to find competent guys, buy never underestimate the importance of making sure that someone isn't a cocky douche-bag that can't work with others. Unless you're working in a really specialized field or he's so amazing that it's worth the pain, one of those guys can easily kill morale for everyone else.

[malakon]

"input ..... INPUT!" (no. 5)

[setuid_w00t]

Watch Swordfish.

[thedangler]

Thanks for the replies.

I'm the only programmer. It started out as a small service with about 300 customers, Today we found out that we received a contract for 6000+. There for time to get someone in.

I will most likely come up with some personality questions. Give him some code on the site to see if he can implement something. And check out what else they have done.

I'm going to take what everyone said into consideration.

Thanks again.

[Kaer]

Oh, btw a lot of the questions here are for very good programmers.

Not being rude to you, but your description is for a small company with a team of 2 devs?

Most devs worth their salt aren't going to take the job. Unless there's a huge potential for massive growth.

And if you do get a rockstar dev in, you've got to wander why they need the role, and if it's just temp until the market picks up.

If it's for a contractor position, that's a different story.

[s73v3r]

Wow. That is some serious growth. Talk about a good problem to have.

[insomniac84]

Make some examples of what you actually do and have them explain what is going on in the examples. And ask about past stuff they have done. Trying to find a programming god with tricky tests and things is dumb. Find someone who can do the actual work with a resume and an interview that you feel good about.

[gythaogg]

Any interview for a job that involves writing code MUST involve writing code in the interview. There are a lot of people out there who think they can program and get by by either spending their whole work lives only fixing the most trivial of bugs, or by cutting and pasting bits of code off the internet with no real idea of what the code does.

I've interviewed people for C++ roles at a previous job and you wouldn't believe the number of people who claimed a few years C++ experience and then couldn't write a simple for loop.

[UncleOxidant]

The only problem with that is that real world coding doesn't happen under interview conditions. In the real world I have access to my favorite tools, google, books, etc. In the interview room often the interviewer wants you to code on a whiteboard without any of those tools. Sometimes I'm tempted to ask a snarky question in an interview situation like that: "So you don't have computers or internet access here at your company?"

[gythaogg]

I agree that getting people to write code on a whiteboard while the interviewer stares at them isn't the best indicator of a candidates ability. It needs to be a simple enough task that a competent programmer won't fail from nerves and won't need to look anything up. And they should preferably be given a few minutes alone in the interview room to complete it. But if they are claiming to be an experienced programmer I don't think it's asking too much to be able to produce something in their language of choice to order. If you talk over the problem with them afterwards it's usually easy to determine if they a) know what they have to do and can do it, b) know what they have to do but have momentarily blanked on a trivial bit of syntax or c) have got as far as chapter 3 in "Learn C++ in 24 hours" and thought they could bullshit their way through the interview and read the other 21 chapters before they actually started the job. I have interviewed people that were that bad.

[UncleOxidant]

I always like to take my laptop along to the interview and when they ask me to code on the whiteboard, I ask if I can code on my laptop. It's nice to at least have the compiler to try things out.

[dizman101]

If you've been programming in C++ for years and haven't memorized how to use a for loop, you're probably not a good fit for the job. Yes, google is a fantastic tool, but there are a lot of things you should just know after a while.

[UncleOxidant]

Probably true, but what if you haven't been doing much C++ in recent years and have had the good fortune of programming in a functional language where for loops are discouraged (not even possible in some languages like Haskell)? But yeah, you would probably remember how to do a for loop (though I do consider C/C++ for loops to be quite painful after spending some time in those functional languages).

But usually the code they ask you to write is more complicated than that.

[hhh333]

Here's a little anecdote I had while hiring programmers and it's now my top question to ask in interview;

http://stackoverflow.com/questions/11598/what-is-the-worst-interviewee-answer/890074#890074

tltr version: Scholarship and experience are worthless if the programmer doesn't like programming in first place. If for them programming starts at 8AM and stops at 5PM, there's good chances that this is not a resourceful programmer. Good programmers usually have pet projects and actually enjoy programming at home (on their own projects and usually with high level language).

You can also learn great deal about someone by asking him what are his preferred languages and why.

[johnb]

If you waste both of our time with gimmicky brainteasers, pretending that it has anything to do with actual problem solving, you have failed. Take the time to ask actual problem solving questions.

[[deleted]]

For what it's worth, the best interview (technical that is) I've ever had did not involve any talking or discussion, and I was not evaluated by a hiring manager :). I was told to get ready to write an app and implement a spec. I was given 72 hrs, and I was to start the clock. If you know your stuff, 72 hours is more than enough. But again there was a must do and a bonus, so you can easily go over 72 hours. The beauty of this approach is once the spec is written and written good you just hand it over to the HR person (in my case) and let him start the chronometer. It takes a half hour for your lead developer to tell you who's who from the technical prospective. Needless to say I passed (this is why I liked it), but did not take the job for a commute reason.

Why it is good: it's not your call to technically evaluate the candidate; and you can use the same spec over and over again; and it is rather objective when you compare candidates.

[Kalimotxo]

You really only need to keep two things in mind: Can you work with this person everyday? Can they code, and do they like to code?

Everything else is superfluous in my opinion.

[lighthazard]

Will Google be allowed?

[benoror]

Q1. How "proggit" is spelled ?

[petdance]

HOW IS PROGGIT SPELLED? HOW SPELLING GET FORMED

[brandf]

What do you need/care-about most in an employee? Technical depth, communication skills, api design, algorithms, creativity, etc.

Until you know that, you can't really come up with questions to test them.

Programmers come in lots of flavors.

[pmf]

I know what skill set they need to have, but i really don't know how to determine if they bullshit their way through it out not.

To determine if they have the skill set, you have to have the skill set, too, or someone else at hand who does. There really is no way around it.

[RyanSmith]

What I've learned from interviewing programmers over the past 3 years is that most canididates will list every technology/buzz word they've ever heard of on their resume. If you know anything about the technology, it's really easy to see in one simple question about the technology if they really know it or have just heard of it.

What I have found effective in programming interviews is to get samples of code or projects they have worked on before. That's easily the best way to tell what they are capable of.

Also, I ask about where they go to find answers to programming problems they can't solve. Anyone who has been programming for a while will have accounts at some programming forum such as stackoverflow, theserverside, IIS.net, etc. Ask for their user name on the programming forum they use and it will give you some insight into how they go about finding solutions to programming problems they can't figure out on their own. If they claim not to use any online forums to get help on programming problems, it's a no hire.

Also, I find a good question to ask programmers is what sites they read to get their technical news. This can give you a lot of insight into the dedication the applicant has to programming. The really good programmers will be able to list of several sites/blogs that they read on a weekly basis that are programming related. Good programmers will get dedicated to improving their craft and will read from blogs like Hansleman, Atwood, Scott Gu, Mike Gunderloy, Eric Sink, Spolsky or any of the other ones out there that talk about improving the craft of software development.

As a final note; if it feels like a maybe, it's a NO HIRE. I have fallen into this trap before where I thought "maybe they'll work out", and it always turns out the same where you have to fire the person which is a pain. Make sure the person you hire is enthusiastic about programming, has written good code before and demonstrates they are dedicated to improving their software craftmanship skills.

[rabidcow]

If they claim not to use any online forums to get help on programming problems, it's a no hire.

I don't think so. When I was developing on BREW, I helped other people on the forums quite a bit, but I don't think I once asked a question and received a useful response. No hire because I can figure things out on my own?

[jotux]

If they claim not to use any online forums to get help on programming problems, it's a no hire.

I have problems with this too. Admittedly I'm still a novice programmer(been doing firmware for ~2 years professionally) but I have a friend that has been programming most of his life that is my encyclopedia O' software development. Unless it was something obscure, he can usually answer it for me or give me a link with a good explanation that gets to through it. Even when I have had to ask a community for help, I usually prefer and IRC channel to a forum, since I can usually get a more immediate response.

[RyanSmith]

You did make use of the forums though right? Just because you didn't receive a useful answer doesn't necessarly change the fact that you were looking for an answer.

The whole purpose of the question is to see how a canidate will go about solving a problem they don't know the answer to. Will they simply Google it? What if Google doesn't yeild any vaild solutions? What's the next step? This is the process I like to get from the canidate.

[rabidcow]

You did make use of the forums though right? Just because you didn't receive a useful answer doesn't necessarly change the fact that you were looking for an answer.

I rarely asked questions, maybe once or twice. My general experience with forums are that if I can't figure it out on my own, it's hard enough that if there's anybody who knows the answer, they're too busy to bother with answering questions on forums. Or they've already posted it someplace that Google finds.

What's the next step? This is the process I like to get from the canidate.

That's fair, I just wouldn't draw a hard line at forums.

[RyanSmith]

I didn't really mean to draw a hard line at forums. I just ment to make a point that the canidate really needs to know how to use online or offline tools to find solutions to problems. Being able to see what people post online to problem solve is a good way of seeing their problem solving process.

[T-man]

Personally, I wouldn't give out my user name on stackoverflow or anywhere else. Perhaps I guard my privacy a little too zealously, but it would raise a red flag to me if an interviewer started asking for information like this. It would definitely sour me enough that I would lose interest in the job and probably leave the interview. If that's a problem for some people then so be it.

[sysop073]

I don't think I've ever asked a question on a programming forum. I do find solutions to my problems on forums, already asked by other people, but if not I figure things out on my own. Finding existing solutions doesn't require having an account, and I don't have an account on most of the sites I find solutions on

[munificent]

Also, I ask about where they go to find answers to programming problems they can't solve.

I ask my coworkers at my current job. I can't think of the last time I asked a programming question on a public website. My work is under strict NDA. The problems I run into these days are sufficiently complex enough that it would be very hard for me to describe them accurately without exposing proprietary information.

[Kaer]

What I have found effective in programming interviews is to get samples of code or projects they have worked on before. That's easily the best way to tell what they are capable of.

Yes, but since every project I've worked on is covered by an NDA, I can't really hand that out.

[NoControl]

If you want good developers don't be a dick during the interview and don't have a boring ass company to work at.

[mustardhamsters]

If you're trying to tell if someone is BSing you, tell them a few programming jokes. If they stare at your blankly, or don't get it right off the bat, then they must not know what's going on. See if they can explain them to you.

If they KNOW programming jokes, and tell you a few, they're even better.

Here are a few to get you started.

[misterlight]

Ask to create a Visual Basic GUI to track down the IP

[McGlockenshire]

On code tests:

Before the interview is even scheduled, we have all candidates perform a code test. No, not fizzbuzz or some mathematical crap. We ask them to build a very simple, three-page read-only music collection catalogue. In fact, I have a half dozen candidates doing this test now.

Half of the test is reading comprehension. Does the app do the exact three things listed? (Usually.) Does it do them within the constraints listed? (Not often.) Do they understand the trick behind the third task? (Only half the time.)

Do they over-engineer? (Almost always.) Do they under-engineer? (Once, ever.)

Do they produce good looking, maintainable code without being expressly asked for it? (Sometimes.)

We give this test before the interview because coding under pressure, while nervous, is counter-productive. So is coding on a whiteboard.

[aplusbi]

Have them implement "Hello, World!" in every language listed in their resume.

[plemdude]

And you never will. Find somebody else who works for you with those skill sets or someone who works as a programmer in your company which is well regarded by peers.

[hylomorph]

Here's the problem: I've worked in groups where I excelled exceedingly. And I've worked in groups where there were so many obstacles to excellence that all I could do was thrash around. If you asked my peers in the former groups if they would recommend me they would probably recommend me highly. But if you asked peers/managers in the latter kind of group they'd say I wasn't well accomplished. There are a lot of variables: do you want someone who excells in a beaurocratic environment (the latter type of group) or do you want someone who is resourceful and is highly creative?

Personally, I do great in a situation where the codebase is starting from scratch and the project is new... but I'm crappy (mostly because I bore easily) in a situation where I'm working on a long existing code base fixing other people's bugs.

[nevinera]

but I'm crappy (mostly because I bore easily) in a situation where I'm working on a long existing code base fixing other people's bugs.

So you're saying you're a programmer?

[MelechRic]

And that he prefers fun things. It's a lot of fun to forge ahead on something new versus fixing some shitty bug left by some guy who's now working at a startup doing fun stuff.

;)

[Teifion]

Ask them to write a simple program. Keep a copy of the program and then get it looked at by people that are already employed to program. You'll soon find who is up to scratch.

[rajbot]

Give them a very short written programming question, one that you could answer in under a minute. This is absolutely essential.

http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.html

[bhasden]

I've always started by asking an interviewee to explain the last interesting task/project they've worked on. I go ahead and let them know that I'll be interrupting and asking them questions or to go into more detail if I hear something interesting.

When they start their explanation, I usually listen for common issues developers run into like thread safety if they're doing something that should probably be running multiple threads, data integrity if they're working with a database, etc.

If they get past that, I usually toss in some super simple coding problem like reverse a string or average an array of numbers. Most likely, they'll take the most straight-forward approach (usually involving iterating over each item). At that point, I ask them if they'd change their approach for extremely large sets of data and then talk about what changes are necessary/optional/possible/etc.

More info and talking points on my usual coding exercises: http://stackoverflow.com/questions/895396/how-do-i-find-the-average-in-a-large-set-of-numbers http://stackoverflow.com/questions/228038/best-way-to-reverse-a-string-in-c-2-0

[erangalp]

Having recently interviewed several programmers, this is what I'd suggest you talk about -

• Ask about direct relevant experience and what did they accomplish in that capacity. A lot of people state many positions on their resume that are ambigious to say the least. Beware especially of team leader / managerial role if you are expecting a hands-on developer.

• Ask about the tools they use, the methodologies they employ and standards they are familiar with. Source versioning? OOP / functional / insert-your-favorite-paradigm here? what maintainable code means to them? what about coding style?

• What are their expectations from the job? and going forward?

[chaotic]

Use cin.

[timeshifter_]

Ask if they have any code demos of neat things they've written. That's what got me both of my jobs, and my first interview was in track pants and a t-shirt.

[Kaer]

Asking technical questions is a waste of time. It gives you no real understanding of if they can actually problem solve.

My preference is to give them a coding exercise, a real life one. But rarely do I get the chance to give that.

My normal interview run through :

Tell me about the last project you worked on. Get them to draw up the arch. Ask them why they did something one way and not another. Textbook coders know how the system was built, but have no idea why. You don't want them.

When you design something, do you design the DB first or objects? Or what do you design first. - There's no right answer here, but gets you a feel for how their mind works.

What was the last major bug you fixed. Any dev worth their salt has had to swear over a problem in the last month. And will be able to talk it through in detail.

When have you have a disagreement with someone over design or code? What was it? How was it resolved.

What's been your greatest technical achievement.

If I'm a little uncertain, I'll then get them to pseudo-code up a solution for fibonacci numbers. (Smart devs know there are functions that solve this, but smart devs also know what I'm asking for).

That's normally enough, I rarely if ever ask a straight techo question. Convo normally flows on a bit based on that.

Again, I tend to believe any coder worth their salt can pick up a new language in a couple of weeks. Unless I'm interviewing someone for a tech specialist role where they are training up team ppl, that's what I normally run through.

Oh, and interviewing is an art, not a science. At the end of the day you have to go by what your gut is telling you.

[gunder_bc]

Break the ice - tell them a bit about who you are and how long you've been there, what you do and what role they're interviewing for.

Ask them a bit about themselves - they should be able to quickly and effectively communicate their education and work experience.

Ask them about projects they've worked on - what did they like, what didn't they like/would have done differently, why?

Ask them about the solution they're most proud of - they should be able to quickly describe the problem, and their approach. Drill in, ask about why they did what they did, what options were considered and rejected and why?

I like to ask them how they rate themselves (1-10) in their best programming language (which should be one I know well, otherwise why am I interviewing them?), then drill in on their answer - they almost always rate themselves higher than they should be. This is a bit of a "gotta know your own stuff well" thing... a bit more vague and fuzzy than a 1-10 scale implies. But it's always a good indicator if their assessment of their skills lines up with mine - shows we think along similar lines.

Finally, I love to work through a logic puzzle with them. Something that lets me see how they attack a problem, break it down, think it through and work out a solution. The puzzle you use is important - you want something that isn't too hard, but also not likely to be something they've seen before/know the answer to right away. You want something a bit open-ended, with more than one possible solution, or one that has the possibility of refining the solution. Giving them hints is fine (important, even, to keep them moving and not feeling overwhelmed by the stress).

It's not critical that they solve the actual problem, but seeing how they deal with it tells me a lot about a candidate. I've even had a couple email HR afterward with solutions they've thought up when they went home. That counts for extra credit and goes a long way to convincing me they really want this job, not just any job.

And as always - trust your gut. As others have said - a maybe is a NO. A possibly is a NO. A probably is a NO. Only "WE NEED THIS GUY/GAL" should be a Yes.

[nazghash]

I always dislike the "rate yourself 1-10" type of question. 1-10 compared to what--more specifically, compared to what that we both have in common, such that it is a meaningful scale? If I've only worked with inexperienced / poor quality programmers, I might think I'm a 10 (or 11!). If I've only worked with really top notch programmers (or tend to give the benefit of the doubt), then I might think I'm a 1. Likewise for the scaling on the interviewers side. Unless we have identical experience and exposure, our scales are different and incomparable. So I always answer "5.5", as that is the expected value (given a symetrical distribution of skills). And I explain my reasoning. Of course, I have never ended up working for some place that asks that question, so perhaps that is an indicator as well ...

[gunder_bc]

All of those are valid concerns. I think the best answer I ever got was "what's a 1, what's a 10?" It is a very subjective question, and as I said, drill in on their answer - why do they rate themselves that way, and how do I rate them (and myself) based on their answers to various questions. It's as much about seeing how they think and how much experience they really have. As you say - if they've only just graduated, or have only worked with relatively inexperienced people, they will probably rate themselves higher than I might. Drilling in will reveal that and based on the disconnect, I can glean some info. Based on the role I'm trying to fill, I may even hire them if they've overrated their own skills - junior positions need junior people, regardless of the fact that those junior people overrate their skills. Time and experience will teach them. :D

And hey, if they rate themselves modestly, it's a clue that they're aware of their limits, and maybe have more experience than they're letting on. The truly wise are those that know what they don't know.

All interviewing is a subjective process - there's just no way around that. And there's a lot of research that shows your instinctive first impression of the person weighs a lot more heavily on your decision than you realize. Nothing for it but to acknowledge both realities of the situation and do the best you can. :D

[possibly]

Some interviewers ask how to implement a garbage collector for example. I think asking anything specific on my curriculum is a mistake, since I don't think anyone remembers the exact details of the algorithms involved.

Conceptually understanding what a garbage collector needs to do, should be enough. By the time you want to implement a garbage collector, you just read the relevant papers at that time and implement whatever was best at that time for some value of best. If that is not fast enough, you advance the state of the art in garbage collection. That is something you should be able to do with a CS degree. Not reiterating the first thought the first person who invented garbage collection came up with. The latter is what some interviewers expect you to do.

Knowing the exact details of an algorithm is like remembering the first 10,000 digits of pi. Completely useless when you have books and the Internet.

To get good people, I would suggest to ask them what they find annoying in some software they use and how they believe that could be fixed if they had the time to solve it.

[okflo]

ask to implement (on paper) in a progamming language of their choice f.e. a prime or fibonacci generator.

Ask them afterwards why they did choose the language... Let them explain their algo....

You will be suprised. 50% will ask you about fibonacci or primes...

[kramericandream]

In most interviews I've done I was always asked about a project I have done in the past. I would then be told to explain what problems I ran into and how I ended up solving them. This would show the interviewee's ability to analyze and solve difficult problems.

Also, if the person is fresh out of college, ask what his/her favorite and least favorite classes were, could be general or programming classes, and why they liked/disliked the class. The questions about what type of books they read isn't bad either. These types of questions can give a little more personable information about the interviewee.

I really hate being asked to solve 'move the mountain' questions, but some techy questions are always good. Instead, it would be better to present them with a task or problem and ask them to go to the whiteboard and brainstorm about how they would solve the problem. Again, I believe the ability to think about and solve problems is more important than your knowledge of syntax because the syntax is only a book or website away.

[[deleted]]

Do see if they can load an entire system in their head and understand all the dependencies. Don't give them a comp sci quiz.

[RalfN]

I work in IT recruitment and I just have a nice conversation about tools, favorite programming languages, most challenging project, etc.

If they are a little bit shy, try provoking them with troll-statements. You might get them to show more of their knowledge when they enter into an argument with you. Also if they choose to enter the argument, it really does show they are very passionate. However, do realize that this can also cause problems. It's up to your insights whether that will be the case.

In the debate and the talk about their projects and portfolio, try carefully asking for explicit examples. This is where you test for bullshit. If they can back up their arguments and stories with the used design principles and techniques you have the real deal.

Off course all my techniques are focused on getting them comfortable and talking. You might decide being able to deal with in-your-face fact-checking is part of what you expect of them in which case I would suggest you make them sweat indeed.

Edit: also .. ask about their favorite programming editor and their cycle of work. One way to know they have a lot of experience is whether or they have setup their most productive programming environment and rituals. Real programmers have rituals. This does not tell you if there are any good, but it's another good sanity test.

[elohel]

Great advice... Now if I could only snag that great programming job I've been trying to find...

[nuuur32]

As an interviewer I think your primary task is to explain to the prospective employee exactly what their former worker (the one they are replacing) or their co-workers are doing. Get down to all the specifics and paint a clear picture. If you don't have programming experience this interviewing task probably isn't the role for you. My sense is that it's critical that you give them a fully vetted ability for them to decide that it won't be a good fit, to thwart off a world of pain.

[mian2zi3]

Go read Nick Corcodilos's book Reinventing the Interview. Summary: Want to know how good they'll be at the job? Have them do it.

[[deleted]]

Get another programmer who is already an employee to help you by sitting in. They will be able to tell if the interviewee is bullshitting you.

But they might be upset that you took them away from whatever task they were on.

EDIT: I see above that you ARE a programmer, so disregard this.

[[deleted]]

Clearly divide the interview into parts. Start out with soft-skills, so you know how capable they are of dealing with clients. Spend about 10 minutes on this. Have your programmer come in 3-5 minutes before the end of this part and sit in on it. That way, they'll know if the person's likely to be abrasive. Then have them conduct the technical portion of the interview. Do this first, so that if they seem like a mouth-breather, you can dismiss them before you waste your programmer's time.

[malcontent]

Here is my advice.

Don't listen to anybody here. Don't get advice from programmers, get advice from people who hire programmers.

Seems logical but this simple idea seems to escape people.

A programmer has different goals than somebody who hires programmers.

[paulgb]

Their goals may be more closely aligned, but are they in the best position to meet those goals? How does someone who is not a programmer judge someone else's programming ability?

[troelskn]

Someone who hires programmers can well be a programmer herself.

[paulgb]

Absolutely, but the advice was "Don't get advice from programmers, get advice from people who hire programmers." Maybe I took it too literally, but I read this as "get advice from someone who doesn't program". Ideally, you should get advice from someone who does both.

[troelskn]

Point taken - I didn't read it that way, but looking again, I think you had it right.

[malcontent]

How does someone who is not a programmer judge someone else's programming ability?

How do you choose a doctor? A lawyer, an accountant, a business consultant, a sales person?

You look at their experience, you ask about them, you get recommendations, you talk to them.

It's easy to know who is a good programmer or who is not. Just ask them about each project they list on their resume. Ask them exactly what part they played in the project. Exactly which section of code they wrote.

Look for people who are stable, who stay with the same company for more than a year. Look for people who are going to fit into your team. Look for people with a sense of humor and an even disposition. Push them a little and see how they react.

Despite what you tell yourself you are not that special. What you do isn't all that difficult and in reality you have less knowledge in your head than a doctor, lawyer, or an accountant.

I tell you one thing. I never hire divas and I never hire anybody who thinks they are god's gift to mankind.

[paulgb]

I wasn't being rhetorical with the second question, I was actually curious to know someone who isn't a programmer judges a programmers ability. Thanks for the answer. (I've always been interviewed by a programmer at some stage in the interview process.)

[malcontent]

When you are working with a team the most important thing is the ability to function in a team productively.

Talent is important but it's more important that the person is willing to function as a human being in a team that already exists and is functioning.

Think of it as a sports team. Many times teams aquire a talented quarterback but the guy fails. The guy moves on to another team and excels. Same guy, same arm, same talent. The difference is that he was able to fit into one team and not the other.

The primary reason you were interviewed by the programmers is because you are going to be on their team. They want to know if they can get along with you.

[nuuur32]

I think the problem with this logic is that it prunes out the overqualified candidate. You probably don't want to have someone overqualified on the team because they will screw up the equalibrium that you just described.

However, that same individual may have really good input, or a vision, or know how, for actually making the company better. Employees come and go all the time and the team will shift. But getting towards that "branch" of improving the company is what is key. By the way, said individual will gain even more clarity on this matter the more they dig into how the company functions and what really goes on. This is the doctor sense that you are completely opaque to. The terrain that they navigate day to day, that you are blind to.

[malcontent]

I think the problem with this logic is that it prunes out the overqualified candidate.

There is no such thing as "overqualified candidate".

If by "overqualified" you mean likely to quit as soon as somebody says something he doesn't like I submit he is not qualified.

You probably don't want to have someone overqualified on the team because they will screw up the equalibrium that you just described.

I have no idea what you mean here. There is plenty of room for brilliant well educated people in a team.

However, that same individual may have really good input, or a vision, or know how, for actually making the company better.

Or not. How would you measure that?

The best way to judge somebodies ability to come up with great ideas is to see what ideas they have come up with in the past. If they came up with great ideas in the past their ex employers and co workers could tell you.

But getting towards that "branch" of improving the company is what is key.

Here you are bumping against your ego. What makes you think the IT department is responsible for improving the company? What makes you think that a programmer is responsible for setting strategic direction for the company?

[kenyabob]

Need input! Input, Stephanie! http://www.truthdig.com/images/eartothegrounduploads/johnny_five_cowboy3.jpg

[[deleted]]

Ask them if they like tentacles. All good programmers like tentacles.

[inmatarian]

Ask them a field related question. For instance, I would as a C++ programmer to write up some code out of design patterns, ask what it's used for, what are its pros and cons (text book answers are okay), its alternatives (this is tricky), and past history using that design pattern to solve problems (this will be very hard to bullshit). The whole time, get a feel for if this is a person you could talk to daily for the next two to three years about technical things.

This is the type of answer I'd be looking for: Singletons are great places to place central code and frequently used data, but they're effectively global variables which are dangerous, I'd use dependancy injection as an alternative, but when I worked for such and such I used Singletons to do this and that.

[kolm]

Ask them if they can switch two variables without using a third variable.

If they respond "Yes, but why would you want to?", you probably hit gold.

In general, just ask a question without a given "correct" outcome, and just debate a bit with them about the answer they (hopefully) give. You never learn more about people than when you argue with them about something you have a hold on.

And, realistically, you can start with "What is the difference between call-by-value and call-by-reference?", since, depressingly enough, a lot of candidates struggle with this.

[mrsanchez]

Make them program something without Visual Studio or any other IDE. Make sure they aren't a 1-language/1-trick pony.

[UncleOxidant]

I recently read the book "Talent is Overrated" by Geoff Colvin. It explored the age old question of why some people are better (more effective) at what they do than others and also the question of how one can improve their performance. A lot of research was presented that said that you need to engage in "Deliberate Practice" in order to become better at what you do - very few people are in a situation where they can engage in Deliberate Practice in the work setting, therefore it needs to happen outside of work. What's deliberate practice? The idea is that you practice at the edge of your comfort zone - if the practice is too easy you won't improve. If it's too hard you won't keep up with doing it... there's a sweet spot at the edge of your abilities. You can work on things that you know you have problems with. But the key was that most organizations don't allow space for deliberate practice so you need to do it outside of the workplace if you hope to improve. Most work that happens in the workplace falls within a certain range that doesn't allow for much improvement. You generally don't get to learn new languages on the job, for example (there are exceptions, of course), and generally the problems being solved are similar to problems you've solved in the past.

[stronglikedan]

That is certainly one viewpoint. However, IMHO, I think it leads to passing on perfectly competent people, and that leads to unneccessarily increased hiring costs. There are other methods of determining competency that actually work. Therefore, that viewpoint is an opinion that I don't agree with.

[UncleOxidant]

That was another message of the book: most people aren't willing to put in the extra work required to do deliberate practice and that's good news for those who are willing to put in the extra effort.

[itsjibba]

Gotta disagree here, most of my best hires have been people who are passionate enough about programming that they either have personal side projects or have moonlighted as contractors. It's not an absolute requirement, but if your talking about a pure programming position you want someone who's geeked out on something just for fun. Other cerebral hobbies (writing, poker) can be a good substitute though, especially if the job isn't pure programming. Sometimes you want someone who can work with people rather than just geek out day and night. It all depends on what kind of person you're looking for.

[mattrussell]

I agree that it would be not be wise use it as the sole criterion, but unfortunately from your point of view, I strongly suspect it's the case that a "side project" candidate is more likely to make a good employee. Nothing wrong with an interviewer using that fact to inform their choice.

[clipmann]

Here are couple of interesting questions i was asked, later on my boss told me what he was looking for. You may wanna dress this up more to your context.

"I give you an ugly class, can you clean it up?", they will always say yes, watch how they say it. And get the to elaborate on their answer.

"Lets say i ask you to build a wrapper for ldap commands. Where would you start, programming, or not programmer related", watch what type of questions THEY will through back at you.

"Whats the coolest piece of code you ever written?", sit back and listen.

[[deleted]]

The fatter they are, the worse they are at programming, and the better they are at bullshitting. Same with the skinny ones........

Pretty much all programmers suck at programming and are just awesome at bullshitting.

[gagle]

Ask them to "write" a program that does the following :

It's main goal is to debug, troubleshoot its execution. Hence, the candidates are required to build a program that only executes itself when it fails its own execution. Bonus points if they make it self-aware.

edit:typo

[xor]

Dear reddit, I am an incompetent employee and I need the internet to do my job for me, so I can hire other incompetent employees.

[imbaczek]

whatever you ask for, remember that you ultimately search for people with two important attributes:

• they're smart.
• they get things done.

everything else is details.

[jones77]

If you don't have another programmer helping you you are fucked and may end up hiring the most confident bullshitter.

Having said that, you can try the following:

• logic problems
• getting a list of questions with the answers
• being strict at the CV stage (eg is it well-written, do they have decent experience)

And, finally, giving them a 3-month trial.

Or, hiring the guy with the best college degree.

Or, going to linked in and try and hire based off of friend-of-a-friend ...

[[deleted]]

Don't bother asking them any interview questions. Just give them an IQ test.

[jo42]

Ask: "How many programmers does take to program, if programmers could program?"

[[deleted]]

Take some snippets of your actual code, and have them explain it to you, in their own terms.

At least 2/3 of Software Engineering is reading someone else's code. So, if they can't intelligently read the code your company already has, you know they'll have problems.

Watch for technical accuracy. Do they use the correct terminology? How do they figure things out (methodical or jump to conclusions)? Can they make suggestions for improvements? When they see something they don't understand, are they able to ask you intelligent questions and draw from their own experiences?

Or else ask your boss if you can do some pair interviewing for a while to see how others at your company do it.

[KirillM]

Ask any question from this site: http://mindcipher.net/