What C# knowledge should I have?

Question

A very open question. I've been programming in C# for the past 5 months doing small projects that I completed successfully.

Today I went to an interview for a C# role. The 1st question was 'Tell me about boxing'. Given my experience I had no idea what the guy meant. Needless to say the interview didn't go that well. Others questions were 'why isn't it recommended to use an ArrayList of int', 'tell me what you know about threading', etc.

I don't really want this to happen again so I'm planning to spend some time reading (and practising) more on C#. I understand that the best way of learning is by coding but coding wouldn't have really helped me answer the question about 'boxing' for example.

I'm not asking you to answer the above technical questions. In fact, I know now their answer as I went straight to Google after the interview and it's how I realised that my C# knowledge is somewhat limited.

My question is: in your opinion, which knowledge should any C# developer have? Ideally it would be better if you could categorize it (Basic knwoledge anyone should have without exception, Advanced knowlege, Expert knowledge etc). No need to go into details. Doing research on whatever you list will be a good exercise for me.

Thanks.

Answer 1

Here is a good list: What Great .NET Developers Ought To Know.

Answer 2

You can find a lot in this thread:

Good C# Interview Questions for a Senior Dev Position

Answer 3

Five months without any knowledge of boxing? My dear, dear, boy. I would hesitate to be in your position. Why, I remember those halcyon days when I, like you now, similarly lacked some of the basic knowledge of the tools of my craft. But, do not despair, lad! You have time and the desire to learn. Let us, forthwith, dispense some knowledge that you may use to your future benefit! Huzzah!

Read CLR Via C# cover to cover. Grab a Linq book (can't recommend any off the top of my head). Write an application using WPF (for the xaml). Those three things I think will give you the biggest bang for your buck right now.

Answer 4

Read the C# Programming Guide and C# Reference on MSDN.

Answer 5

I would expect someone going for a professional C# job to know about:

• Generics and generic collections
• Interfaces (general)
• Interfaces (specific), namely -
  • IDisposable: how it's integrated into the language and why
  • IEnumerable: including common extension methods, iterator blocks, and deferred execution
• Overview of serialization in .Net (maybe not have done it, but understand what it is and know where to look in the namespace heirarchy and documentation)
• Overview of Xml in .Net (same as serialization)
• Overview of threading concepts (same as xml/serialization). Bonus points for understanding why most thread-safe collections aren't.
• Have used anonymous delegates / lambdas in at least one project, and therefore also have a basic idea about closures.
• Comfortable explaining some basic concepts from at least one of winforms, wpf, webforms, or MVC
• Be able to answer some easy questions on specific common classes in the .Net BCL: namely from System.Data (think parameterized queries!) and System.IO (filestreams, path).
• Garbage collection: when should you call GC.Collect (hint: pretty much never) and why

Answer 6

Also depends on the role. If this was advertised as a jnr role then a threading question is a little tough...sometimes agencies/employers have unrealistic expectations.

Answer 7

Hidden Features of C#

This question/topic make easier your work.

Answer 8

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

Answer 9

My personal experience from a long time ago when I was in school.

I went to see my father at work in a bank. At that time, most of his day was taking care of accounts and making sure every thing worked. What I saw was he was trying to tally/calculate large numbers and calculating(basic additions/multiplications...).

After noticing him, I asked him: Dad, if all you have to do is basic additions and multiplications, why bother to study till graduation?

His response was : While you don't have to use all the knowledge you have acquired, that knowledge would help you make learned decisions.

Coming to your question: While you dont have to use the entire set of concepts, knowing that they exist would help you make good decisions while you code.

My suggestion along with the others posted would be to try and spend some time on stackoverflow every day.

Good luck.

Answer 10

This book would be a good start.

http://oreilly.com/catalog/9780596514822/

also,

I would recommend getting a Safari Books Online Account ... this will give you books to read and save you money.

Answer 11

