We interviewed with a London-based Hedge Fund last Friday and, as usual, it was interesting. The first guy I saw (head of development) is a graduate of Conchango, a company that writes software of excellent quality using good developers, the latest software technology and techniques, etc. Also, they often kindly host the London Dotnet User Group meetings at their offices near London Bridge.
Naturally the interviewer asks fair questions along the lines of Value Types versus Reference Types and Garbage Collection. Inheritence and Shadowing. So far so good. Only when we get to the Messaging architecture used and extended at the previous client's site is there a little uncertainty. Without the source code, which we didn't take with us, we can't remember enough detail about the implementation from July 2008 so there's one shaky answer.
Next up is a question about our exposure to SQL Server 2005. Yup, we used it. Oh, which bits? That will be the new Try-Catch (after a little prodding about error-handling). We mention not having used CLR functions but being aware of the possibility which leads to a question about the components of the CLR... and we've a blank moment!
The JIT compiler! In fact we mentioned just JIT.
This is *all* that arrives. That's it. Nothing about Exception-Handling, Memory Management, Thread Management, Garbage Collection, Security, Managed Code, Type Safety - this is an impressive list already - Portable Executables nor IL never mind debugging and profiling services offered. Oh, there's more that wasn't mentioned. Code management (loading and execution), Application memory isolation, Access to metadata (enhanced type information) and Interop. Nice.
Then comes the first of a few quirky incidents. Hint: If ever an interviewer testing your C# knowledge offers the Base Class Library as a component of the CLR it's probably worth saying something. To prevent an already lengthy entry from growing needlessly still a summary will do here. When Interviewer #1 is replaced by a senior developer I then learn that impersonation does not work the way I've used it. Apparently, I've misundersood all along that using the identity element in the web config for an ASP.NET web application will not allow me to use credentials for a SQL Server connection. Maybe at that point I should have just looked it up on my iPhone and shown him this:
<system.web>
<identity impersonate="true" userName="domain\username" password="password" />
</system.web>
Of course that might have seemed a bit smug. Both nice guys. Both almost certainly good developers. I'd still like to work with them on the enterprise reporting solution due by the end of the year. However, during my next interview we won't assume that the interviewers have a monopoly on .NET understanding.
Subscribe