×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

How Should You Interview a Programmer?

Cliff posted more than 12 years ago | from the aspirant-firing-line dept.

Television 1136

phamlen asks: "Having hired several programmers who haven't worked out, I'm wondering if other people have better success with interviewing techniques. Usually we have a two 'technical interviews' and a final interview. The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility. Unfortunately, we've been burned a couple of times by people whose performance didn't measure up to what we expected from the interviews. So I'm wondering if other people wanted to share their interviewing tricks - how do you find out if someone is a good programmer?" Surprisingly enough, we've done a series of these, so if you are interested in similar questions for sysadmins, network engineers, or the one who will follow in your footsteps, then we've got it covered. We've also covered core IT questions as well. What special ways do you have of evaluating potential coders? How well have they worked out?

Sorry! There are no comments related to the filter you selected.

Word (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#4120942)

Word to your mother

I got it (-1, Troll)

Anonymous Coward | more than 12 years ago | (#4120946)

Tech interview questions techinterview.com or something, problem solving

FP (-1, Troll)

Anonymous Coward | more than 12 years ago | (#4120951)

I usually ask my programmers if they plan on making up lame 'Ask Slashdot' questions in their spare time...

Re:FP (1, Funny)

Anonymous Coward | more than 12 years ago | (#4121063)

Until recently, I would ask for their slasdot ID and then check their karma. I always assumed ability was inversely proportional to slashdot karma.

Good question (4, Insightful)

mr_zorg (259994) | more than 12 years ago | (#4120952)

Unfortunately, I don't have the answer... I tend to look for someone with general problem solving skills, intelligence, and a genuine passion for that they do.

Re:Good question (5, Funny)

unicron (20286) | more than 12 years ago | (#4121054)

How were you able to be so poetic yet completely vague all in one sentence like that?

Re:Good question (5, Funny)

laserjet (170008) | more than 12 years ago | (#4121134)

He just got promoted to management.

A good quesation to ask (1, Interesting)

Anonymous Coward | more than 12 years ago | (#4120954)

Ask them what they consider a productive day.

just out of curiosity (4, Insightful)

AssFace (118098) | more than 12 years ago | (#4120964)

if you are asking them actual questions that have definite single answers - what is to stop them from studying for it?
wouldn't you rather have someone that can think on their feet rather than those that heard from a friend what your interview was like and studied to do well for that interview?

Re:just out of curiosity (1)

morgajel (568462) | more than 12 years ago | (#4120997)

how many technical people do you know that are good at thinking on their feet?

I don't know about you but even the thought of someone doing that to me in an interview freaks me out.

Re:just out of curiosity (1)

ivan256 (17499) | more than 12 years ago | (#4121060)

how many technical people do you know that are good at thinking on their feet?

All the good ones....

Re:just out of curiosity (1)

AssFace (118098) | more than 12 years ago | (#4121061)

LMAO - that was a joke right?

I come from a consulting background, so maybe I have a different view on it.

Riddles... (2, Insightful)

Cryptnotic (154382) | more than 12 years ago | (#4120969)

Ask them a few riddles. For example,

the ones discussed here [slashdot.org]

Re:Riddles... (0)

Anonymous Coward | more than 12 years ago | (#4121096)

Ask them a few riddles.

This happened to me once. I went into an interview where they started to ask riddles. I promptly told them "I am truly sorry. I thought I was being interviewed for a programming job, not a guest spot on Romper Room. I do not appreciate having my time wasted in this manner." After which I stood up and walked out.

All this cutesy bullshit like, "Riddle Me This", "Tell Me a Story" are just inexperienced interviewing techniques of weak minded people who have no real idea what they need.

One simple little function... (3, Interesting)

bloggins02 (468782) | more than 12 years ago | (#4120976)

... the swap function. It may be simple and about three lines long, but you'd be surprised how many people it weeds out who simply don't understand pointers.

And understanding pointers (even if you use non-pointer languages) seems to be a common trait of most "Good Programmers".

Re:One simple little function... (0)

Anonymous Coward | more than 12 years ago | (#4121010)

I can do it on one line of inline asm. Simple load the address of the variables/objects in the registers and use xchg to swap them.

Re:One simple little function... (0)

Anonymous Coward | more than 12 years ago | (#4121098)

Oh come on, that's kind of ridiculous. I'd maybe ask that in a Data Structures class but not in an interview. The interview questions would have to far superecede that question in complexity.

Re:One simple little function... (1)

smileyy (11535) | more than 12 years ago | (#4121112)

The only thing pointers are useful for is implementing whatever programming language i'll actually be using.

Re:One simple little function... (1)

YetAnotherAnonymousC (594097) | more than 12 years ago | (#4121133)

Another one that I find similarly illuminating:
reverse a singly linked list in place
sooooo many people don't even know where to start, or don't understand pointers
many do it recursively, which is fine, but not as efficient as the iterative method.
let's you see how they think on a relatively simple problem, and weeds out the people who are incompetent.
of course, this is only the base of an interview. next step is to determine things like people skills, work ethic, etc. I could write a book on that

Make them sweat (2, Funny)

tjw (27390) | more than 12 years ago | (#4120978)


Q: Which is better vi or emacs?

Re:Make them sweat (1)

perljon (530156) | more than 12 years ago | (#4121077)

Easy... whichever one you're most productive in.

Here's an idea. (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#4120979)

i saw one for microsoft in the news paper the other day, it had a nice function and it asked how to improve upon it and make it more efficient.

If you interview potential employees. (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#4120984)

If you hire an programmer, make sure he hasn't any background in open source. It's extremely risky to hire them despite many talented people.

We all know that people are doing open source for all kind of different reasons but there are a substansial part that sees it as their mission in life to clone commercial project and drive commercial companies out of business.

It has happen quite a few times that open source programmers clone the projects their employeer hire them to work on just for the cause of killing it.

Re:If you interview potential employees. (0)

Anonymous Coward | more than 12 years ago | (#4121016)

According to the recent open source study published here on slashdot over 30% of all open source programmers don't think propietary software should exist.

So the risk is quite high.

Hello World (1)

Aknaton (528294) | more than 12 years ago | (#4120985)

Make them produce an error free "Hello World" program. What else could you possibly need to know?

How Should You Interview a Programmer? (1, Flamebait)

The Iconoclast (24795) | more than 12 years ago | (#4120986)

Using small words, so that they can understand.

AHAHAHAHAHAHAHAHA!!!!!! ;-P

Re:How Should You Interview a Programmer? (2, Funny)

SDF-7 (556604) | more than 12 years ago | (#4121101)

Unless you need an IPF programmer...

then you use Very Long Interview Words.

heads up y'all (0)

Anonymous Coward | more than 12 years ago | (#4120987)

You can be sure every programmer who comes here is going to use this as a cheat sheet for their next interview.

Re:heads up y'all (0)

Anonymous Coward | more than 12 years ago | (#4121020)

Yeah, as if hiring managers (people of responsibility) read slashdot.

You should ask them this: (0)

Anonymous Coward | more than 12 years ago | (#4120988)

Do you like this man [goatse.cx] ?

My experiences (4, Interesting)

IIRCAFAIKIANAL (572786) | more than 12 years ago | (#4120990)

When I applied for my current programming job, they gave me a barrage of tests and compiled an aptitude and personality profile of me.

It was really freaky how accurately it described me... the main point was to evaluate me with reference to the type of person that excels at my job (Programmer/Analyst with some support duties)

They also asked for source code I had written and numerous references.

THe problem with an interview is it's too easy to bullshit. You need to go beyond the interview, as my current employers did.

Re:My experiences (0)

Anonymous Coward | more than 12 years ago | (#4121062)

Of course you may have also got the job because you're the only person who endured their demands. And if other people did endure, think of how much time they wasted . . .

ask them to pick a number (4, Funny)

KirkH (148427) | more than 12 years ago | (#4120992)

...if they answer "42", then hire them.

Re:ask them to pick a number (-1)

CmdrTaco (troll) (578383) | more than 12 years ago | (#4121079)

that would only prove that they were some geek who would probably spend his days quoting monty python and the like.

Hire only people you know (2, Insightful)

mikki_m (322215) | more than 12 years ago | (#4120994)

You cannot go wrong, when you either only hire people you know or hire people, that are recommended by someone you know to be a worthy developer. If you don't get enough people this way, you can always ask the candidate if there is someone who can recommend them.

Re:Hire only people you know (0)

Anonymous Coward | more than 12 years ago | (#4121130)

Aren't there general ethical guidelines that recommend against this regardless if you know that they are good?

Check there referances (1)

oliverthered (187439) | more than 12 years ago | (#4120995)


Have you contributed to any open-source projects?

If yes, then take a look at there work.

Re:Check there referances (3, Interesting)

Camulus (578128) | more than 12 years ago | (#4121088)

I have to agree whole heartedly. One of the nice things about programmers is that you don't have to guess whether they are good or not. You can look at their code or ask them to interpret some that your team has already created and critic it to see if they code in similar ways etc. Since it sounds like you are employeeing multiple programmers. Have one of them sit in with the guy and talk shop, work on functions, etc. If your guys are good programmers, they should have a pretty good BS detector. Artists have portfolios, why shouldn't programmers (PDA's aside).

Re:Check there referances (0)

Anonymous Coward | more than 12 years ago | (#4121105)

Apparently spelling and grammar aren't terribly important in your current job.

It's "THIER", DIPSHIT! (-1, Redundant)

Anonymous Coward | more than 12 years ago | (#4121132)

Reading your posts is like dying.

Re:Check there referances (0)

Anonymous Coward | more than 12 years ago | (#4121135)

If yes, then take a look at there work.

Have them write the above line, if they used "there" instead of "their" return them to the minors.

Find missing number 1-10 (0)

Anonymous Coward | more than 12 years ago | (#4120996)

Add the numbers an -55. Tada!

The ultimate way. (2, Insightful)

unicron (20286) | more than 12 years ago | (#4120998)

Remember, the worse he looks, the smarter he is.

Re:The ultimate way. (1)

eMilkshake (131623) | more than 12 years ago | (#4121118)

Looks? The worse he smells, the better he codes!

My Mommy? (4, Funny)

Master Bait (115103) | more than 12 years ago | (#4121000)

I was interviewed at Adobe Systems a long time ago, and one of the people asked me if I liked my mother.

Hire the programmer on a temporary basis (3, Interesting)

CrazyJim0 (324487) | more than 12 years ago | (#4121003)

Give them a real project that will take a week or a month to complete. If they do well, offer them a full time position.

Odd questions (2)

bsDaemon (87307) | more than 12 years ago | (#4121004)

when I interviewed here, they asked me stuff like, if i owned weapons and would i attempt to sabatoge the CEBAF accelerator. apparantly they got "bad vibes" off of me. they hired me anyway. Go figure.

performance not measuring up? (3, Funny)

Jucius Maximus (229128) | more than 12 years ago | (#4121008)

Were they reading slashdot at work when they should have been programming? I think that this could have been a drain on productivity and perhaps justification for you to discipline them because [...] uh, wait a sec a minute ...

/me closes the browser window

Re:performance not measuring up? (2)

Jucius Maximus (229128) | more than 12 years ago | (#4121039)

"Unfortunately, we've been burned a couple of times by people whose performance didn't measure up to what we expected from the interviews. So I'm wondering if other people wanted to share their interviewing tricks - how do you find out if someone is a good programmer?"

By 'performance not measuring up,' do you mean that they simply did not know how to build what you wanted to build? Were they not fast enough? Did they not build stuff according to your specifications?

Please explain how you determined that they were not 'measuring up to standards' !

Show me the money.... (5, Insightful)

PGillingwater (72739) | more than 12 years ago | (#4121009)

Well, as someone who has programmed since 1972, and who regularly hires programmers, I recommend the following:

Ask them if they write code as a hobby

What Open Source projects have they contributed to?

Ask them to bring some samples of source code they've written, and then do a walk-through

Ask them to solve a simple exercise with pseudo-code, then explain which language they would choose to implement it and why

Get them to find a known bug in some code that matches your "house style" (describe the unintended behavior)

Talk to their previous associates and boss....

YMMV....

Get them to code... (2, Interesting)

cjustus (601772) | more than 12 years ago | (#4121013)

Sit them at a computer and get them to code... I haven't been there recently, but www.topcoder.com [topcoder.com] had an excellent setup with "practice rooms" - past problems that could be solved in under an hour...

so, you have two condoms... (1)

tiedyejeremy (559815) | more than 12 years ago | (#4121014)

"A man would like to have safe sex with three women, any of whom may be carrying an STD. Given two condoms, how can he do so, while ensuring that no STD is passed from one woman (or possibly himself) to another (or to himself)?"

Re:so, you have two condoms... (2)

wackybrit (321117) | more than 12 years ago | (#4121081)

"A man would like to have safe sex with three women ...

Yep, and you'll know if you have a good programmer on your hands, because his answer will be:

Huh, what's sex?

What is a "good programmer"? (5, Insightful)

TheConfusedOne (442158) | more than 12 years ago | (#4121015)

Here's the real thrust of your problem. You need to define a "good programmer" then you can interview for it.

There are, of course, a whole range of programmers from the code pounder to the system architect. Are you looking for someone who will produce tight code from a very well defined set of specifications? Are you looking for someone who can take a general "we'd kinda like this" and create code?

How were you "burned" the previous times? Did the interviewee misrepresent themself or did the project turn out to be different then what you were trying to fit the person into?

Another thing to remember when interviewing potential candidates is to look at your current staff and see if you can promote one from inside. That way you can interview for a more entry-level/well-defined position and increase morale by advancing your current employees.

Try to focus on the actual job, not your ego (0)

Anonymous Coward | more than 12 years ago | (#4121017)

I've seen many a programmer who look for the most obscure questions just to blank the candidate. Anyone can find an obscure issue to trip up almost any candidate.

The problem is, you end up chewing through good candidates and taking one that isn't as good later on when you are desperate.

What do you want to hear? (3, Interesting)

perrin5 (38802) | more than 12 years ago | (#4121019)

The interview process is a TERRIBLE way to hire anyone. Unfortunately, it's also pretty much the best way. (I will allow others to argue the logical consistency of the above two statements) I would consider myself an excellent employee, and barring the occasional "brain break" of playing a computer game or two, I think I'm pretty productive. The problem is I am a terrible interviewer.

My personal opinion of interviews is that you should be interested in 2 things:
1) do they know what you want them to? and
2) are they good workers.

The problem is that people try to add any of these criteria:
3) do you LIKE them?
4) Are they professional enough?
5) do they fit into the corporate image?
6) will they stick around?

None of which are useful for hiring employees. Sure you may not want to invite them to the company picnic, but man can they crank out the work.

I would also like to point out that "productivity" is overrated, unless you are ranking on a scale normalized for "quality" of program (quick scale = lines of code/errors found later)

just my rant for the day.

easy (5, Funny)

Casca (4032) | more than 12 years ago | (#4121023)

Interviewer: Who won the superbowl last year?

Programmer:

Interviewer: What do you do for fun outside of work?

Programmer:

Interviewer: Hmm. What do you look for in a woman?

Programmer:

Interviewer: Great then, one last thing we need to check...

Programmer:

Interviewer: Ok then, see you Monday.

Referrals (1)

cliveland (603210) | more than 12 years ago | (#4121028)

Referrals from your best developers.

I Am Confused (1)

LordYUK (552359) | more than 12 years ago | (#4121030)

"'Given the numbers from 1-10 missing one number, how do you find the missing number?'"

lets examine this question here. If I give you the number's 1-10, minus a SINGLE number, then how difficult is it to FIND THE MISSING NUMBER? maybe thats why you get burned, you're asking silly questions.

Go Figure

Re:I Am Confused (1)

beerman2k (521609) | more than 12 years ago | (#4121082)

Yes this is terrible interview question.

Balanced binary trees... (2)

Cryptnotic (154382) | more than 12 years ago | (#4121038)

Ask them when they would implement a balanced binary tree as part of a solution to a problem. The correct answer is "never". You would never want to implement one, since it is so much of a pain in the ass and is so prone to error. In the real world, when you want a balanced binary tree you use someone else's implementation (e.g., STL). Any programmer who would implement one himself is likely to waste too much of your time and money.

Interviewing Programmers 101 (5, Interesting)

wackybrit (321117) | more than 12 years ago | (#4121041)

The original posters questions and theories are a little weak. Testing a programmer's skills in constructing algorithms for random scenarios is a great idea.. if they need to use lots of algorithms.

The key to interviewing is to scope out the person's general work ethic, overall personality, and how well the person can do the job they have applied for. That's it!

In previous Slashdot threads we have learned that it's not wise to sit programmers down with a pen and paper and get them to write C code on the fly! Yet... the interview techniques you are mentioning are a lot like that.

Getting people to 'think on their feet' is good, if you're just talking concepts and ideas, but don't expect people to get things 100% right sitting at an interview table. These guys are programmers, not TV evangelists with all of the answers at the tip of a hat.

From the sound of your post it seems like you have interviewed people, found them to be great at algorithms and answering your questions, but then have found their work ethic stinks or that they're not as ingenious as you thought they were. That's because you assume that someone who can answer questions quickly and proficiently is a good programmer. Wrong!

Instead, look out for programmers who list extra-cirrucular projects on their resume. Look for programmers who have worked on their own projects, and can demonstrate them for you. Would you rather employ someone who coded a great deal of Gecko, or some gimp who can answer your algorithm questions?

Look for people who don't need incentives to work, but those who will program whether they get paid or not! Those are the people who will stick with you, and aren't just learning new languages to make a quick buck.

New Slashdot Section? (5, Insightful)

JTFritz (15573) | more than 12 years ago | (#4121043)

It seems that we have a collection of these articles and comments in our little community. CmdrTaco, why not put together a new section with a theme of Technical Recruitment.

Perhaps this new section could include these helpful questions and resources following the current re-education and recruitment techniques of the industry.


Any thoughts?

You shouldn't. (5, Funny)

foxtrot (14140) | more than 12 years ago | (#4121047)

If you're interviewing the programmer, you somehow got pushed up to management and are screwed already. :)

-JDF

Re:You shouldn't. (5, Funny)

unicron (20286) | more than 12 years ago | (#4121095)

I would go the arrogant route in that position:

Manager: Where do you see yourself in 10 years?

Programmer: On the other side of this desk, Bob.

Ask them what they really, really hate (0)

Anonymous Coward | more than 12 years ago | (#4121050)

You'll find out sooner or later anyway, and many techies are best defined by what they simply can't put up with. Might as well prepare for it.

How many fingers am I holding up? (1)

titonutz (558355) | more than 12 years ago | (#4121055)

This question tests the candidate's basic ability to discern solid objects in space, as well as their ability to follow directions. To correctly solve the problem, the candidate must be able to use their built-in senses of vision (or touch) to ascertain what parts of your hand can be defined as finger-like appendages, and then to count (starting at 1) the total number of "fingers" you have extended from your otherwise-closed fist. Off-by-one errors are unacceptable.

Laugh all you want, but it really works!

Joel's got help (2, Informative)

Arjen (52387) | more than 12 years ago | (#4121056)

Joel (of Joel on Software [joelonsoftware.com] fame) has an interesting article [joelonsoftware.com] about interviewing, entitled The Guerrilla Guide to Interviewing. The name is self-explanatory, I guess.

Hiring a programmer (2, Insightful)

2names (531755) | more than 12 years ago | (#4121058)

I can tell you one way you absolutely SHOULDN'T interview a programmer:

"Here's a piece of paper. Write me a program that does ."

I actually had a guy do this to me. I'm a very good programmer, but I don't keep syntax of every language I've ever used in my head, that's what REFERENCE BOOKS are for.

Find someone who understands logic, flow, analysis, etc. and is also good with people and you will have found yourself an excellent programmer. Getting hung up on syntax memorization is retarded.

Easy Solution... (1)

V_drive (522339) | more than 12 years ago | (#4121059)

Solution is easy! Hire me! C/C++/Java

Resume:
http://danwoods.linkedresources.com/ind ex_files/re sume.pdf

ask them.... (1)

ender-iii (161623) | more than 12 years ago | (#4121066)

Ask them if they are a virgin and then convince them that they are.

Opener (2)

Picass0 (147474) | more than 12 years ago | (#4121067)

You start off with "Can I get you a soda or something with caffeine?"

Technical questions are irrelevant (5, Funny)

JMZero (449047) | more than 12 years ago | (#4121069)

..for the most part. Most programmers with some sort of qualification can get your jobs done, unless your jobs require some amazing degree of skill. I probably couldn't write you out a bug free Quicksort first try, but I could certainly implement it in a real project.

And to be honest, most projects don't require skills nearly that nebulous. How many projects today are: get the data off the screen, validate it, then create the invoice.

The bigger question is whether they'll actually work hard on their jobs, or just play on SlashDot all day. And I don't know how to interview for that (and obviously neither do my employers).

.

Give them a project. (2)

laserjet (170008) | more than 12 years ago | (#4121071)

I would have them come in and instead of doing a technical interview, have a small project that they should be able to complete in a few hours.

Then sit them in a room with just an internet connection and a linux box. See if they can install their compiler of choice, get everything working, and begin coding. Best man wins.

Were you born in September? (2, Funny)

T1girl (213375) | more than 12 years ago | (#4121073)

Our 18-member team likes to have birthday parties every month, and we've got every month covered except September, so we've asked management to make sure our next hire has a September birthday.

Our interview process (4, Interesting)

Darth Maul (19860) | more than 12 years ago | (#4121075)

At my company, since we're small, we need to know that new developers will click quickly. We do a technical paper exam (one hour) with some standard programming/algorithm questions. We then do a few riddles and logic puzzles. These are the best way to test raw intelligence, IMHO, since you have to think abstractly and quickly. We then do a few more design questions at a white board to test their skills at high-level design and diagrams.

However, the one thing that is difficult to test but really seems to be the deciding factor of a new hire "working out" or not, is whether or not they have the "passion". One way we try to determine their take on programming (just a job vs. a fun hobby) is to ask them to describe one software project that they have developed on their own time (not on the job or necessarily part of schoolwork). It's amazing how few actually code for fun or just to continue the learning process.

We then ask them what their favorite joke is just to jolt them a bit and see if they have a sense of humor. Most people fail this question, unfortunately ;-).

Simple (0)

Anonymous Coward | more than 12 years ago | (#4121083)

Ask for a sample of their source, say 300-1000 lines min. and a few example apps of what they've written in the past.

Your own 'good' programmer should be able to tell you how compedent he/she is.

BTW any Goto's... send 'em back to microsoft!

Stretch their minds... (1)

Dr_Harm (529148) | more than 12 years ago | (#4121085)

I generally interview with in three parts:
  1. Simple HR-like questions (i.e. how do you handle deadlines, etc).
  2. Simple-to-moderate technical questions (i.e. why is it important to use parens in a #define)
  3. Brainteasers
It's the brainteasers that's where the 'okay' and the 'excellent' really differentiate themselves. The questions I ask have solutions... they take the typical person several days to work out. But I'm not interested in the answers, I just want to see how they think and attack the problem -- can they see the blind alleys? can they recognize when they don't have enough information? what sort of questions do they ask?

Occasionally, I throw a curveball. "I see you have experience with the PPC architecture. What's your favorite PPC instruction?" You'd be suprised how many people answer that with "eieio, because it sounds funny". Which isn't a bad answer -- I wanted to see how they reacted to an unexpected question. Another candidate told me once that (for the ARM platform) the bit-invert function was good for writing highly-optimized bit-manipulation functions for banging away at hardware registers.

Through all of this, tho, you need to keep in mind their personality. Will they play well with the rest of the team? That's a difficult factor to judge, and I'm likely to cut a candidate some slack on this.

soft questions and references (1)

dcocos (128532) | more than 12 years ago | (#4121086)

Ask questions about problems you've run into while working with the lang but not nessecarily related related to the syntax or structure of the lang (ie classpath problems with Java or connection errors with databases)

Most of these are pretty easy to setup a test for on your computer which you should have them use to trouble shoot during the interview.

The other thing you should do is check with their past managers. Make sure that they've actually worked where they said they did and they did what they've said they've done.

And finally look for their name on google!

Don't ask those technical questsions. (1)

crazney (194622) | more than 12 years ago | (#4121087)

By the sound of the questions you ask, alot of good coders would probably screw them up in the heat.

I know I could probably screw them up quite easily.

why? Because with those questions your testing invterview skills, not programing skills. I'm a shy and nervice guy, as such in an interview I'd likely get paranoid and worried and just blunder everywhere (and probably try to answer too quickly). Even though I know the answer.
Someone who is good at being interviewed would take it calmly and answer calmly, correctly.

And as you probably know, most good programing geeks arn't exactly totally out there and self confident.

What you want to do is two things:
a) Look at their previous work. What projects have they worked on, what have they done personally in there own time. Ask them to submit any work they can do.
b) Make them feel comfortable and then ask them technical questions, but in a chatty way so they don't feel pressured, it shouldn't be a Q&A type session.

Disclamer: I've never interviewed people or been interviewed. But I am a programer, and have had two jobs as one (one I'm in now).

Cheers
David.

Does contributing to open source projects help? (2, Interesting)

Mastos (448544) | more than 12 years ago | (#4121090)

One of the reasons I contribute to open source projects is to learn something new that will perhaps be needed for a future job. In the interview for that job, I would think that being able to point to source code that is in production, so to speak, would be a tremendous advantage. Has this been the case for anyone? Has anyone gotten a job primarily due to related open source contributions?

For a real look at their personality... (2, Interesting)

perfects (598301) | more than 12 years ago | (#4121092)

...casually ask them where they post. Then ask them what their User Name is. Then go read what they have written.

Not only will a handle like LuvWarez or MyBossSux tell you a lot, but I suspect that over time a person's SlashDot messages (for example) are a good indicator of their real personality and attitudes. And intelligence. And sense of humor.

Check their grasp of reality. (5, Funny)

Kenja (541830) | more than 12 years ago | (#4121093)

Based on some psycho developers I've worked with, I would recommend checking their grasp of reality in the interview.

Some example questions would be.

Which compiler do you prefer?
  1. GCC
  2. Visual Studio
  3. Small furry rodents are chewing my eyes out from the inside
  4. Metrowerks

Complete the sequence. 2, 4, 8, 16, 32, 64
  1. 128
  2. 256
  3. 512

Are the voices in your head loud enough to disturb your coworkers?
  1. Yes
  2. No
  3. How do you know about the voices?
  4. What voices?

here's how (1)

PanBanger (465405) | more than 12 years ago | (#4121097)

give them a piece of paper with the word "Slashdot" on it. If they pull out a pen and scribble "first post" at the bottom of the page, don't hire them.

Repeatly tasks (2)

famazza (398147) | more than 12 years ago | (#4121103)

Ask him/her to do something repatly, if he organizes a way to do it faster, or to do it easier then just repeating each time a different way, the he/she is a good programmer. ;o)

Ask about quality (2)

matsh (30900) | more than 12 years ago | (#4121104)

I think this is a good question:

How do *YOU* make sure the code you write is of good quality.

The answer must involve a discussion on what characterizes good code, *AND* how this particular person gets his/her code to that goal.

It should reveal if the person doesn't understand what quality is, and/or if they have no idea how quality code gets written. A good programmer needs to know both these things.

It is a really hard question, and I think it would be pretty obvious if you try to bullshit yourself around it.

Mats

for fun projects! (2)

drenehtsral (29789) | more than 12 years ago | (#4121106)

Ask them about their for-fun projects. This will break the ice, and give you an idea for their level of geeky enthusiasm for programming. It will also give you a look at how they approach problems, and will give you a good buzzword-free handle on the sort of thing they are good at.

If you task a programmer with things similar in nature and challege level as the stuff they are doing for fun on their own time, you'll have a better fit to their skills. A programmer knows what they can do, and they will use everything they've got on their own projects. A programmer with no projects of their own probably lacks design skills and is more of a coder than a programmer.

It may help to point out that you're not asking this so as to steal away the projects, but rather to gain a better/wider picture of one's experience.

(I work as a programmer for perspective information).

Standardized testing across the board? (0)

Xuli (98764) | more than 12 years ago | (#4121108)

I recently started work for a small comany that has a pretty solid core staff of people that have an average tenure of about 5 years. As part of my interviewing process, I was introduced to a standardized test [caliperonline.com] that one of the executives had recently learned about, taken, and felt was an excellent measure of an individual's professional and personal fit in the organization.

While I don't tend to put much stock in most standardlized testing [collegeboard.com] , I am currently sitting at my desk at said employer and must, therefore, acknowledge that the process played some part in my receiving an offer.

The push now is to apply the test to everyone in the organization, to pick out common themes of people who've been part of this company for some time.

While I'm not sure this would have any bearing on assessing someone's performance in a technical role (there are some reasoning aspects to the test) it will help to ensure that there is a sanity check as to who is a good fit moving forward.

Perhaps this is one way to address the issue, as someone who gets along with peers and can relate to them, is more likely and willing to mold into the culture of the organization.

ask them about the mailing lists they read (0)

Anonymous Coward | more than 12 years ago | (#4121109)

One of the best phone-interview questions I was ever asked was "what mailing lists are you on?"

idea (2)

Tebriel (192168) | more than 12 years ago | (#4121117)

Ask them how much they've done in the past 3 months to improve their skills. If they say nothing, show them the door. A good programmer is always looking to expand their skillset in some way.

Everyone's favorite: logic puzzles (0)

reyalsnogard (595701) | more than 12 years ago | (#4121121)

Much to a lot of interviewee chagrin, I advocate the employment of logical puzzles as part of the interviewing process. By throwing the 'technically-inclined' candidate a logical problem, and asking for thoughts aloud, the interviewer can test the applicant's ability to formulate correct assumptions, heuristically test solutions, and explain their reasoning/rationale.

.. and if those aren't valid points, every interviewer should have some lithe trick up their sleeve to make the interviewee squirm. =)

For those who may have missed it the first time it was /.'d, there exists an expansive collection of riddles/logic puzzles/etc. at http://www.ocf.berkeley.edu/~wwu/riddles/intro.sht ml

Questions... (2)

wilburdg (178573) | more than 12 years ago | (#4121122)

To find out if he is a real programmer you need to ask questions like:
  • Do you have a girlfriend?
  • What did you do last friday night?
  • If you had $10,000 what would you blow it on?
  • What is your slashdot karma rating?
  • Can you wear sandals with a suit and tie?
  • Name 17 cafenated beverages
  • And last but not least: What is the airspeed velocity of an unlaiden swallow? (I actually had someone ask me that once)

Ask for percentages (2)

totallygeek (263191) | more than 12 years ago | (#4121127)

Ask them to break out in percentages where they have learned most of their programming:

  • In school
  • On the job
  • At home

Pick the one with the highest percentage At home.


This is such a tough thing to do. I understand why there are the strange creative-thinking or logic problems offered-up to applicants (How many bricks would you guess there are in this building? How many gas stations are there in Florida? Using a 5 gallon bucket and a 3 gallon bucket, give me four gallons of water -- not sure the wording on this one). I have never been very good at logic problems like Brad has on a green shirt and is sitting next to a woman; Mindy is wearing a blue shirt and is sitting beside someone wearing a purple shirt; what color shirt is Tracy wearing? I would have never made it on the LSAT test for law school. Of course, I have never claimed to be a great programmer or anyone dedicated to reading enough to be an attorney.


Good luck in your hirings! At least it sounds like you can get rid of staff if they don't work out. I have seen terrible people get to sit on the job endlessly because the company fears firing anyone from the liabilities. I have worked with a CNE (Novell Netware certification) that had never built a Netware server, didn't know how to create/manage print queues, and could not figure out Groupwise or Netware Connect. I have worked with some "Linux experts" that didn't know what an inittab was for, could not install Linux, and were totally clueless when it came to installing software. I have also worked with programmers that used all global variables, did not put things into separate, clear functions (500+ lines of c in main() ), and couldn't figure out how to do anything from scratch. They all got to sit around while someone else (me usually) covered for them!

Working through a problem (1)

SuperMallen (156287) | more than 12 years ago | (#4121131)

One the best techniques I've used (or had used upon me) is to pose a general problem, maybe even one you've encountered before on this project, and see how the candidate addresses it.

The trick I've found with these sorts of questions is to pose it very broadly at first ("This piece of the application goes slow. What do you do to make it go faster?") Then see what kind of questions they ask you. ("How is this piece configured? Have timing measurements been taken?") What they ask you can reveal much more about their thinking processes than any puzzle-type questions you ask them.

Beyond that, identify the three or four key skills that will be needed for the position, then come up with two sets of questions for each: a normal set and a mean set. The normal set should contain questions that any programmer with a reasonable amount of experience should be able to answer. (For example, a Java question might be "Why would I decide to use an inner class?") Then you can ask mean questions to see how far their depth goes ("You can't use the keyword synchronized on a static method. Why?")

Always always always get them to talk about a past project. Drill into their knowledge and find out exactly what they did.

Riddles (2)

DeadSea (69598) | more than 12 years ago | (#4121137)

Three years ago, as I left college, I interviewed with about sixty companies. Most asked some programming questions, and some kind of riddle. You know the kind of stuff:
If you have a cabbage, a goat, and a wolf, how do you get all three accross the river without the wolf eating the goat, or the goat eating the cabbage given that your boat can only carry you and one other item.

(You of course have to take the goat, come back for the cabbage, take the goat back, bring the wolf, then retrieve the goat one more time.)

I don't know if these actually show anything, but they were popular, I probably got asked 30 distinct riddles.

For programming questions I tend to ask high stress problem. Such a problem has a simple solution, but it is non-obvious, and puts people in a time crunch. One such problem I would use is find a regular expression that you can put into the search box of your text editor to find the first c-style comment (no "\/\*[^]*\*\/", and "\/\*.*\*\/" don't work, although they are the most common first answers). Things that I've run across that were harder than I thought they would be or have elegant solutions that I didn't think of right away. I have several from my college classes where the professor presented something and the whole class gasped, and said, "Why didn't I think of that?".

Story about a guy at work (5, Funny)

The Wing Lover (106357) | more than 12 years ago | (#4121138)

Work was interviewing somebody for a non-technical position. However, he had put on his resume that he knew HTML. The company's president (we're really small), who was interviewing him, quickly came to the conclusion that he didn't know a thing about HTML, but he wanted to see the guy sweat. So he said, "Here's my computer; I'll be back in 10 minutes. I want to see a web page".

Well, 10 minutes later, the president came back in the room, and there was a web browser displaying his creation -- a single sentence, "Hi Tim, I wrote a web page" in bold and italics. Up on the screen were other web browsers containing internet searches about basic HTML, as well as the output of "view source" from one of our web pages.

Three years later, this guy is still with us, by far the best customer service manager we've ever had.

I guess the point is, give the person a puzzle that you know that they have no idea how to solve, and give them the resources to figure out how to solve it, and see what they do.

Asking the wrong questions (2, Insightful)

leibnizme (264472) | more than 12 years ago | (#4121139)

The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility.

"Is friendship inherited?" is just a bad interview question. Are you looking for specific programming languge knowledge, or the knowledge to search for answers? "How would you find out?" indicates the latter. Phrase the question accordingly: "If you wanted to brush up on friend classes, where would you turn?"

Depending upon the skill set you're seeking, algorthimic questions should be of an appropriate level of difficulty. "Given 1-10, with one missing..." is a question my mother could answer without any knowledge of computer science. If you want to check for algorithmic understanding, pose a graph problem. They're easy to visualize and easy to describe. You should get some stock answers like Dijkstra's or BFS or Kruskal's... Then ask for the person's own algorithm to see how he reasons through the problem and modifies his approach. This helps test for intelligence and flexibility in thinking.

As for testing team skills, pose both hypothetical questions and real-life questions. "What would you do if a person in your team was not pulling his weight in a project?" "Describe a time in your life when teamwork was essential. What were some problems you encountered?"

In general, the best thing you can do is force the person to talk. Not just simple, short technical answers, but stories and long "essay" answers. You shouldn't ask specific details about C++ ("In a switch() statement, how you specify the default case?") but general questions ("When would you use a switch() statement?"). Of course, you would want to ask harder questions, but you get the idea.

The best interview I had was with the CIA (Central Intelligence Agency). Did they care about my technical skills? No. They had my resume and my transcript. Every question got me talking about myself. "Tell me about a time you failed" separates the men from the boys. And you get a good sense of who this person is... which is the goal you're really seeking.

Ask him to perform a common task... (0)

Anonymous Coward | more than 12 years ago | (#4121141)

"Given $600, an electrical outlet, a T1 line and 5 hours, build the best server you can."

If he comes back to you with a kick-ass Linux box, hire him. If he comes back with a Windows box, tell him you'll let him know. Then hand the box to the next candidate and say:

"Given this computer, a T1 line and 5 hours, build the best server you can."

Repeat.

Hire people you know (2)

Wee (17189) | more than 12 years ago | (#4121142)

how do you find out if someone is a good programmer?

This may sound trite, but I've seen it happen successfully over and over in the past three years the tech world has been languishing: Hire people you've known professionally. There are a lot of folks that got tech jobs due to the dotcom expansion who would have otherwise not had that exposure. The VC money was just phosphorus for the tech algae bloom, though. Now the colony if is dying off, and the strongest ones survive. Trouble is, some of the weaker ones can fool you into think that they are really strong ones. The only good way past this is first- (or even second-) hand knowledge about the person you're hiring.

It's common knowledge that the the job boards (Monster, Dice, et al.) are completely useless and that the only way to get a tech job is to get a referral/offer from someone you already know. So it stands to reason that the people who are looking for work either don't know anyone else professionally (not a good sign) or they know people professionally, but those people either can't or won't hire them. You can't tell the difference between them all from one interview/phone screen.

Interviews are like references: they can be as useful as the interviewee is honest. But the best way to hire good people is to hire people whom you know are good. Failing that, hire someone as a temp, on spec, for a probationary period, etc. If they work out, then hire them full time. There are a lot of very talented people out of work, and it's something of a buyer's market. If you have a decent position open, then many people will put up with being a temp in order to secure the permanent job.

-B

behvioral interviews (1)

mitchner (524884) | more than 12 years ago | (#4121145)

My company gave all techies a good training class on an interview style called behavioral interviewing.

Traditionally, interviewers would ask clever questions requiring the candidate to think on their feet. Of course, if the candidate has heard that question before, they will slam-dunk the answer regardless of their intelligence/ability. From earlier stories, lots of /.'ers follow this approach. The main problem with this approach is being able to quickly answer a handful of difficult questions in an interview doesn't mean that person will write good code day in and day out or be a good employee. IMHO, it measures interviewing ability more than the ability to get work done.

The other approach is to ask the candidate what they've done and how they did it.
  • Describe the design patterns you used on your last project
  • Describe a difficult algorithm you had to write recently and how you wrote it.
  • Describe a problem you had on your last project and how you solved it.
  • Describe your role on your project team.
  • etc...
Then, take their answer and drill into more details on it. Try to understand their process of working and solving problems on a real project.
I think this approach works well.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?