Interview Questions
Heather, Gretchen and Zoe are going to kill me for this one, but it was cute...
Yesterday, we had a 5th anniversary lunch for one of the developers on our team. One of the other developers related the following story about his internal interview.
First a bit of a word about internal interviews. We interview internal candidates for positions, just like we interview external candidates - the internal candidate carries a bit of history forward, but they can be just as grueling, both for the interviewee and the interviewer (especially if they're new and interviewing someone more senior).
In this case, the interviewee came into the office, and the interviewer asked him a coding question (yup, we get them too).
"Design a vector template class, with the following operators and characteristics..."
The interviewer was stunned at the response:
"No. That's a horrible way of doing it, it wouldn't make sense."
It totally took the interviewer by surprise. What do you do when the person you're interviewing refuses to answer your question?
Well, in this case, he gave him a hire recommendation - the interviewee was totally right, the question he was asked was completely arbitrary and he gave great reasons why it was a poor solution to the problem. They moved on to other things and, as I mentioned, the guy was hired into our group.
Btw, I would NOT recommend doing this on your interview, unless you REALLY knew what you were doing. For everyone who gets away with stuff like this, there are a dozen who don't.
But it was kinda funny. I'd have loved to see the expression on the interviewers face.
Comments
- Anonymous
December 07, 2004
If the purpose of the question was to test some characteristic of the interviewee other than his/her overall design and coding skills, then the interviewer ought to be patient enough to say so one time and then see how the interviewee answers.
I've gotten in trouble many times for correcting my managers. Usually I try to explain and if the explanation isn't understood then I obey the instructions as they were given, but most managers don't even have that much patience and I get in trouble for it. If the instructions are really impossible as given then I try to find workarounds, and I get in trouble for that too, but the trouble is less if I don't say what I'm doing.
When the instructions come from a customer rather than from an immediate manager, then it becomes far more important to obey rather than making corrections. Depending on the culture there are various degrees to which it is possible to make proposals for some kinds of changes to a spec, but they cannot be stated as corrections because that would look like an insult to the customer. Again in the interview, if the purpose was to simulate what the interviewee would do when confronted with that kind of demand from a customer, then the interviewer should be patient enough to say so once and see how the intervewee performs. - Anonymous
December 07, 2004
Hmm. When Internet Explorer timed out the first time and I did a refresh, it warned that it was going to repeat the http post operation, but if both submissions succeeded I thought surely the moderator would only take one. - Anonymous
December 07, 2004
Happier? - Anonymous
December 07, 2004
That's actually a good story. Why would we be mad? :) We're not the ones who ask the silly technical questions. ;-) - Anonymous
December 07, 2004
12/7/2004 9:08 PM Larry Osterman
> Happier?
Well now there's only one copy of my reply as there should have been, but the continued existence of my "hmm" message looks really silly now. - Anonymous
December 07, 2004
The comment has been removed - Anonymous
December 07, 2004
Thanks for sharing :-) - Anonymous
December 07, 2004
Norman, well if you will use IE its your own fault. ;)
I like what Joel has to say about interviewing
(http://www.joelonsoftware.com/articles/fog0000000073.html)
especially the impossible question where you ask someone how many filling stations there are in a city.
I actually remember being asked in an interview how the boss should go about seducing demi moore. In the end I passed on that job because it became clear to me that this new company had a really badly thought out business plan and was likely to fail. - Anonymous
December 07, 2004
Gretchen, You're right, but I figured that recommending that saying "No" to an interview question at MS would be counter-productive :) - Anonymous
December 07, 2004
Simon Said:
"He then went on to insist that my multithreading whiteboard example was wrong, until I exhaustively explained how auto-reset events worked when multiple threads are waiting on them.
(He was also someone who rolled his eyes when I said that I'd never seen the need to use a sempahore so I couldn't remember the logic for them 100%)."
I've done a ton of multithreaded work and have also never needed to use a semaphore. I guess I'm not 1337 too. :/
I once had a long argument with someone who said that you can't do multithreaded applications with events. :O He even cited a paper that talked about WIN32 events and monitors in depth to back up his position. I referred him to the end of the very same paper which talked about alternate solutions which backed up my position and referred to the exact same pitfalls that I went into great care to explain to him. He still refused to believe me.
I love my auto-reset events. I have seen so many bad multithreaded implementations using manual events or PulseEvent that I could scream. Heck, I've seen a few with auto-reset events too. - Anonymous
December 08, 2004
In the joelos article, Joel also suggest arguing with the candidate about a point you both know is correct, ;) - Anonymous
December 08, 2004
While I think Microsoft prides itself on independent thinkers and people willing to stand up for what they believe in (both Larry's hire story and this thread show that), I feel obligated to point out that that characteristic isn't worth diddlysquat if someone isn't willing to do what Simon said, namely that when faced with someone who will not compromise, stop the war and try another method.
Sometimes that method might be to play the "they're the manager and even though they are clueless, they get to make the decison." Sometimes the method is to talk to other decision makers to figure out which solution is better.
A great Microsoft employee knows the difference :-) - Anonymous
December 08, 2004
The comment has been removed - Anonymous
December 09, 2004
Tom:
The question at hand was one of having a single buffer with two writers and one reader - how do you make sure that the buffer doesn't get corrupted?
A single "read lock" auto-reset event and a "write lock" auto-reset event will do the job nicely.
The questioner was looking for a more complicated solution, but an auto-reset event will - as you said - allow only one of the waiting threads to grab it - which is exactly the behavior you want.
I've got nothing against manual reset events per se - it just depends what you're using them for - eg. for signalling purposes or as a program flow control mechanism. - Anonymous
December 09, 2004
Simon:
Neat. Your solution would seem to guarantee that the single reader would read every change to the buffer so long as it was the only one signalling that the buffer was available to write. However if the buffer was allowed to be overwritten without the reader having a chance to read the content only a single event to signal a read or write operation complete would be required. - Anonymous
December 14, 2004
I know this is straying way of the original post, but... has anyone got any recommendations for some good good books on writing good solid multithreaded code for Windows? I've been looking for 6 months and found nothing great. :-(
PS. Nice story Larry, I've seen Simons interview case happen a few times as well. - Anonymous
December 16, 2004
The comment has been removed