Showing posts with label interview. Show all posts
Showing posts with label interview. Show all posts

Saturday, July 7, 2012

More interview questions

We had a coding competition at work last week. We had an hour or so to code-up a solution to:
I want to simulate a vote by providing a question, valid responses, and an integer representing the voting population size.
When the vote occurs, there should be 1 random vote for each member of the voting population.
 The entries were judged on the following criteria.
  • Testability
  • Maintainability
  • Accuracy of solution
  • Structure of solution files
I've uploaded my contribution to GitHub. I didn't win. I made a few weird assumptions (that I've corrected in the code online) and for some reason went off on a tangent playing around with JSON serialisation. However, the wining solution wasn't particularly different to mine.

The purpose behind the competition was to use this task (or something similar) when interviewing candidates. I guess the people interviewing wanted a base-line to work off, that's why they had the staff do the task.

Anyways, it was quite fun. I've never done anything like that in a workplace before.

Friday, July 6, 2012

Interview questions

I've been asked the same questions during interviews in the past. The two that come to mind are:
  1. What's the difference between a clustered and non-clustered index in SQL Server?
  2. What's the virtual keyword in C# mean?
I finally got around to looking up the answer to the second question. I generally don't override methods, so I've never had much use for it.

The short of it is that virtual is required if you want to override a method of the base class. If you don't supply virtual, the best you can do is use the new keyword to create a completely new method that just happens to have the same name of a method in the base class. To take it a bit further, sealed will prevent any further overriding down the inheritance chain. Therefore;
  1. a base class may have a method with virtual assigned to it;
  2. deriving from 1, you could override the method;
  3. deriving 2, you could sealed override the method;
  4. deriving 3, you can't override any more (but you could new the method);

Is this an important question? Not in-itself. I was offered the jobs without knowing the answer.

I have written an example gist to further clarify.