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)