(C#) Interview Questions

Seems to be the trend at the moment to post some interview questions on your blog. So not being one to buck a trend, I thought I would do the same.

Some of the questions I have seen are more pop quiz types questions. For example: Name 5 C# data types?
To me these questions like this are stupid. I don't care if someone can recite the entire class library word for word, I care about how much of an understanding of actual programming someone has. My questions are more aimed at creating an insight into how someone thinks, and perhaps starting a discussion. I prefer open ended, no one right answer questions.

Without further ado, here are my questions...

1. What are you thoughts on the following?:

try
{
...
}
catch (Exception ex)
{
...
}

The answer should create an insight into how deeply the developer thinks. I think catch all exceptions are the devils spawn, but would be interested in learning justification someone might have for using

2. Name your favourite feature of .NET 2.0? Why?

Just a matter of interest. Should get the person talking.

3. Explain the difference between an Interface, and an Abstract class.

If the person knows the difference then it shows they have created bases classes or at least know about OO programming.

4. In your opinion, when should you use each?

Just to try and see if they have an understanding of the difference, not just know what each is.

5. How do you define the n-tier model?

Again it should be reasonably clear from the answer if the person has actually don e n-tier design/programming

6. When passing data between tiers, do you prefer passing a custom class, or something else such as a Dataset? Why?

Always interesting to hear peoples approach to this. Also it demonstrates what level the person has. I.E a junior - intermediate may not have had to worry about this before.

7. Who is Anders Hjelsberg?

I would want people who take an interest in the language they use. If they do then they will know who Anders is, or at least heard of him

8. Explain the terms Pascal Casing and Camel Casing.

Most people should know what these mean, although not a show stopper if not

9. Explain your coding standards for: a member variable, a parameter, a method, a class an interface and a local variable.

This question just shows if people have thought about standards or not. Any good developer should have a fixed standard they stick to. It is good to discuss their reasonings for using a particular standard. For example I use m_(camelCase) for member variables because I feel it is easier to read and harder to transpose the variable by mistake.

10. What is your understanding of a business layer?

Everyone has a different idea about what a Business Layer should be and do.

Coding Tasks

Here are some coding tasks that could be given at an interview. Obviously not enough time to do them all....

1. You are creating a basic accounting application. Create a business layer stub which would allow the application handle Creditors, Debtors and Invoices. Just create any classes needed, the variables needed and the method headers. In each method, just add a comment as to what the method will do. As a starting point, the database has been created where the business data will be persisted to.

I think this would be an interesting task to give. It shows the interviewee's ability to take a problem and apply their skills to it. We're not really that interested in the actual coding, just the design and thinking behind it. I would expect most people to either create custom classes based on the database, or create an approach based on datasets which will be passed between layers. I am a student of the Rocky Lhotka approach to business layers where the business classes shouldn't just replicate the table design, it should define a behaviour, and can include data from several tables.

2. Create a simple Webservice that given two numbers, returns the sum of these two numbers.

3. Create a console application that consumes the Webservice created above.

Fairly simple task that anyone worth hiring should handle in 30 minutes or so.

4. Give them an application with a number of bugs, some compile time, some runtime and get them to fix as many as possible in a given time.

5. Explain to the interviewee that they can use any datastore they like - have MS Access, SQL Express, SQL Server installed on the test machine - create a simple application to store contact details.

Give no hints on what you are after, give them a set time (60-90 minutes) and then let them loose. Good developers should work out what is important given the time constraints. I would prefer a well engineered solution that wasn't finished, than a slap happy finished product. Above all else it should show how people think about design and give an indication about their ability. Afterwards, let them explain why they did X and give justifications for that approach.

Comments welcome....