I agree you can't avoid them in most cases and I'm not even sure why I added that last part because it wasn't really relevant - but one of my biggest pet peeves is people in an organization that have to interview for an internal promotion. One interview to talk specifically about the position and reasons for wanting the job is reasonable but asking them technical questions or having them prove their skills is ridiculous in most cases because they've been evaluated on those skills for the last X months/years.

Teaching is another example. Often in Ontario people wanting to get hired as teachers volunteer or substitute teach for at least a couple of years before getting a full time job. But they still have to interview for any full-time job and some principals put a ton of weight on the interview even though they have a crap-ton of more relevant data to use to influence their decision.

i've never encountered a software job where this was not a critical part of the work.

care to elaborate on some of those better ways?

Firstly - there's a pretty significant difference between being asked to talk/explain what you are doing, have done or are planning on doing in relation to a specific project you are working on and answering interview questions about how to move mt. fuji.

Secondly - some of the best programmers I've worked with have also been people who are very uncomfortable talking in meetings and do not do well at all in interview situations (admittedly I'm just guessing at this - I've never been in a situation where I have interviewed them (or anyone) for their jobs). They do fine explaining stuff and talking things over with the people they work day to day with though.

no one is defending the mt. fuji question.

i'm sorry but if you can't explain technical things clearly to me in spite of being in a stressful situation like an interview, i don't see how i can work with you. that is a weakness in your skill set and it has been exposed by the interview process.

but hey, if you've got a better system, i'm still all ears.

There is something to be said for team fit though, the more people on the team that think the guy is a jerk after one interview the stronger the candidate has to be regardless of history with one hiring manager.

i dont doubt that this blogger exaggerated to make himself look good. of course thats likely

but 'sht was pulled' as soon as the interviewer asked the bs question that he had no real interest in knowing the answer to.

exactly. same sht different laxative. bs games. no thx.

both guys asked "why", and both interviewers had no answers. the second guy just went with it and started providing the answers himself. the second guy played along more, and yes, he did a great job thinking it through analytically. if that was the purpose of the question (which i take it is the justification behind these riddles), then great, the second guy succeeded.

but this one of the points!!: the interviewer didn't think he did a good job answering. you said yourself that if he were better he would realize that this is the guy he should hire. this is my gripe. the interviewer is playing a game where he doesn't even know the fkn purpose. he is too stupid to know why he is doing things, and is just doing them out of trendiness or whatever. fk that

Why is not being able to express yourself clearly verbally in an interview situation a weakness in the skillset of a programmer/developer?

What technical things are you looking for an explanation of? If you're looking for confirmation that he/she knows basic technical concepts in an interview then I'd suggest the screening process pre-interview is lacking. And if you're looking for more complex, in-depth knowledge, then a lot of the best programmers out there is going to have problems showing off their real knowledge in an interview setting.

All your interview process has 'exposed' in that case, is that the candidate does not do well talking with a stranger in an unfamiliar surrounding about stuff he's not prepared for.

Mr. nice - I'm not defending the question. But even stupid interview questions can provide good feedback in certain situations. And your response seemed to miss the point I was making (right/wrong way to answer a question).

You have a point, but you seem to be ignoring tc's also valid point. There are very few situations where developers are in a complete silo and never have to interact with people around them. How a person expresses themselves in an interview situation (where they should have prepared for the stuff they're talking about) seems like a reasonable proxy for how that person will react in various meetings and interactions with co-workers or external clients.

If you read my posts, I'm in no way ignoring that. My point is that these people do just fine interacting with people in a 'normal' work situation - being placed in an interview-situation is a very different matter for a lot of people. Having problems dealing with situations like that does not mean they can't do an excellent job otherwise.

The more you argue your point the less experience you appear to have in an actual workplace. I don't want someone who can't speak trying to tell me how their code works, it makes me feel uncomfortable and I still can't support their code.

