Questions every .NET developer should be able to answer

<< New Year, New Job | Home | My Team's Developer Credo >>

Questions every .NET developer should be able to answer

Working once again on hiring developer talent I am again amazed at the number of candidates who come my way who have little or no understanding of object oriented fundamentals. As many of us end up doing interviewing even when we're not managers I figured I'd share some of the questions on my technical .NET developer interview that I expect any developer with experience to get right. Feel free to suggest more questions and critique the ones I have!

Describe inheritence, give examples of when you would use it.
Describe what an interface is, how is its usage different from inheritance?
There are many ways of working with multiple related items in code, such as an array. Name some of the other options and how they are used.
What is the difference between a value type and a reference type?
What is serialization? How do you implement it in .NET?
If you were going to read a text file from the disk, how would you go about it?
In .NET, you can modify class and method access with modifiers like public and private, what are some others and what impact do they have?
Describe as many objects as you can that are used with ADO .NET

When I design a question set, I try to avoid pure definition questions in favor of open ended questions. Basically I'm trying to get the candidate to go into an essay style dialogue and just tell me as much as they know in a given category. I find it is harder for people to fake knowledge with such open ended questions, and unlike your yes/no pure definition style questions I think the above requires them to actually have used and be aware of the concepts. Pure definition questions can be memorized and don't really show true understanding. Open-ended ones tend to give the candidate enough freedom to show their knowledge or lack of depth.

I generally don't expect everyone to get all the questions right. If your'e junior level I'd expect 30-50%, mid-level 50-80%, and a senior/lead should be able to answer them all without difficulty.

Print posted @ Monday, December 31, 2007 10:21 AM

Feedback

# re: Questions every .NET developer should be able to answer

Great set of questions.

I just finished a couple of classes recently, 2 semesters ago, and remember some of the info in your questions, but for the life of me I can't seem to remember all the answers. Is this just a little indicative of the Universities' teachin methods? Stressing the methodology and not the concepts...

Probably not but it makes me want to re-visit my texts just to anwer these.

12/31/2007 3:04 PM | The_witt

# re: Questions every .NET developer should be able to answer

Two additional questions.

We apply them in .NET/logic tests:

9- Revert a string with C#

10-

int Func( int value )

{

if( value == 1 ) return 1;

return Func( value - 1 ) * value;

}

a. What the function is trying to do? Do you recognize this technique?

b. Does it work? Any comments?

1/3/2008 7:11 AM | Fabio Galuppo

# re: Questions every .NET developer should be able to answer

These questions are actually practical - something that lacks in a lot of other interview question sets that people post on the web. I like them (and not just because I can answer them ;)).

@Fabio: your questions are C#-specific, not .NET-specific. Plus if you're looking for comments on things like tail-recursion optimisation chances are that most people will miss them in an interview even if they know them.

Cheers!

1/3/2008 5:37 PM | OJ

# re: Questions every .NET developer should be able to answer

Hello OJ,

Yes, these questions are C#-specific. We supposed that any .NET programmer can read C# code.

About the recursion question, it's a controversial question in my POV. Why? Because, some developers trust in partial functional code. A lot of developers told me: "Yes, it works!" (Really?).The answers I expected are simple things like "the function works partially. But, if the value is equals 0 then we have a problem", "if you change int (Int32) to uint (UInt32), the compiler prevents negative numbers", ... (tail recursion, loop unrolling, ... is a plus, of course). This question was very discussed (in portuguese) topic at my old blog: fabiogaluppo.blogspot.com

Make sense?

1/4/2008 8:58 AM | Fabio Galuppo

# re: Questions every .NET developer should be able to answer

Actually as far as code exercises I usually like to make them write the classic fizzbuzz.

www.codinghorror.com/.../000781.html

Of course I have more questions that delve into more specifics like SQL and ASP.NET etc, but the above questions I've found to be a good measuring stick of the understanding of .NET/OO concepts.

1/4/2008 9:36 AM | ewise

# re: Questions every .NET developer should be able to answer

I agree, I also ask more open questions like

talk about design patterns, testing methodologies, ajax frameworks, testing frameworks, etc

1/15/2008 10:23 AM | Eber Irigoyen

# re: Questions every .NET developer should be able to answer

Interesting. One thing about the recursion question -- I would have gotten what it does, what it is, and, more or less, does it work -- but I have to admit, I wouldn't have anticipated the hidden question of "but does it work for ALL possible values?" I hate gotcha questions, personally. That would be nullified in this case if the interviewer followed up with, "are you SURE?" That would prompt me to look for something hidden. Otherwise, well -- I don't want to waste the interviewer's time looking for problems in his code or, God forbid, risking insulting him by pointing out a problem in his carefully crafted code question that he may not have been aware of. That might get his respect -- or he might be the sensitive type that slams the door on you. Maybe I'm being over-paranoid.

Anyway. These are good questions. I have a thought though. I'm a little bothered by the "pop quiz" style of tech'ing. I realize that it can be effective, but I worry (a) that if you ask the wrong questions, especially if someone's nervous, you might miss the ones where he actually knows what he's talking about. I mean, asking about serialization -- fine, but not all developers will have had cause to learn about that/do that in the job(s) they've had so far. Granted, if YOUR job requirement is for someone heavy on serialization, then by all means, hammer him on it. But for general "did you just crack a .net textbook yesterday?" questions.... I dunno.

Though I hate them as the interviewee, the best question for the interviewer may be, "Describe a project you're proud of that you worked on recently, and describe the problem, any issues you ran into, and how you resolved them." The gander here though I guess is that they may have anticipated such a question and came with a canned, well-rehearsed answer. Which is where I guess you get into details, asking him specific questions about why he chose THIS solution over THAT solution, what his thought process was on that, etc. That I think is where it REALLY is, how to judge not what he knows today but what he might produce tomorrow -- how does he solve problems? What's his thought process? Even if he's not as knowledgeable as you, can you at least respect his approach?

Finally, an oft-asked question that I get, one that I approve of, and one that is missing from the list in the original post, is "What is 3-tier development?", with the followup question of, "why 3 tiers?" What I'd be looking for is presentation vs. biz rules vs. database. Bonus: Separation of the middle tier into biz object and dal object. Bonus: Discussion of web vs. biz service layer and how it was achieved. Bonus: A discussion of n-tier physical separation on availability, scalability, etc. I'll tell you, I just got done looking today at the code of a loudmouth who talked with the (loud -- I mean that literally) confidence of someone who knows "everything." Well. There was business logic in all three tiers. No comments. And, a personal pet peeve, web services/middle tier methods named after presentation-tier events, such as "DocumentScreen_Save." Ugh. UGH, I say.

In fact, for THAT reason, I'd almost include a question like, "How would you encourage code-reuse," or, "What kinds of techniques do you suppose would lend themselves to code reuse?" Not to be a hard-nose about it, but there's at least three advantages to code reuse: Less developer time reinventing the wheel, less testing time, and, I would say as least as importantly, just plain less code flying around. The more code there is, the more difficult it is to maintain a system. it's that simple. Eventually that impacts team morale and productivity, and, subtly or not, eventually impacts client satisfaction, e.g., "Why does it take so long to just change it to do THIS?"

I yield the soapbox. 6/23/2008 1:35 PM | Edward Buatois

Eric Wise