"Microsoft was responsible" (Score:3, Funny)
by siliconshock.com (slashdot@siliconsho[ ]com ['ck.' in gap]) on Tuesday July 23, @11:51PM (#3942219)
(User #531040 Info | http://siliconshock.com/)
I believe Microsoft was responsible for popularizing the usage of riddles in interviews
Yes, but they still have not been able to find anyone who can solve the "why does windows crash" riddle!!
Why do interviewers use "riddles"? (Score:5, Insightful)
by Turing Machine on Tuesday July 23, @11:53PM (#3942228)
(User #144300 Info)
What's up with using this type of question for interviews, anyway? Sure, they can be fun, but they're perfectly useless as far as telling whether someone can actually write solid code. 9 times out of 10, all they tell you is whether the interviewee has heard that one before.
To interviewers: Do you really think that the answers to these questions don't spread through the entire department within 15 minutes after your first interview? I realize that "knowing the answer" makes you feel smarter than the prospective employee in some sense, but how about actually doing your job for a change?
Re:Why do interviewers use "riddles"? (Score:4, Interesting)
by pongo000 on Wednesday July 24, @11:11AM (#3944504)
(User #97357 Info)
Those points are true if you're hiring a contractor to come in, do a job, and get out. They are not true if you're hiring a flexible team player who is going to handle a demanding job which is guranteed to throw new challenges on a daily basis.
Please. Do you really think some silly-ass riddles will separate the wheat from the chaff? In a previous life, I was an air traffic controller (9 years). I was thrown new challenges several times an hour. I don't recall riddles being asked on my interview.
I can tell you, however, that the three months of indoctrination in Oklahoma City was a head game unto itself. The point being it took three months to sort the psychologically strong from the weak. I seriously doubt a few puzzles on an hour-long interview is going to tell you much of anything.
To get to the other side. (Score:5, Insightful)
by realgone on Wednesday July 24, @12:33AM (#3942394)
(User #147744 Info | http://www.mistertumbles.com)
I know this is going to sound a little flamebaity; I do apologize for that in advance. But IMHO, when an interviewer falls back on riddles or, worse yet, the "what's in the invisible box" type questions, it reflects either a lack of effort or interviewing skill -- maybe even both! -- on her/his part. Honest, those old hoary chestnuts are like the SAT scores of the job world: indicative of something, but god only knows what.
Do you want to know if someone has strong logic/reasoning skills? Talk to them about past projects and how they've dealt with the inevitable problems and challenges that crop up. Look for those key details that show they're telling the truth; fakers are usually pretty easy to spot. Want to see examples of creative thinking? Ditto. Take the time to engage folks in regular conversation without resorting to gimmicks. You'll be surprised.
It goes without saying that I've refused to break out riddles and the like whenever I've been in the position of hiring new staff. There's absolutely no reason to make the whole process seem like a bad Q episode of Star Trek TNG.
Re:One of my favorites (Score:5, Funny)
by Henry V .009 (marstrail@ho[ ]il.com ['tma' in gap]) on Wednesday July 24, @02:17AM (#3942742)
(User #518000 Info | http://slashdot.org/)
You are writing a parser that reads a C program and translates all the variable names into new names of the form "VAR######", where ###### is an integer incremented for each unique variable name. Discuss what is needed for the case where the C program already contains a variable of the form "VAR######".
How is the view from the Ivory Tower?
Here is what actually happens:
I have 25 minutes to write out the parser. It's 11:35am September 30th, and our guys in marketing promised that C-Checker 5500 would be out in September. If its not finished on time, management will start complaining that we need to double the number of programmers or something crazy like that.
The hard part of the problem is variable identifiction. Have to look up the standard keywords again and type them in, and make allowance for a couple of other things.
After finishing that part I've got 10 minutes left.
Now I zip through with a little routine that takes the first varible it comes across and replaces it and all future occurences of it with VAR#1, and so on.
So I run my program on the main development project to test it out.
I press compile on the modified program. Cherchunketa, cherchunketa --- boom! Compilier error messages out the wazoo.
Who the hell named his loop counter VAR#37534? Goddamn that bastard! Who the hell does something that crazy?
Now I have 3 minutes to implement the fix. Do I write in the simple check algorithm that all the CS students you managed to trick came up with?
Hardly, I rename the thing to VARXY750#XXXXXX, and wait for a bug report.
As for the triple redundancy problem. Before you start going into your ANDs and ORs and wherefores, there are a few things to keep in mind. First off, if its really important, you need some non-local copies. What if there is a hard-drive crash? Or a nuclear war? The internet will still be around even if the main office is a glassed over glowing area in the North Western U.S. If it's important enough for triple redundancy, it's important to survive any forseeable catastrophe isn't it? So now you have to encrypt the numbers coming and going, and sign it, to keep the hackers from fooling you.
And so what is the easiest way to implement all this? Simple--there is no simple way. It'll take a lot of work. So you might as well throw your computer out of the window and tattoo the number to the back of your hand.
Re:One of my favorites (Score:5, Insightful)
by The Cat ( ) on Wednesday July 24, @03:18AM (#3942871)
(User #19816 Info | http://www.heavycat.com/)
I've caught some really bright people with it.
So, what's the point again? Proving people aren't as bright as they think? Making people sit there and squirm because they really need a job, are nervous anyway, and have some "three cups and a white marble" puzzle standing between them and feeding their kids?
I don't get it. My first question would be "why don't we just hire the bright people and get back to work?"
These tech interview questions are STUPID (Score:5, Insightful)
by JamieF (jamie@white-mountain.org) on Wednesday July 24, @02:35AM (#3942788)
(User #16832 Info | http://www.white-mountain.org/jamie/)
Am I the only one who thinks this interviewing technique is retarded?
Because Microsoft does something most definitely isn't a reason to emulate it. Microsoft isn't exactly known for producing well designed software, nor software that reuses proven patterns or algorithms that solved known problems 20 years ago. Better to hire a bunch of 21 year old college grads who can solve word problems from 8th grade algebra, and pretend that Microsoft invented computers! Whee.
When I hire developers I want them to be good developers, not promising young interns. My interview questions typically involve technology questions, process questions, some theoretical PROGRAMMING questions, and some social / communication questions. I'm not saying that hiring smart people is a bad idea, but ignoring skills and only looking at generic problem solving ability is a recipe for unbelievably bad code. It's like hiring musicians based on measured hearing sensitivity and reflexes. OK, maybe that matters if you want to figure out which 5 year old is going to be a prodigy, but hand them an instrument and the noise that comes out is going to sound like ASS.
Examples of things that "smart" developers I've worked with before have totally missed:
the existence of more efficient data structures than arrays
generalizing code into reusable chunks (functions, objects, whatever)
regular expressions
the difference between "client" and "server"
the reason for using descriptive variable names
collection libraries with built in sorting ("whatcha workin' on?" / "coding up a quicksort algorithm" / "in a J2EE app!?!?")
You can't just get this from reading a book, either, although that definitely helps. You have to have some degree of EXPERIENCE too: at least a few projects, and some awareness of things like performance tuning, security, coding for maintainability, etc. I would use these "tech interview questions" only for hiring interns or recent college grads where the expectation is zero experience, zero clue, zero skill, and a correspondingly low salary. After all you're investing in someone. But for someone that commands a market rate developer salary in the high five figures, screw the brain teasers - just spend a couple of hours grilling them on skills, experience, discipline, etc. They will respect you big time in return because they know when you extend an offer that they won't be working with a bunch of dumb-asses who can get the explorers across the river without being eaten by the headhunters but who can't code their way out of a soggy paper bag.
Re:These tech interview questions are STUPID (Score:4, Insightful)
by MeerCat on Wednesday July 24, @06:15AM (#3943179)
(User #5914 Info | http://www.schmerg.com/)
Precisely why companies end up with the wrong employees. My usual answer to these questions is "Sorry, the interview ends here, you failed", or (if I feel like baiting them) to "think outside the box" eg the bridge/flashlight/limited time issue "so, one guy is lighter than the others and they realise they can cross together, or they wait til their eyes adjust to the darkness and they're fine, or they check their watch and realise they have more time than they thought". If the interviewer says "no, wrong answer" I tell them they've missed "the big picture" and they need to "free their minds from the imagined constraints", and then ask them what we're doing next...
On a similar note, I do NOT want to hire staff who can put a list of obscure C++ operators in order of precedence, I want to hire those who say "well, I'd look it up if need be, but to make sure the next guy reading my code doesn't get confused I'd simplify the expressions with braces"... bingo - instant pass !
Interview questions should be open, not closed.
|