I know there have been a great deal of interview questions posted on SO, however I wondered what sort of questions people here ask at C# interviews, interviewing for a senior developer position.

In order to keep this in line with SO principles, please provide a list of questions (or a single question) rather than discussion.

+6  A: 
  • What features do you like about C# and why?
  • Name 3 features you dislike about c#. how would you make them different?
+5  A: 
  • 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.

+1  A: 

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.

+1  A: 

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)

+4  A: 

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.
+1  A: 

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.


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?

+29  A: 

Firstly, 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.

Define a '1' and define a '10' please ..
Well... you don't have to really. It's more to get a rough idea of where the candidate thinks they are. It's not like you'll have separate questions for each of the levels. A one is barely touched the technology; a ten is wrote a book on it. It just helps set the level of the interview: asking easy questions of experts, or expert questions of beginners, leads to an awkward interview. (PS - If they say they're a ten - and they are a ten - then hire them. I said "reject" because most of us never meet a genuine ten).
These questions would indicate I am a senior developer. I haven't even been on one real project ever. I think you should ask about experience.
Jouke van der Maas
+8  A: 

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.

+22  A: 

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". It has a lot of great advise from guys that have done this a lot.

Jon Gretar
I partially agree with this, however asking language specific questions is a great way to gauge their experience with a certain platform. Do you want the hire to spend time coding new functionality or fixing bugs b/c they don't know how to properly catch exceptions, check for nulls or pass by reference?Also, asking about OO features helps to indicate their architecture abilities.
There is lot of good information in there for hyperlink above - How to interview a programmer

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.



+62  A: 

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.


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.

Andrew Myhre
I personally believe in today's day and age, it may not be a great assessment to judge a candidate based on writing code using pen and paper. I mean a candidate can really be good even if he is not able to do it. You need to take all other capabilities in to consideration as well. Just an opinion.
Although I don't have a problem writing some code off the cuff--please don't make me write it out. My handwriting is illegible and embarrassing--at least offer me a keyboard.
Bill K
Yeah I've since reconsidered my view on this. I'm more interested in the intentions conveyed by pseudo code and I agree, using a pen is tedious and there's no reason to arbitrarily handicap an applicant by denying them the tools they'd normally use to perform the task.
Andrew Myhre
@Andrew, Arbitrarily handicap via handwriting? The ability to write and communicate without a keyboard is arguably a test in and of itself. If a person applying for a senior dev role can't communicate without writing code, they're probably pretty useless.
Robert Paulson
@Robert is true, but using a *pen*? At least let me pseudocode in notepad.
Kirk Broadhurst
I'd also ask what languages they know. My experience is that the truly great developers know multiple languages - and most often not just variations in the same family (C++/Java/C# being the most common).
@Andrew, I really wish more interviewers would inform the candidates (before the actual interview) that they plan to have a "pen and paper" test. It would save ALOT of my time!
Because intellisense has "dumbed down" myself and I am sure a whole bunch of other developers (hit the . and tab and continue coding). Using Visual Studio, the html colors to indicate that your code is correct or the squiggly lines to show that you missed something, using the little pop up bubble message display when intellisense pops up and you and hover over the property and methods that will tell you what "SelectedValue" is vs "SelectedItem" vs "SelectedIndex". Not to mention the compiler (paper can't compile); Then there is the thing that you can google code / syntax; Why memorize code?
I would rather just tell the client recruiter "Thanks, but I have never gotten a job where I was pen and paper tested" and just move on to the next open position. I am blessed to be in an industry where I can be a bit picky. And its not like if I can code on pen and paper, that I will also know how to use good logic. I am currently doing maintenance where the original developer made a database call to return records to a gridview, then someone else took over, they made a call to the same stored proc to export the records to excel. AARRRGGGGGHHHHHHHHHHHHHHHHHHHHHHHH !!!!!!!!!!!!!!!!!!
At my last corporate gig we would require numerous written examples from candidates, but for the source code test we allowed (even encouraged) fudge code -- syntax didn't matter. The goal of course was to verify they understood legitimate coding structures and practices as opposed to their ability to 100% memorize contextual syntax.
+4  A: 

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.

+7  A: 

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 changes 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.

+2  A: 
  • 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
Philibert Perusse
+2  A: 

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?"


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.

Brian G
+24  A: 

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 ans 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 agree with this answer, although a couple feelers for basic C# doesn't hurt. Btw- my trick question for web dev applicants is "What's the difference between HTTP Response codes 500 and 600?" :)
"f 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"Perfect and clever approach
+50  A: 

Lots of good questions here!

Scott Hanselman
I guess you're a bit biased about that though Scott ;-) seriously though, those questions are great.
Yep - great blog post Scott
John Sibly
I bet watching you interview people would be entertaining. :) Several of those would burn me.
I'm not so keen on this question:"What ports must be open for DCOM over a firewall? What is the purpose of Port 135?"Why should someone have to learn that? Why not just google it
Dave Hillier
I wish there a second version of the list which listed with the answers :)
Ramiz Uddin
@Dave Hillier: Having these types of questions are by no means "hurtful" to the interviewing process. A very specific question like this one can do two things for the interviewer. If they get it correct, it lets them know they probably have some real world experience in this space. If they do not know it, they should be able to tell you how they might look something like this up. This could then lead into an entirely new question about finding reliable answers to question you don't know, what process they use, do they copy paste it, or do they really learn what they looked up. Legit!
@Dave... what would you do if google was down? Or got taken over by Microsoft ? Or The Russians invaded ?

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.

+3  A: 

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!!


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

Andrew Bullock

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.

