Interviews are full of an array of different types of questions. What I'm curious about is what people think about asking an interviewee about the differences in .NET versions. For instance, asking what was new in .NET V2.0 to 3.0 and then from 3.0 to 3.5 and so on. Is this a good interview question to find out what a person knows about the .NET world? As V2.0 was released in 2005, I start to wonder how valid it is to ask about what was new in a release done 6 years ago. Is it a good question at guaging a developers knowledge or just his/her memory?
migration rejected from stackoverflow.com Jun 26 at 16:26
This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.
closed as off-topic by Snowman, MichaelT, durron597, ratchet freak, Dan Pichelman Jun 26 at 16:26
This question appears to be off-topic. The users who voted to close gave this specific reason:
Remember that in interviewing, your job is not only to learn about the candidate, but to educate the candidate about your workplace. If at all possible, you want to make your workplace seem at least reasonably attractive, especially to the best-qualified candidates.
IMO, this question fails on both counts. At best it tells you a bit about whether the candidate has memorized some useless trivia. A candidate who can reel off a series of correct answers is no more (and maybe even marginally less) likely to be a good candidate than somebody else who can't.
Much worse, however, is that it's likely to give the best-qualified candidates a bad feeling about the possibility of working for you. Somebody who's good will probably have a number of choices of places to work -- and questions like this are likely to make the candidate think that s/he'd rather work elsewhere.
This is why puzzle-like questions work so well. Yes, they tell you something about the candidate's problem solving. Probably just as importantly, however, ones that are well-designed are interesting and fun, especially to people who are likely to be good programmers. They let you gain insight into them and they start that person off with good feelings about your company and thinking that working there is likely to be interesting and fun.
As such, even in the (rather unlikely event) that this information really matters, I'd do my best to avoid asking about it directly, and instead ask more about the kinds of problems that the features helped solve. If they really do know about the features and history, you'll almost inevitably hear about what a pain that kind of problem used to be, and how much nicer it is now that feature X was added. They may not say "it was added in 3.5SP1", but they're still likely to give a pretty fair idea of whether it's been there forever, or added recently, or what exactly.
To me that suggests that you have a customer base which does not like upgrades, or upgrades only slowly. Your programmers are working with old versions of .net in order to support those customers, and that's going to remain an important fact in the future. For a senior developer it translates to "we expect you to stay on top of the latest tech, but you'll be designing for old platforms and we're sick of designs that assume features that the customers don't have".
I suggest being quite careful about how to phrase the question and the context around it. Bringing it up in the "how do you feel about maintaining old code" part of the interview might be problematic.