Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Mar 14 '11 at 20:48

This question came from our site for professional and enthusiast programmers.

5  
I don't really see how it's applicable to understanding a programmer's ability to write .NET code today or their knowledge of the platform, but I'm also very cynical. –  Tyler Treat Mar 14 '11 at 19:58
    
Are you talking about .Net versions? Or corresponding language versions? –  Snowbear Mar 14 '11 at 20:02
    
If someone claims recent .Net experience, then I would hope that they used some of the latest stuff. –  Job Mar 15 '11 at 4:12

8 Answers 8

I wouldn't really ask about 2-3-3.5: those are mostly the same versions. The bytecode is compatible but some new things were introduced (that's why you don't need to install .NET 2.0 when you have 3.5 installed).

4.0 on the other hands breaks bytecode compatibility and introduces loads of new things in to the framework, like dynamic typing and functional programming (F#)

1.0 and 1.1 might be a bit too old, but 2.0 did something likewise, mainly to properly support generics (as opposed to Java which doesn't safe generic information in the bytecode, which makes an interesting interview question on itself)

So a proper interview question would be to let someone summarize the (in)differences between the .NET framework versions starting at 2

share|improve this answer
    
From 2.0 to 3.5 may all still be bytecode-compatible, but the introduction of LINQ in particular makes for a huge difference to developers. My feeling is that 3.5 to 4.0 is actually a much smaller change from the perspective of programmers in the trenches. –  Carson63000 Mar 15 '11 at 0:50
    
imho that is because many of the techniques introduced in 4 aren't discovered yet by "programmers in the trenches". Major paradigma changes take time to be introduced everywhere. Compare it to relational databases ("SQL") and OOP, which were available in academia long before they were used in the wild. –  dtech Mar 15 '11 at 8:08

I think this is context specific based on the type of job you want someone to apply for, if you want someone who is .NET only and must be an expert at all of the frameworks and for whatever reason know the history of them, then absolutely it is an okay question.

However if you want someone who is fundamentally capable of doing or learning to do a particular task in whatever is the right tool for the job then maybe limiting the scope of questions to the history of the .NET framework is much less practical then asking about problem solving, experience, algorithms, data structures and so on.

share|improve this answer

Unless they're trying to hire someone who must have intimate .NET knowledge, I'll declare this to be an overly-nit-picky question for a typical developer position interview. I wouldn't worry about remembering what versions of .NET had particular features added to them. Instead, focus on studying up this Stack Overflow wiki:

Questions every good .NET developer should be able to answer?

share|improve this answer

This is a bit subjective, but I personally think it's a perfectly good question. I wouldn't consider it a make-or-break question by any means, but it can certainly help gauge a candidate's understanding of the .NET Framework in terms of where it's been and where it's going. Each release of the framework has had at least one major change or major goal (generics, LINQ, async, etc.) and a question like this would be a good lead-in to questions about those changes, why they were needed, what they accomplish, etc. As an added bonus, if they know which versions brought about new runtimes would be good.

(As a side, you could take the question along a slightly different path and ask the candidate what kind of "cruft" do they think was left behind by different versions or was functionally deprecated in different versions. What old stuff are they glad to no longer have to use, and why? What features were they waiting for that have since arrived and what did they do before those features? etc.)

As I said, it's not make-or-break. It's really just to get more of a well-rounded understanding of how that developer views the framework and development therein. It's also pretty easy for them to have a canned answer for a question like this, so using it as a lead-in for follow-ups is important.

share|improve this answer
1  
I like to approach this topic in a more conversational tone. What new stuff have you found most useful in each newer version? What stuff hasn't turned out so useful to you? What would you most miss if circumstances forced you to develop with an older version of .NET? That sort of thing. Gives you a feel both for their knowledge and for their enthusiasm. –  Carson63000 Mar 15 '11 at 0:48
    
@Carson63000: Another good one would be, "What feature or features are currently not present in .NET, and how do you think it could benefit from them?" That one would show knowledge of the framework while at the same time show that they can think (and indeed have thought) beyond what's currently there or currently taught in some cert course or something. –  David Mar 15 '11 at 0:55

I think just listing them out is testing their memory rather than testing what they really know.

I suggest having a list of new features for each .net framework that you are looking for (Ex. Your company might not care about Workflow Foundation) and come up with questions regarding these features.

share|improve this answer

Honestly, I think this is more of a memory question. I work with .net every day at my job, and what you're asking me is how much I can remember about which things appeared when. Somebody new to .net now really isn't likely to have much if any exposure to 1.1 and thus won't know what was new in 2.0 from 1.1. It really doesn't matter to them either, and shouldn't matter to you.

If you have some specific knowledge you're interested in testing, it might be worth targetting that more directly. For example if you're supporting some .net 2 apps and you discover that the interviewee knows LINQ, ask them how they'd deal with not having it in a 2.0 app.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.