Touche my friend. But I counter that with an analogy. If I haven't driven a car with a manual transmission in 10 years but, for some reason, the driving test I am currently taking is in a manual transmission. Wouldn't it behove me to at least practice so the focus is on my driving.
I agree with Craig. Interviewing is a skill that many of us only need for a few weeks every few years, give or take. For me, prepping for an interview is more about forming talking points about what I know, rather than cramming what I don't know.
Jonathan S.
"Fortune favors the prepared mind"
Steven A. Lowe
Heh. One could argue, then, that you should hire the people who seem *least* prepared. If someone's good at interviewing, then it means he's spent a lot of time job-hunting, right?
Problem with "preparing" is that you seem to know more than you really do, so if/when you get hired, the employer ends up with "buyer's remorse" and wishes they actually hired someone who knew how to program rather than how to game the interview.
yea, its like the LSAT, youre better off not studying, and going in fresh
Shawn Simon
Craig, you know the subject and you know it. But how does the interviewer will understand that ? Hate it or live it, these types of questions are bound to come up in 95% of interviews.
+5  A: 

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.

Eric Z Beard
I don't consider most of these questions to be pertinent or indicative of a candidates abilities. They are simply trivia.I've been developing .NET applications since 2002; ASP.NET as well as desktop and mobile devices. I can't answer more than 3 of those questions off the top of my head.
John Kraft
Really? I could answer about half off the top of my head and know where to find the answers for the rest. I especially like the last 4. Very nice questions indeed.
There's nothing wrong with the questions. They are nice things to know, but they give no indication of the candidates abilities. I'm more concerned with if they know how to use ViewState rather than how it works under the hood. If I need to know something works inside to use it, it's not worth using
John Kraft
Sorry, John, I disagree. I feel it's incredibly important for a developer to know how the framework works, all the way down to the lowest level possible. Otherwise you get stuck for days and weeks at a time troubleshooting things you don't understand.
Eric Z Beard
I guess I just look at it from a utilitarian point of view. I know how to drive my car to work every day. I don't need to know how the motor works, or the brakes, or windshield wipers. I just need to know that when I step on the gass, I accelerate; the brakes, I slow; etc. continued...
John Kraft
Not knowing how my car works, and, likewise, not knowing, has no effect on how well I drive. I still get from point A to point B.
John Kraft
Ok, using the car analogy, as developers we're using all the parts to make our own custom cars, or mashing 6 cars together to make a giant transformer car, and when it doesn't work right, we have to figure out why.
Eric Z Beard
@John Kraft: except you don't drive the car, you're building it, your users are driving it. Maybe you shouldn't know how the on board computer works entirely, but having as much knowledge about mechanics and the parts does make you a better car builder.
Pop Catalin
I appreciate the comments on the car analogy, but I still disagree. I'm the user. I'm using the ViewState, not creating or maintaining it. I need to know how to use it, not how it works. If I need to know how it works to use it better, it was written poorly.
John Kraft
@John Kraft if I am building a car and pick a MacPherson suspension type and my handling is bad, I need to know how it work at a low level to fix it or make right decision to replace it for another type.
@John Kraft - Not knowing how the car works is all well and good until it breaks down. Then you either need to know how to fix it, or pay someone else who does.
Adam Luchjenbroers
If your car goes wrong you go to the mechanic. If your software goes wrong you the developer need to fix it. So the car analogy doesn't really apply here. The more framework knowledge you have the better chance you have to figure out a possible problem and fix it.
Still, questions must be relevant to the topic at hand. Don't ask ASP.NET questions if you do not use a lot of, for example. SOme people specialize ;)
+2  A: 

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

+2  A: 

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.

Andrew Cowenhoven
+1  A: 

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.

Ken H

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....

Richard Ev
You were interviewing for .NET jobs 10 years ago?
My corrected.
Richard Ev

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.

JB King
+1  A: 

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.

+1  A: 

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?

Brian Genisio

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?

+8  A: 
  1. What are Generics ? How do they affect performance.
  2. How would you define an Anonymous Delegates ?
  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 ?
  • 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#...

Thomas Hansen
+2  A: 

How about this for your question:

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

+1  A: 

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

When was the last time you actually used boxing in code? I've never needed it.
What you need to know about boxing is *when it happens that you're not aware of*. Whether you use it deliberately or not is irrelevant.
+2  A: 

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?

Steve Hayes
This belongs in an update to your original post. It isn't a forum, which is hard to remember sometimes.
I think it is similar to my college physics professor. He always gave us the sheet of formulas to use for tests. He said unless the formula was in his field and he used it every day that even he would have to look up formulas. Any programmer can look up the syntax for a command or the $50 name of a method - as long as he knows the methodology. How you solve problems is much more efficient and telling than whether you remember the steps taken internally by a compiler.
+1  A: 

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.


quite useful, and there are more topic to share


I have consolidated .Net Interview Questions at

.Net Framework Interview Questions:

ADO.Net Interview Questions:

ASP.Net Interview Questions:

C# Interview Questions:

Visitors are also requested to share Interview Questions at

+1  A: 

here is a interview website,


Here are some more C # Interview questions

+2  A: 

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.

Jeff Bridges
+1  A: 

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.

+1  A: 

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

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


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.))

Sam Pearson
+1  A: 

Here's a nice link with 300 videos on interview questions which covers C# , sql server , , WCF , WPF ,Azure , Design patterns etc

I have always used that site for interview preparation

+1  A: 

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

"How do you inherit from a class in C#? Place a colon and then the name of the base class. Notice that it’s double colon in C++." - Umm, no. C++ uses a single colon for inheritance also. These are actually some pretty lousy questions and even lousier answers.
Greg D

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

+2  A: 

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.


check out some ques listed on they seems to be good.

+1  A: 

Here is another link to C# interview questions