C# coding interview preparation [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

Looking for a few good C# interview problems.

Hi All, I have done a good amount of reading in C# and have also practiced most of the data structures too. My sour开发者_Go百科ce has been mostly msdn and few blogs. Interestingly, hardly anybody has asked me about data structures, optimization or their efficiency during a C# interview. So I guess this interview will also be very language inclined and so I want to practice language related concepts such as iterators, generics, arraylist, delegates, comparators and events. I would like to have few questions answered.

Am I missing few more concepts to be practiced as I am preparing for a Junior-mid level (on-site)interview?

What kind of language related programming questions are asked in a coding(onsite) interview?

Can somebody recommend some probable language related programming questions in C#?

Can someone also recommend programming questions on delegates or comparators?

Do employers expect junior-mid developers to code using query expressions or LINQ?

Thanks

---

As an employer, if I asked you to demonstrate how to write a LINQ query to fetch the first 10 rows ordered by X, and you didn't know how to, I'd be more interested in hearing how you'd go about finding out how to do it.

Nobody knows everything, it's how you go about learning what you don't know that sets you apart.

As a Junior-mid level developer, I'm looking more at personality, communication skills and culture than technical skills (not to say these aren't important for non-junior roles, they are just as important, but for a senior position I have higher expectations around technical ability).

You can teach technical skills, you can't teach personality. Generally people change only a little bit and over a long time frame. If they don't fit then they probably never will. You can learn how to write LINQ.

The point I'm getting at? If your interview is entirely focussed around how many lines of code you can recite from memory, and not on who you are, and if you're a good fit with the culture, you need to question if you want to work there. Chances are you will find you have little support, the team will be solitary, and generally quality will be low.

All of that said, you should focus on things you'll constantly be using: object oriented programming, encapsulation, cohesion, polymorphism, generics. Rather than algorithms, learn the built in types. Its highly unlikely that you're going to have to implement a linked list yourself, you will just use one of the existing base class libraries.

It's hard to predict what you'll be asked in an interview, mostly because just as the quality of candidates greatly differs between candidates, the quality of interviewers greatly differs. My experience has been most interviewers are actually pretty terrible at it, and ask the wrong questions.

Don't stress about what you don't know, focus on what you do know, and get ready to tell them how you will find out if you need to answer a question "I don't know."

---

I recently went through a pair of interviews (late May, June). Some common questions posed:

• What is an ArrayList? Hashtable?
• Disadvantages of each?
• What would you use instead? Explain why.
• What are the uses for the "using" keyword in C#?
• What interface is involved in one use of "using?"
• What is an interface?
• What do the access modifiers "abstract" and "sealed" mean?
• In SQL, what's the difference between an Inner and an Outer Join?

Kind of simple stuff, really, but then again, there are people that couldn't answer any of them. 199 out of 200, according to some people.

They also like to pose logic questions that don't always involve code, maybe show you a code sample on a whiteboard and ask you to find the errors, perhaps improve the efficiency. You know, be able to think on your feet.

Others, feel free to add to this, I'm marking it CW.

---

The job market is flooded with under-qualified applicants, so employers are looking for any way they can to filter out the noise and limit the number of people they actually have to consider. The easiest way to do this is to focus on your current, actual knowledge, which is far easier to measure than potential.

Expect to be asked concrete questions that test your knowledge of C# and .NET in general, and your ability to write safe, correct code, in specific. This means things like IDisposable, IEnumerable, lock, using, try/catch and so on. It's nice if you know LINQ, but the reality is that most interviewers aren't going to be particularly sharp, either, so they're going to focus on the basics, which means stuff that's been available for at least 5 years, not the "new" features.

---

I Agree with Steven - the workforce is filled with under skilled people. Confidence in your knowledge of the framework and the ability to properly communicate your abilities to problem solve if you don't know usually shine more than being a ninja in the black arts of thread management etc...

This is from quite a few years of experience in hiring for such roles. Most of the colleagues i have been with while doing said hiring have often agreed - some people "have it" whether they know everything or not. Good programmers understand logic and pit falls and how to research and learn to find a solution to a problem - these people get the jobs.