I'm a senior developer and been involved in a number of interviews, on both sides, and I've learned a lot about interviewing candidates (but still have a lot to learn!). I've tried a few different methods so here's my $0.02.

In a senior developer I'm looking for:

• Skill/Knowledge
• Evidence that they have actively tried to improve their work
• Evidence that they have a real, true interest in the craft
• Something they've done that I haven't seen before
• The ability to think software design through mentally

So, here's my current best guess at how to assertain the above:

Skill and knowledge, okay this is well covered above but basically I want to see some knowledge of things like the GAC, CLR and JIT. Here are some sample C#-specific questions:

• Where are the framework assemblies stored? How is this useful?
• Explain the abstract keyword and what is an example of its use?
• Can you prevent a class from being inherited by another class? If so, how?
• Describe a pattern you have used or seen used.

Evidence that they have actively tried to improve their work

A senior developer needs to be involved with keeping the skill levels of the rest of the team up, so they need to take an active role in keeping abreast of what their skill levels are and keep them motivated to learn new things. To do this, they must be engaged in learning in their own work. Even 1 or 2 hours per week where they are trying something new, at home or after hours, is enough. I'm adamant about this.

Evidence that they have a real interest in the craft

One way to get to the bottom of this is just to ask the candidate about a project in their career they enjoyed, and just ask how and why they implemented it the way they did. This should be easy, you should actually need to tell the candidate to stop talking. If it's like drawing blood from a stone, they're not the right person.

What have they done that You've not done before?

Related to the point above. I want the candidate to tell me about something they've done that makes sit up and pay attention. Could be anything. A contractor last year told me about build automation in an interview. Hired.

The ability to think software design through mentally

Here I'm looking for the candidate to be relatively fluent in the language. A senior developer shouldn't need to do internet searches for keyword use (very often). This point is subjective so apply the needs of the job being interviewed for.

To address this point I have asked candidates to write code using pen and paper. Just simple stuff, like a Factorial method or a string reversal method, and a class implementation involving polymorphism. I really believe that some ability to write without a keyboard and a software IDE is crucial. But don't open with this because it scares the crap out of the candidate.

The rest

There are still things that all of this doesn't cover. There are just things that a senior developer should be aware of, even if they haven't been directly exposed to them: continuous integration, build automation, unit testing, design patterns, web deployment projects, reference vs value types, etc etc etc. Just think of as many as you can and drill them.

And don't hire 'maybe's.

edit

Okay, I actually agree with Vinayak - it may not always be useful to require pen and paper coding, but at the very least have your candidate write some code on a spare PC. It's the only way to know whether they're any good. Oh and ask to see code samples (get your recruitment agents to warn them first).

edit 2 Also, make sure they can touch-type! It shouldn't have to be mentioned but I've worked with too many developers who managed to get hired even though they can't meet such a basic requirement.

Lots of good questions here!

http://www.hanselman.com/blog/WhatGreatNETDevelopersOughtToKnowMoreNETInterviewQuestions.aspx

A common mistake among interviewers is to focus too specifically on a language or technology. If I were interviewing a C# question I would only be interested in the experience of the developer in a general sense (ie how long have you worked with C# - what sort of project did you do? could you give me an example of a problem and your solution to it?).

General questions are great for getting a candidate to open up and talk to you so you can get a feel for who they are. Once this happens, you can get at what really matters - are they yanking your chain or not?

Anyone can memorize keywords, buzzphrases and Google for the answers to common C# questions. I've seen this time and time again. They answer everything you could ever want to know with confidence and then you hire them and present them with a problem and they are completely lost. What I'd be interested in is whether or not this person will admit what they don't know - those people are able to learn.

My tactic is to ask a question you know to be false or invalid. If they respond positively that they know what you mean or nod appreciatively as they stammer over an explanation - move on. If they look you in the eye and tell you they have no idea what you're talking about but they could probably investigate the answer - hire them.

