What C# knowledge should I have? [closed]

Question

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

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

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.

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.

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.