Fog Creek Software
Discussion Board

Interview Technique

A co-worker of mine is co-interviewing prospective coders. The other interviewer is non-technical. My co-worker (a coder) plans to give the candidate half a day to complete a task that should take one day - just to see how they cope with the stress. This seems to be his idea of how to measure a person's technical abilities.

Personally I think it's the stupidest idea I've ever heard. No-one produces decent code under stress like that. Any decent coder will think that we're just another dumbass web company that cares more about lines of code than quality.

Any comments? Hopefully this will dig up with a list of reasons why it's a bad idea and what would be a better idea. Then I can send him the url to this discussion.

Not The American President
Wednesday, January 14, 2004

I'm not one of those people who think technical interviews should have no technical questions, but you're right; this is about the dumbest thing I've ever heard of interview-wise. 

Yes, the job market is pretty good for employers right now, but not *that* good.  All of the worthwhile developers they get to the interview stage will pass on the company, most walking out the door midway through the interview. 

The process you're describing throws up a huge red flag that says: "You'll be working for a code sweatshop where we don't properly schedule anything and you'll be expected to have no life outside of work to deal with our mismanagement." 

Mister Fancypants
Wednesday, January 14, 2004

Hmmmm.  I keep harping on that out of context technical 'challenge me' kinds of questions are largely a waste of time.  The mistake is in the belief that software development, even where its considered a coding job, is about coding. It isn't, its actually the smallest component.

Coding is the final, iterative process.  Its more important to detect the quality of thought than it is the ability to compose syntactically correct lines of code under test conditions.

There are, I guess, logical puzzles that can show some of the qualities of how people think but this again fails to be useful because the kinds of thought we need aren't just about logic problems.

Alternatively, I'd recommend having a collaborative conversation about the project or kinds of project that the candidate would be involved in.  Pick a specific real project, describe the basic requirements, some of the governing factors, they might be cost, they might be timescale or whatever and encourage the candidate to speculate on how he/she might approach some of those problems, fit together solutions.

If there's a specific knotty problem then discuss that.  Note, this isn't free consultancy (though if I'm seeing a client for the first time its likely to be exactly that), you aren't expecting to take whatever is discussed and just implement it.  Its a way of measuring their technical knowledge, their experience, their confidence, their ability to communicate their ideas and so on.

Now for those that might say, but this is overkill I just want someone that knows ASP or VB, WebSphere, because that's what I need, someone that can just start day one and I don't have to train or get up to speed; I'd say this.

Are you hiring a resource for a specific project for a specific timescale, or are you hiring a resource that will be a positive benefit to the organisation and that will develop and give greater benefits in the long term?

If its the former, outsource it, bring in an outside contractor  or hire temporary staff because you aren't looking for an employee you're looking for a tool to do a job and its much cheaper.

If its the latter then any time spent at the beginning coming up to speed (and if you pick the right person that will be much less anyway), will be laughably cheap in relation to how much they'll contribute over all.

This same criterion can be applied to an organisation's hiring policy at any level and for any kind of job, not just software development. 

Simon Lucy
Wednesday, January 14, 2004

A colleague of mine went to an interview with a company.

The interviewer said something like:

"We don't have exagerated demands. We understand that you can't program faster than you can type."

One of the dumbest things I ever heard...

Wednesday, January 14, 2004

There's a factor of 10 difference in speed between the best and worst programmers. Now anyone who sets the test above is unlikely to be the best, so let's assume the best programmers are twice as good as the test setter.

What happens when one of your interviewies calmly completes the task in the time alloted and wonders what the fuss is about?

Mr Jack
Wednesday, January 14, 2004

Factor of only 10?  I have seen BAD programmers, and I am nowhere near the best, but I am probably a factor of 100 times better than they are performance-wise.

Wednesday, January 14, 2004

"What happens when one of your interviewies calmly completes the task in the time alloted and wonders what the fuss is about?"

If you couldn't recognize that talent without the coding quiz you have bigger problems.

Tom H
Wednesday, January 14, 2004

Kobayashi Maru.

If it's good enough for the United Federation of Planets, then I guess it's good enough for me.


Sgt. Sausage
Wednesday, January 14, 2004

Nuff said. People who come up with questions like that are responsible for all the unemployment :)

Wednesday, January 14, 2004

I agree with Sgt. Sausage. If they can't ward off a fleet of Romulans I don't want them. They should also read a book by Ayn Rand in under 30 minutes.
Wednesday, January 14, 2004

The previous comment by marktaw is closed captioned for the sarcasm impaired.

Wednesday, January 14, 2004

Unfortunately, the closed captioning reads:

While technical interviews should both challenge and test someone's techinical ability, putting undue stress on someone for a job interview seems unfair. Now look at this picture of a cute bunny.
Wednesday, January 14, 2004

Regarding factor of 10, 100, etc, it's between the best and the average. You can't compare to the worst since they have a negative productivity, causing work for others while contributing nothing useful themselves. Consider the guy wh odoes nothing and bothers no one. His productivity is 0. No consider the guy who writes 5 LOC/month. His productivity is 5/0 = infinitely more than the guy doing nothing. now consider the guy with negative productivity. Well, Joe 5-line's productivity is even greater than infinity compared to the negative producer.

Ed the Millwright
Wednesday, January 14, 2004

"They should also read a book by Ayn Rand in under 30 minutes."

Anyone who willingly agrees to read Ayn Rand should be an immediate "No Hire"! ;)

Sum Dum Gai
Thursday, January 15, 2004

What if that person had never read anything by Ayn Rand before and was wonder what all the fuss was about?

Foolish Jordan
Thursday, January 15, 2004

Not so dumb; I can make sense of the results:

1- the program doesn't compile: not The One
2- the program runs but is buggy: poor
3- the program runs, but lack security checkings: pretty good
4- the program runs fine, but lacks some features: good.

An extra bonus to those who've remarked quickly that they won't have enough time.

Monday, January 19, 2004

*  Recent Topics

*  Fog Creek Home