I'm assuming you want C#-specific questions here. Of course, you'll want to ask general coding, architecture, project management, etc questions. (They're far more useful questions by the way than specific technology-related questions).

I always try to get a feel for the candidate's level of knowledge. There's no point asking tough questions of a junior developer; equally, a senior developer needs tougher ones. I start by asking the candidate to rate their (C#) knowledge on a scale of 1-10. Start with easier questions and give more help for a low self-score; skip the easy questions and give less help for a higher answer. Reject anyone who says they are a ten.

Easy questions:

• What's the difference between a class and a struct?
• Is System.String a class or a struct (or reference or value type if you prefer).
• Explain IDisposable and the 'using' statement.
• Explain public, protected, private, and internal.

Intermediate questions:

• What's the difference between Hashtable and Dictionary<>?
• What does int? mean? Explain the relationship with Nullable.

Hard questions:

• Explain the following snippet of code: 'from x in collection select new { x.Foo }'. What is the compiler doing? What is the CLR executing?
• Explain the "yield" keyword. What is the compiler doing internally?

BUT as I mentioned earlier, you're far better off asking more general coding questions, than focusing on C# specifically.

My advise is to have minimum amount of C# specific questions. Ask about how to solve problems. If you only ask some C# specific questions you might get someone who only knows the syntax. But if he knows the theory and how to solve problems whatever the language you are way better off.

Also read the article " How to Interview a Programmer ^[1]". It has a lot of great advice from guys that have done this a lot.

1. What are Generics ? How do they affect performance.
2. How would you define an Anonymous Functions? What is the difference between Anonymous Methods and Lambda Expressions?
3. How does an Enumerator (IEnumerable & IEnumerator) work ? How does an Iterator work in C# 2.0 ?
4. What is Garbage Collection ? How does it work ? What are generations in GC ?
5. What is the role of an Extension Method ? When would you use it ?
6. What is a Lambda Expression ? Where would you use it ?
7. How would you define a new custom event ?
8. How would you choose between a pure abstract base class and an interface.
9. What is MVC how does it differ from MVP ?
10. What is Dependency Injection / Inversion of Control ?
11. What Design Patterns are you familiar with ?

As someone said before me, a senior should have knowledge outside the C# domain. I would concentrate on that:

• What other languages do you know? In what ways are they superior to C#? In what way is C# superior to them?

  Many dotNet developers have trouble with other technologies. But having a diversified experience makes you a way better programmer.

• How would you write a blog web site? (if the job is web related)

  This lets you evaluate his or her favorite development style (db centric, model centric) and knowledge of existing solutions.

• Name a few patterns and anti-patterns and explain what they are good for and what are the pitfalls (if any).

  Patterns are good knowledge, but they are tricky to learn (see singletonitis for example). A senior developer should know when to use patterns and when not to use them

In general you want to see a lot of practical experience and should give less importance to theoretical questions. After all, a senior is a person that will have to solve real life problems and most importantly, get the job done with minimal fuzz.

• What features do you like about C# and why?
• Name 3 features you dislike about c#. how would you make them different?

There are some really good answers here. I don't subscrube to the philosophy that asking questions about the syntax of the language is a good way to judge a developer. The question you should ask yourself first is:

What do I want out of this developer?

If he's a senior developer then chances are he will be mentoring your junior programmers and guiding your other programmers. Leadership skills in this case are vital, his personality is very important in this position.

With the speed that technology changes it's important that developers keep abreast of the new technologies that flood the market every 6 months. The last thing you want is someone who is set in their ways and refuses to use new technology or design principals due to a lack of understanding. Ask about the technologies he's looked into recently and try to guage his passion for his craft.

The rest of your questions I would direct at the technologies that he'll be using in your company. It's all well and good to find out how much passion he has for developing and seeing how well he can lead, but he or she will still have a job to do and as a senior will be expected to do it well. Make sue he's competent in the patterns you use and the tools you need.

Good luck! I've interviewed many developers and I find it great fun.

How about this for your question:

Would you please sit down here at this workstation and write some code with me? ^[1]

• What is an intern pool ?
• How many generations of garbage collection are there?
• What is a Satellite Assembly?
• Why are catch all exception handlers bad? When/Why might you use them?

Best interviews make the developer actually write some code, maybe a small project or task.

I've been developing in 20+ different languages for over 25 years with 18 of those as a contractor. I class myself as a lead developer/senior developer/mentor/part time pm/consultant and have delivered key solutions for numerous blue-chip financial organisations during that time.

I know the answers to some of the questions above but by no means all but that doesn't make me any less effective in my role. What most people are looking for in my view is someone who can fit in, talk to people at all levels, bridge the gaps between technical teams and business users, solve problems and generally get something done. In the financial world all of these skills are just as important as language specific knowledge. I've been put on the spot and asked to critique people's code in interviews, this can work both ways; sometimes it tells you more about the interviewer and their standards and may show that they have more to learn from you or that they are obsessed with an ideal world approach to development rather than a pragmatic one.

So overall I would say it needs a balance between technical and general questions, and as Scott Meyers says in the referenced article on interviewing a developer: "I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate."

Here are my "feeler" questions that I use to see how deep I can dig into someone's .NET knowledge.

1. Talk about the differences between different .NET versions, and your experience with each.

2. Do you favor C# or VB.NET. Why?

3. What's the difference between "override" and "new" in a method declaration?

4. Does .NET support multiple inheritance?

5. How do you display a table of data on an ASP.NET page?

6. Explain the ASP.NET postback mechanism.

7. Explain how ViewState works.

8. Explain different ways of calling methods asynchronously.

9. Explain how the JIT compiler works (from a high level)

10. How would you troubleshoot a memory leak in a .NET application?

11. Explain IIS 6 ASP.NET security and how it applies to an ASP.NET website.

Well, senior dev must know about design not only c# specific features. I would ask him to implement some design pattern in C#.

What I would ask for sure:

• Disposable pattern
• Async pattern
• GC related things: finalization, objects lifetime etc.

I always find that the best developers, regardless of seniority have a passion for what they do. Try asking about the best bit of code they ever wrote, did they hear that interview on dotnetrocks, are there and development books they consider essential reading.

If you're looking to hire a candidate, then you may already have an idea what the scope of their workload is going to be, so concentrating technical questions on areas which are relevant to the work they will be doing is the best bet.

I maintain there's no substitute for somebody who's passionate about the job though. Those are the people you can challenge to learn many things that they may not be able to answer at an interview, and if you can keep them challenged, they'll become key members of your team.

Here's a simple one that gives a surprising amount of insight.

"What are some of your favourite Visual Studio keyboard shortcuts."

If he/she passes the initial tech questions of "what is the different between an anstract class and an interface", etc, get it more detail by asking them to illustrate a few different design patterns of your choice.

Not to downplay the knowledge of book stuff, but as an interviewer, you will learn a lot more about the candidate's capabilities than just whether or not he we went to ComputerZen and memorized all of Hanselman's .NET interview questions. If he/she can explain a time they used an abstract class instead of an interface, then you shouldnt have to ask them the difference between the 2.

In addition to that, I like to start by getting into an indepth technical conversation about the things he/she has done. "Tell me about your last project, and how you used some of .NET capabilities to solve a problem".

Lastly, construct a scenario where the 2 of you would construct something, you can use a white board if you want, but do it together and let them do most of the talking. For example, "Lets build ApplicationX. What kind of business objects would I need? What might be some neat UI design features you would want to implement?"

When finding a .NET developer, it is not only imperative that they know the Framework very well, but that they are capable designers of code and apt problem solvers.

Oh, and my favorite question to spark a conversation and get an idea of where they are in the community (looking for a sense of passion here): "What blogs do you read?"

"Tell me about some of the projects you've worked on recently."

All the above answers are good. The only thing I would add is if they give you a problem to solve be sure to make them clarify it so you understand it. Don't be afraid to look slow or dumb. Really make them clarify the question. This is a big part of what good interviewers want to see: are you persistent enough to really grok what the problem is? In some cases, the answer is almost an afterthought.

I don't have a favorite question but I do have a bit of advice regarding questions. Make sure you understand the question fully before answering. That usually means asking some clarifing questions of your own. Not only does that give you time to think of your answers it also shows that you are thinking about the problem before just tossing out any old answer.

Good luck!!

Ask them what the latest .Net stuff is. Do they know Linq, Entity Framework, MVC and all the stuff? If so, drill down and don't forget to check if you can trust them. Maybe they've 5 years of experience with Linq, uuuhh, or they've already done 20 large scale products with Entity Framework, eieiei, you know what i mean. I've met a consultant in 2003 with 3 years of experience in Commerce Server 2002. That's why i ask questions like these all the time.

There is obviously hundreds to thousands of different questions that anyone can ask during an interview. Nobody can know all the answers, expecially to some of the esoteric ones talked about in this blog. For example, I have worked with ADO.NET since VS 2001, and I can bet that if somebody asks me a question that I don't work with daily, I probably wouldn't be able to give them the answer. The thing I would know is how to get the answer. Interviews are a great thing, but lets not get carried away with questions that only feed the interviewers ego, but questions that are relevent on a day to day basis.

Ask to see some code he has worked on professionally. Talk about it.

Give him a miniature coding assignment before the interview and have him bring his solution to your meeting (it does not have to be hard, it can even be trivial). Talk about it.

Ask him to explain the design of a system he has worked on, what was good and bad about that design, where the pain points where and how he would recommend to alleviate them, the trade offs made, why etc.

Ask him about what factors makes a successful software project and how you create a winning team. Ask him about his experiences with development projects and follow up on his opinions.

If you are unsure about your ability to judge his strengths and weaknesses, bring another experienced developer with you to the interview.

I will not be asking code or language level questions in an interview. I will ask as to how does he approach a new technology or language. What are his short term and long term goals. This is not a HR question but very much related to programming. Though I am senior developer myself, I did interview some candidates for developer positions. Here are few questions that were asked to me when I was being interviewed for senior .Net developer position.

1. If we have a person class, how can we implement sorting on different properties of the class. (I answered implementing IComparable and IComparer....)
2. Should we override equals if we implement IComparable? What else do we need to do?
3. Situation-- Code has been deployed in production. Client complains for a particular scenario, he is not getting the correct output. How would I figure this out?

In one of my recent interviews, the interviewer asked me if i had used 'SelectSingleNode' method in XML. He wanted to know if the method throws an exception if more than 1 nodes are found matching the criteria. My reply was "it is a code specific question and when I go to implement, I will figure it out." Sorry my answer was rude but I feel that was nota question to be asked to Sr. Developer. That's my opinion.

I found some good ones at C# Interview Questions ^[1]

I find the best way is to produce a simple problem to be solved (small app style) have them design the solution, pesudocode it and then justify their choices.

Another option is to give them an API to identify how it can be optimised (where should an interface be used over an abstract class, why there aren't internal classes/ methods)

I would usually ask them their favorite features in C# and ask them to write some code on that. Like for instance if they say they like interfaces and so on..then i would ask them write a sample for interface and some other minor implementation. Most of the times we can evaluate the person based on the code he/she writes.

• Explain what is a delegate and show an example of its use
• What is the difference between a BeginInvoke and an Invoke
• Explain the IDisposable pattern and how and when it should be used

Alright so a lot of these answers/questions are excellent, thank you for your responses. Now, I had the interview and I it really through me for a loop. Instead of general questions that one would expect, they gave me 4 scenarios and had me solve them using a white board.

I thought it was pretty effective, and I was just wondering what you guys think of doing scenarios instead of questions like those above?

Not very specific to .Net Interview, but I would prepare for,

"Give me a situation where you made a mistake in the code, that had a major impact on the end user (assuming Unit test and QA didn't catch it), explain why you think you made that mistake, and how you fixed it. Talk technical"

This question allows me to explain coding mistakes that one might make and how careful one should be. If I know atleast one common coding mistake, that means I've done enough development to know such things.

Actions taken to fix/rectify also shows passion, commitment, foresight and such.

My favorite things to talk about:

Memory leaks in .NET (Observer pattern) and the Dispose pattern. How do you find and solve performance problems? How do you find and solve memory leaks? Why are you a developer? How do you learn new things. What are you learning now?

Ask them a couple of really basic questions. eg:

• What's the difference between public and private?
• Write a function to return the area of a rectangle given its width and height.

It wont help you choose a senior developer, but it'll weed out the candidates that have bluffed their way through the initial CV-culling.

What sucks is when ALL your short-listed candidates fail. Speaking from recent experience.

Tell about boxing, unboxing and difference between value and reference types.

Today, the .NET platform is not a perfect abstraction. You get best results if you understand how the OS works. I think it's quite relevant to ask questions about Windows, Win32, COM, etc. even if your project won't include any unmanaged development.

A nice question that starts from C# is to ask about that [STAThread] attribute you sometimes see. A candidate's description of that will really show you how experienced he/she is.

I always try to finish with "what are your 3 favourite technical books?". Although books are rapidly becoming unnecessary for developers, most good devs will have read at least three. It almost doesn't matter what their choices are, but if they can't think of three technical books, you might be suspicious.

When replying to what you have worked on, don't just list the project, list your accomplishment. No matter what the project, large, small, college project, you efforts produced a result.

Ask them their favourite major version features, e.g. what do you like and use in 3.5 that wasn't in 2.0? Critique them on their reasons; is it for efficiency, elegance, portability?

I always ask for their favourite means of help: which websites do they read for help. When something comes up on a Google search page, which do they follow first?

In the website below, C# Interview Questions by topic can be found.

C# Interview Questions ^[1]

I have consolidated .Net Interview Questions at www.etechplanet.com.

.Net Framework Interview Questions: http://www.etechplanet.com/questioncategory/Net-Framework.aspx

ADO.Net Interview Questions: www.etechplanet.com/questioncategory/ADONet.aspx

ASP.Net Interview Questions: www.etechplanet.com/questioncategory/ASPNet.aspx

C# Interview Questions: www.etechplanet.com/questioncategory/C.aspx

Visitors are also requested to share Interview Questions at www.etechplanet.com.

here is a interview website, http://tipsinterview.com

Here is another link to C# interview questions ^[1]

I have interviewed many and..

for juniors...its aptitude I am looking for! for want-to-be seniors...are they responsible (and there are many that just sit there in the job waiting for others to spoonfeed them day in day out). You don't want these... for seniors - whatever features they've used, do they actually understand WHY (for instance, yield return, linq, specific logging, error-handling, testing, data-access, patterns, performance techniques, etc. etc...).Seniors should be able to justify why they've chosen specific programming techniques etc.

Finally, if someone has put something on their CV...probe them to the nth degree. Its an unforgiveable SIN to put 10 years test driven development experience and not know some of the basic questions on it!

Here's a nice link with 300 videos on interview questions which covers C#, SQL Server, Asp.net, WCF, WPF, Azure, Design patterns, etc.. : http://www.questpond.com/

I have always used that site for interview preparation

Use this link, you can find some C# Interview questions.

http://lionalblog.blogspot.com/

Refer

http://lionalblog.blogspot.com/2010_07_01_archive.html

Your comment is awaiting moderation. this is a good collection of c # interview question thanks for author and also i have found some more questions on fallowing glog http://lionalblog.blogspot.com/2010/07/c-interview-questions.html

check out some ques listed on http://csharptopicwiseques.blogspot.com/.... they seems to be good.

Here are some more C # Interview questions ^[1]

I ask candidates to explain the fetching and rendering of a web page. It let's me explore knowledge of DNS, TCP/IP, HTTP, web servers, web application execution (i.e. the anatomy of .aspx), CSS, JavaScript, AJAX, browser rendering, et al. I get them to go as deep as they can on all subjects. Many candidates have no clue what's actually happening when an .aspx page executes. Good candidates can speak in great detail on several of these subjects. Great candidates geek out on how they had to whip out wireshark to figure out some crazy bug or read through the source code of the MS Ajax code to figure out why modal popup was acting flaky.

Lastly, I take the position that anyone can learn a language and write code to earn a paycheck. I want people that care about the craft of software development. I wish I had the perfect way to find those that care but my approach above has paid off so far.

always ask them to write code. A good snr dev will chuckle and breeze through it; but refusals (I have had several) or failures are instant alarm bells

You can then use the code test as a departure point for deeper questions

There are simply too many questions to ask to get a real feel for the interviewee's knowledge, assuming it's not anything more technologically-specific than C#.

I'd really like to be on either side of an interview that goes like this: Interviewer provides interviewee with a sample object model (complexity determined by approximate length of interview).

What flaws does it have? Strengths? How should it change? How can it be made more object-oriented?

This gives the interviewee a broad canvas to show off his skills, without worrying about remembering the answers to a bunch of google-it-style questions.

As the interview progresses, if you do want to learn about his understanding of specific technologies, ask him how he'd implement X, where X is a contract in the object model. (For example, if X was ISummaryView, ask him what UI tech he'd use to implement one (WPF, WinForms, HTML/CSS/JS, etc.))

one thing i would like to share with you guys , doesnt matter if a candidate is new or experienced. The fact is everyone right from new or experienced , experienced a downfall ans wering a question either in writing or by presenting in person. I think the best thing is , give him/her a day to prove , people are taking to much of time and energy to find the right candidate but at the same time there is a chance there ... one of us wanted to prove and let the management decide , by this you are not favouring yourself as an institution but also giving everyone a fair chance by avoiding 10-20 odd interviews ... may be i am wrong open for optimistic suggestions please ...- GK

Make sure you don't hire non programming programmers. After you are sure that the guys knows the concepts, make sure that the candidate is able to write code sample What I found is that many developers are confident and can answer almost everything buy can't write a simple program.

Here is an interesting link ^[1]

Here is the link to Joel's Blog who has blogged about this very topic ^[1]

I would also say make sure you don't hire non programming programmers. After you are sure that the guys knows the concepts, make sure that the candidate is able to write code sample What I found is that many developers are confident and can answer almost everything but can't write a simple program.

Here is an interesting link ^[2]

Ask them what types of design patterns they use and give an example. Also another is to ask them if they have ever totally rewritten an app, library or major piece of code that was written by another developer. Ask them why and what was wrong with it.

I seen this happen so many times that a new person comes to the company does not like/understand others work and just toss it and rewrite. It is painful.

One approach could be to focus on the softer side of development, the "not-so-easy-to-google" stuff, it seems to be easier to educate a dev in how to code properly, than team work, project "lojalty" and common interest in delivering the right things at the right time.

:)

//W

I would expect to be asked about generics, boxing and unboxing (I certainly was in every one of about ten .NET interviews I had last year).

I don't think I have a particularly excellent precis of the topics though, hence I've not posted an answer here....

My suggestion would be to review some of the simpler problems that can be given as a test to see how you go from an idea to an implemented optimal solution. FizzBuzz, reversing a string, basic CRUD operations on a data structure or a basic set of classes come to mind as the "whiteboard" challenge that you may have in an interview.

Unless they need anything to see if you know anything spectacularly specific, I'd swot up on design patterns most of all, followed closely by testing and deployment

quite useful, and there are more topic to share http://jack-fx.com/csharp/post/aspnet-interview-questions-and-answers-csharp.htm

Like most people here say: make sure you fully understand the questions being asked. Even if you don't come up with the right answer, a good interviewer will take note of your thought process and desire to listen.

I was once asked in an interview: how many source files can a single .net assembly be made up of? Weirdest one I've been asked yet.

Be sure to have the standard object oriented programming questions down: what is polymorphism, inheritance and encapsulation?

• Define JIT
• Define GC
• Explain the good and the bad about the two previous technologies

Might be candidates...?

Part from that I loved the answer to the same (PHP) question asked her the other day which went something like this; "Give some examples of the weaknesses of PHP and how you managed to walk around them in previous projects"...

A candidate here for an answer might be Multiple Inheritance or Functional Programming for C#...

Point to ponder... if a person needs to cram for an interview, surely that means that they aren't good enough for the job? If they were good enough, they would already know the necessary answers.