A similar thing happened to my significant other taking a driving test. The state trooper said, "make a roundabout" and she didn't know what he was talking about. Both of us think a roundabout is a type of road layout with a big circle, not a u-turn as the instructor meant. So I know what you mean.

Programming job interviews vary wildly. Some people think you can't really judge a programmer well in an interview and are willing to give anyone who makes a good impression a chance. Others are grueling things which only those overqualified for the position would pass, and you will probably be suprised how often you get a call back from those.

Answer 12

This is something I have been pondering myself a lot lately. Using C# plenty but not sure what I am missing.

I ordered

Microsoft® .NET Framework Application Development Foundation

Which covers a lot of ground related to C#

Also looking at C# in Depth

Read some of this already. Has some great information from a high quality author.

In depth is on sale too via Jon Skeet's blog

Answer 13

I would have to say that if an interviewer can be fooled into thinking someone has more .NET / C# experience by he or she visiting a webpage, then the interviewer is failing. I've interviewed a number of people myself, and I really like the approach of giving them some easy to understand problem to solve, and asking them to write some code on a white board. Even if they've memorized the answers to every question on Scott Hanselman's blog, I would learn a lot about how comfortable they are in the language, as well as how they go about problem solving. I'm looking for a developer, not a partner for Trivial Pursuit, .NET Developer Edition.

That said, keeping up with blogs like Hanselman's is a fantastic way to keep up with the jargon. You could code C# in a vacuum for years, fully understand the advantage of a strongly-typed List<int> over ArrayList, but never actually use the term "boxing". But it's much more time consuming in an interview to ask, "Describe the advantage of iterating through a List<int> instead of an ArrayList of int," than it is to ask, "Tell me about boxing." Plus, actually researching the answers to Hanselman's .NET interview questions (especially if you explore the details and ask "Why?") will make you a better developer. So by all means, keeping reading Hanselman.

And one more note... If I ask someone whether a String is a reference type or a value type, and they simply say "Hmmm... Reference type," I'm not going to be nearly as happy as I would if the response was, "Hmmm... Reference type, but that's an interesting question." "Why is that?", I say... "Because string is implemented so that the string is immutable, allowing you to do things with it like safely use it as a hash key. Or pass it to a method, knowing the value cannot be changed. So in a way, strings can act a lot like value types..." And that would be a great conversation, leading me to ask, "So tell me more about why hash keys should be immutable..."

It's not just the difference between answering a 50/50 question correctly and all the additional information in the second answer. Having an intelligent conversation with a interviewee leads me to think I'll have intelligent conversations like that on a regular basis once the interviewee becomes my coworker. And that's something I'm definitely looking for.

Answer 14

A good interviewer isn't going to grill you on trivia. That's why we have Google. A good interviewer is going to find areas you don't know, and ask you questions there, as that's the best place to find out how you react when confronted with something you don't have down pat.

The best advice I can give for interviews is to not worry about the technical trivia too much. Instead, in an interview, focus on problem-solving skills. If you don't know something, don't try to hide it, just admit it. If you think you know, it's okay to say "I'm not sure, but I think it's this." And don't get flummoxed either - at that point, usually the interviewer will give you a hint. This is not just giving you the answer, it's another part of the test - to see if, given a nudge in the right direction, you can extrapolate from there.

For the boxing/ArrayList/int questions, if I was interviewing and you didn't understand boxing, I'd give you a basic description of what boxing did. Then I'd ask you, knowing what I just told you, why you might think using ints in an ArrayList might be a bad idea.

One thing that will go far in any interview is focusing on the requirements, the desired result, and boundary conditions or edge cases. As most programming interview questions fall into the "write this method" category, make sure you get the following correct:

1) The inputs to the method 2) The expected output of the method 3) Boundary and edge cases.

This sounds ridiculously basic, but it's amazing how many developers, even ones with experience, don't bother thinking through these things. Code solves a problem - if you don't understand the problem correctly, you can't solve it correctly.