Technical C# Interviews

So back to the world of interviews - things are going well, Company A is drawing up the papers to make an offer; I had an all-day interview with Company B, which seemed to go well; I have an interview with Company C on Monday; and Company D have finally resolved their issues and want to set up a final round interview on Tuesday. Oh, and Company A want to take me out for lunch on Tuesday - somehow I've become a hot commodity, and I'm still quite surprised by it (pleasantly, though).

As I think I mentioned in my last post, most of the interviews I've been to in SA didn't have much of a technical component at all. Here in London, though, technical interviews and technical written tests seem pretty standard (as is an initial phone interview, where they also ask you tech stuff, just to check if you're even worth seeing in person). Most of it's relatively normal stuff, although it can be incredibly difficult to remember syntax and how to do certain things when you're speaking to an interviewer, or writing code in pencil on paper! So it helps to brush up on things that you maybe haven't used in a while, or regularly rely on the MSDN or intellisense to do for you. The things that have come up in my interviews include the following:

• Dispose & Finalize: why you'd want to implement them, why you wouldn't, an d the pattern for implementing them (i.e. actually writing the code to implement them);
  
• The Garbage Collector: basically what it does, how it does it, the advantages and disadvantages of having it
  
• Events & Delegates: explaining what they are, why and where they'd be used, and writing code to use them;
  
• Hashtables: what they are, how they work internally, creating your own hash codes to ensure they're unique, the efficiency of a hashtable;
• Searching & Sorting: why you'd want to, how you'd search for a specific item in a sorted list, updating in-place vs updating and resorting;
  
• Big-O notation, and the efficiency of various algorithms
  
• Attributes: what they do, why you'd use them, how to use them (including custom attributes
  
• OO Principles: explaining what polymorphism is, what the 'new' and 'override' keywords do, given a set of of base and derived classes explaining what the output would be of various method calls and why;
  
• Multithreading: updating the GUI thread from a subthread, the various thread synchronisation methods, deadlock and how to avoid it, what object to use in the lock statement, how to create and start a new thread, and how to kill a running thread, and how to deal with a deadlocked thread
  
• Basic sql queries: explaining the difference between 'where' and 'having', explaining what a query would return, writing simple queries (usually containing a join), the differences between the various types of joins, normalisation

As well as general code stuff like writing a linked list class, or writing a method to reverse or parse a string, or finding all the prime numbers below 1000.

Umm, I'm sure that there's more, but I think that list covers the basic areas. I'm not going to give the answers :P - if you don't actually know the stuff, then looking up answers isn't going to help you even just in the short term, and definitely not in the long term - but if it's stuff you know but isn't sitting at the top of your head, it might be a good idea to go and revise it so that you don't have to struggle to remember during the interview itself.

Of course, there are always the other types of questions too - what are you looking for, what have you done in the past, where do you see yourself in 5 years, can you give an example of a time when you... And those are often more difficult than the tech stuff! I used to cringe when they said, "we've got a written test for you to do", but now I think, "oh good, no more questions for half an hour or so!". In fact, one of the most difficult questions is: "So do you have any questions for me? Because there's so much you want to know, and you don't want to look like you're not interested - but very little of what you want to know can be easily phrased in a question, or easily answered (like, the vibe of the company - what's it like to work here? Or, so what will I actually be doing every day?) and a lot of it, while important, is difficult to ask without giving the wrong impression (what are the working hours? and not just the official ones, but the ones that people actually have to work? how much leave do I get? and, most importantly, how much are you going to pay me?). Most of these get answered along the way, but it's still very tricky all round.

So that's my take on interviews - I feel like I'm kinda an expert at this point :-) Of course this isn't complete - there's all that normal advice that they always give you, like be yourself, be enthusiastic, look interested, dress appropriately... and so on and so on. But that's standard interview stuff, and I'd guess most people know all that already.