Not all interview questions are created equal
by Michael S. Kaplan, published on 2005/02/23 11:11 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/02/23/378975.aspx
Scott Hanselmen recently posted What Great .NET Developers Ought To Know (More .NET Interview Questions) and has been getting a fair amount of positive coverage for the list.
Now I won't say I don't like the list. And I obviously like Scott's blog (its on the list of the Blogs I read, after all!). But in my opinion I think the list has a lot to do with why I don't like many Microsoft interviews. When I do interviews myself, I generally like to avoid:
- Testing people to see how well they know a language or technology they list on their resume -- while this has some utility, I am generally not trying to trap candidates who may be overestimating their skills on the resume. It makes for a much more combative atmosphere, and thats just not me (those who think they know me may disagree, but then they have probably not been interviewed by me!). Plus if a candidate is nervous they may forget salient details -- and in real life they have IntelliSense and MSDN and such, anyway.
- Ever telling people they can use any programming languge they like and then silently judging them for their choice. Maybe they will have to prove why they think it is a good choice -- this is a job interview after all! But if I say they can use anything then they can walk in with LISP, SED, QBasic, Pascal, DOS batch files, ALGOL, SQL, or whatever crazy-ass language they want. Again, I am not trying to trap people here.
- Questions that smack of typical brain teasers, the sort of tripe that fills up "Interviewing at Micrsosoft" books. In my opinion looking for smart, rather than clever -- hardly the same thing (though one can often masquerade as the other in these kinds of questions!). Too often such questions are really tests of how many of the books the candidate has bought or web sites that have gone to (being flown thousands of miles and put up in a hotel to answer why manhole covers are round is also a little insulting, IMHO -- to both parties).
- Anything that tries to test programming competencies on a totally basic level (like "reverse a linked list" and such). These questions really just test how long it has been since they got their CS degree, or again how many books/web sites they have looked at. Maybe thats okay for some if they did just get their CS degree, but it's pretty easy to see such questions as insulting if many other situations (being flown thousands of miles and put up in a hotel to be asked to do almost anything with a linked list can be that way!). If there are doubts that a person has even this level or competency then there are real doubts about them overall, I think1.
- Usually, questions about specific knowledge of the area of NLS APIs or their managed equivalents -- most people don't have a firm understanding of them anyway (at least by our standards). But the smart ones will learn, anyway. There is no good reason to assume that everyone who is smart will understand the area (most don't), but lots of hopes that the smart ones will learn it (they do). And no hopes that the ones who are not smart will ever know more than they walked in knowing, even if that included some internationalization knowledge....
That last point maybe suggests what I do try to find -- questions that make people think about our scenarios (which are usually new to them) because I want to see them think. The hint of understanding how they pick up new ideas and work through problems in unfamiliar areas are the real test of how well someone will do at Microsoft, in my opinion. Because technologies change and knowing all about something today tells me nothing about what they will know next week or next month or next year. And once you hire someone, you kind of expect they will be around for those things....
There have been several times in posts here that I have hinted or outright stated that something might make an interesting interview question -- globalization is full of things like that. It is unlikely that one i mention here will be used because I'll have found other stuff by then, since most of the ones I use actually come from things that I was working on recently -- what better way to see if someone finds an area interesting than to see if something akin to what is being worked on (admittedly simplified to fit in a short timeframe) is engaging to them?
So, definitely you can pay attention to Scott's list and go the sites and read the books for some of the interviews you'll have on your interview day. But I am looking for something else, though -- I want to see the wheels turn. And there isn't a good technique to prepare for that....
1 - One exception to this rule -- sometimes when they did just get a CS degree or it seems like they have been visiting those web sites, I will take one of these sorts of questions but add some detail that turns the conventional question on its ear and requires them to think about the problem. But that is the key -- not to let anyone feel that their web browsing habits give them an edge. They have bring their brain with them to think, not to store trivia....
This post brought to you by U+fffc (OBJECT REPLACEMENT CHARACTER)
# Mark on 23 Feb 2005 10:02 AM:
Hi Michael -
How refreshing to hear that someone within Microsoft does not just focus on brain teasers during the interview. I interviewed for a program manager a while back and had the question asked "How would you go about finding how many miles of paved road exists in the U.S."? I said I would call AAA. The interviewer did not like my answer at all.
I think questions that relate to real challenges that teams within Microsoft are experiencing are the most valuable to both parties. For the interviewer they get to know if this person will fit into the culture. For the person being interviewed it gives him/her the chance to see if this is a good fit.
I think your statement regarding the testing of programming competencies "These questions really just test how long it has been since they got their CS degree, or again how many books/web sites they have looked at." is right on. From my experience one of the most important attributes to look for is how teachable is this person. Anyone coming into the organization will need to come up to speed, learn how things are done, what is acceptable what is not, how to use their technical skills to help solve problems. Just asking the question on how to reverse a linked list will not give insight here.
Excellent Post,
Mark
# Sriram on 23 Feb 2005 10:09 AM:
Ok - so what are the questions you *do* ask? :-)
# Ben Monro on 23 Feb 2005 10:22 AM:
AMEN!
# Michael Kaplan on 23 Feb 2005 11:14 AM:
Hi Sriram -- I give hints about the questions I do ask all the time here, in posts. Any interesting internationalization issue could end up as something I'll suggest people write a little code for. :-)
# Bill on 23 Feb 2005 11:22 AM:
Here here! I could not agree more, there are many varied traits that make a "good" programmer, and trying to uncover them in an interview is always a challenge. I believe there is some value to asking some specific technical questions in the candidate's field of expertise, if only to weed out those who exaggerate greatly (or flat out lie).
I've been giving quite a few interviews lately for .NET senior devs, and I've been unable to come up with a set of questions that I absolutely love. It seems to come down to the individual and to keep asking them about what they actually enjoy about coding, problems they've been faced with in the past and how they solved them. I too really like bringing up something I've worked on recently, and see what approaches they would take.
So what questions do you guys like to ask?
# Ryan Myers on 24 Feb 2005 7:11 PM:
Nearly total agreement. Any interviewer that even thinks of opening one of those classic "Microsoft Puzzle Books" needs to not be interviewing, IMO. The ability to solve puzzles means very little, especially with someone who's been programming for a few years. Puzzles should only be used for fresh-out-of-college types who don't have much of a resume to show a track record.
That said, I don't think such questions are entirely useless. The goal of a question is to see how they think, how they attack a problem and how enthusiastic they are about computing; it's just that most "puzzles" don't actually do that. One of the best problems I was ever given in an interview was to code a few routines in C for a driver for a hypothetical device -- it's a problem, but it's something that's actually applicable, rather than just an "a-ha" question.
Likewise, even though I'm the closest that our team has to a C++ language lawyer, I wouldn't ever interview based on knowledge of C++, unless it was something very vague like "Can you give me a high-level explanation of what templating is and how it's used?" Little tiny trivia like alignment, calling conventions, etc. are important to know, no doubt, but demonstrating knowledge (or lack thereof) of them isn't going to reveal much in an interview situation.
I think the fundamental question is that some people see interviews as a way to weed out the "losers" -- I see interviews as a way to determine how someone reacts to challenges, and how enthusiastic they are about their field. If they tackle problems in an intelligent way and they're excited about what they do, then they'll learn the trivia on their own initiative given time, and THAT is more valuable than someone who's just a walking dictionary of facts.
# Balaganesan S on 20 May 2005 12:02 AM:
Excellent article! When I interview people, I try to guage the depth they can go rather than asking language syntax, namespace, and commands. Anyone can find them from help files.
I was rated the toughest interviewer in the loop everytime. Whoever I recommended ended up being better than me in the smart-o-meter. I also see interview as a discussion and not as an opportunity to prove myself smarter than the other person.
I see interviews as another form of exams from our education system. It is designed to find what a person don't know rather than finding out how a person would add value to the common cause.
I used to work for MS. Once I tried to move to a different business division because I believed that I can add tremendous value to a few teams in that division. In every interview loop, I had 100% acceptance from the development manager. But when someone asks question like write a code for tower-of=hanoi, I stumbled. What has tower of hanoi has to do with business situations? Sometimes after I return to my hotel room and think about some of the inefficient answers an interviewer provided me. I work and find a more optimal algorithm and send them a mail. Result, that person strongly opposed me getting into their team. The funny thing is that the hiring managers freely discussed these points later on. One team told me that a popular MS product will be rewritten using Infopath, effectively losing nearly 50% of its usability and MS top management gave them their blessing, I figured it was time for me to find a different company.
May be one day, I will be able to change the objective of interviewing in my company. Till then, cranking up answers for Scott Hanselmen's questions is a good way to get my feet inside the door.
Please consider a
donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
referenced by
go to newer or older post, or back to index or month or day