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.
Best interviews make the developer actually write some code, maybe a small project or task.
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.
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)
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:
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?
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:
Intermediate questions:
Hard questions:
BUT as I mentioned earlier, you're far better off asking more general coding questions, than focusing on C# specifically.
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.
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.
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'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:
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.
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.
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.
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.
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.
Lots of good questions here!
http://www.hanselman.com/blog/WhatGreatNETDevelopersOughtToKnowMoreNETInterviewQuestions.aspx
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.
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
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.
Here are my "feeler" questions that I use to see how deep I can dig into someone's .NET knowledge.
Talk about the differences between different .NET versions, and your experience with each.
Do you favor C# or VB.NET. Why?
What's the difference between "override" and "new" in a method declaration?
Does .NET support multiple inheritance?
How do you display a table of data on an ASP.NET page?
Explain the ASP.NET postback mechanism.
Explain how ViewState works.
Explain different ways of calling methods asynchronously.
Explain how the JIT compiler works (from a high level)
How would you troubleshoot a memory leak in a .NET application?
Explain IIS 6 ASP.NET security and how it applies to an ASP.NET website.
"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.
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.
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.
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?
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?
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#...
How about this for your question:
Would you please sit down here at this workstation and write some code with me?
Tell about boxing, unboxing and difference between value and reference types.
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?
Ask them a couple of really basic questions. eg:
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 http://jack-fx.com/csharp/post/aspnet-interview-questions-and-answers-csharp.htm
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.
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.
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.
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.
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.))
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://tinyurl.com/yepftou
I have always used that site for interview preparation
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
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 http://csharptopicwiseques.blogspot.com/.... they seems to be good.