not-so-ninja-edit to add:
The idea that everyone who does poorly in an interview will be fine in a normal work environment is also pretty lol, an interview is a nice simulation of a pressure environment. Not being able to handle one is good information to know for lots of jobs.

So, is anyone actually reading what I'm writing, or just assuming based on the first line..?

I just wrote a reply where I explained that I in no way said anything about people not being able to speak or explaining how their code works. My whole point is whether not an interview situation is a good way to determine how people will be able to do so in a normal work situation.

Right, and being able to confidently and comfortably explain things (by answering interview questions) has lots and lots of normal work situation analogs. Are there good interviewers and interview techniques and bad ones? Of course. But a blanket statement that they are pointless is ridiculous.

because when the product is broken and customers are screaming, you and i are going to be under a lot of stress but need to work together to get the thing fixed anyway. if we can't communicate, we're boned.

what do you propose instead? a quiz? essay questions?

fine. i don't want them. frankly, i strongly doubt that they're "the best programmers" if they can't have an intelligent conversation, but i wish them all the luck in the world being an army of one so they never have to talk to anyone they don't already know.

yet you offer no alternative. do i just take everyone that comes in at their word? judge them purely by code samples and chit-chat? only hire friends and family?

Which is why I didn't make one. In fact, I stated in a previous post that having an (informal) talk with possible recruits should be part of the process.

Thinking that a programmers ability to verbalise on the fly is an indication of how good he/she is at the actual job, is a very different matter.

Again, for about the billionth time - my point is that placing someone in an interview situation says very little about how he/she will work/communicate once they're in an actual work situation (unless that work situation acutally involves being thrown curveballs from strangers on a regular basis).

This very much depends on the position you're hiring for and who you're hiring (past experience etc), and I'm not going to claim to be an expert on hiring people.

However - I don't think that you necessarily need to provide an alternative to point out the (imo pretty obvious) flaws of relying too heavily on interviews as part of an employment process.


Again... noone said anything about these being people who need to sit in a dark corner and who tries to hide under the table any time someone tries to communicate with them...

There are next-to-zero people that get so nervous during interviews that they can't get a point across but are also fine in normal work situations.

How is this person going to function when a high level executive asks them a question? What about a Project Manager they're not familiar with? What about a client that's having problems with a tricky bug? What about in a multifunctional meeting involving people from departments they don't usually interact with? Where are you working where your developers are stuck in a room and only ever talk to themselves?

FFS... really...? Still..?

During a screening interview, I was asked how I would design a bike fit for someone visually impaired. I responded something to the effect of, "What, like, for blind people?", and she answered yes.

I thought for a moment and then I responded, "Well.. a blind person riding a bike doesn't sound like a very safe idea, so I would make the bike stationary, maybe with a fan blowing in the person's face. He probably wouldn't even know the difference."

She was speechless.

http://exold.com/article/stupid-interview-questions

****

This other one fries my mind since I don't really understand it, but it would probably be funny? http://exold.com/article/stupid-interview-questions

Yeah. Wolfram's ego is probably the single most blatant characteristic of any human being.

Well said.

There really isn't much substitute for meeting somebody, and if you're gonna meet the guy, you might as well ask them questions. The questions will end up being stupid, but meh, you'll actually come out of the situation knowing a lot more about the person than you would by reading a resume.

In particular, you'll do a little bit of screening out for people who are so horrible that they end up being an ******* to the interviewer....

Not to mention that you'll face way more idiotic customers than these interviewers could ever pretend to be.

There's also the "seriously how hard is it to be prepared for this stuff" aspect. I expect programmers to read stuff loosely related to work in their free time so I kind of expect a decent programmer to read some sort of "interview questions 101" primer.

How does digg (now linkedin?) have a patent on an upvoting system?

I don't know anything about patent law but how is that not "obvious"?

http://www.reddit.com/r/technology/c...6_mn_not_500k/

Whatever dude. Way to ignore the rest of my post that pointed out why what you're saying is ridiculous.

A better way of interviewing seems to be to look at how people act on a programming forum...