Wednesday, September 28, 2005

Interviewing Mode

Four people are coming in today to interview for a position on my team. The requirements are heavy C#/WinForms experience, architectural skills, and a small understanding of finance. In my old job, I probably interviewed at least 100 people for 2 similar positions, and we could not get a decent hit. The client ended up hiring a .NET superstar away from one of the Wall Street brokerage houses.

One of the main problems is that recruiters will doctor a candidate's resume so that it appears that they have WinForms experience. So, a typical line on a candidate's resume will read something like this:

I did an entire web-based .NET application using C# and WinForms.

With the advent of websites like, everyone knows the standard .NET questions. I would like to hear what your favorite .NET, C#, and architecture questions are. Feel free to post a comment.


Patrick Chefalo said...

So what's the fascination with using C# for WinForms? Aren't WinForm programmers more likely to be VB programmers? Here in Rochester we had a similar requirement; I guess I don't get it. I don't think that C# has performance or maintenance advantages over VB.Net for Winforms, and you greatly limit the field for interviews. Seems like a waste of time and money.

marc said...

We get the requirements from our clients, most of which are high-tech savvy Wall Street firms. If they want C# developers for a project, then we get them. If they want VB developers, then we get them as well.

Almost all development on Wall Street is done in C++ or Java. C# is just starting to take hold. Clients tend to prefer people who came up the "object-oriented" ranks, and they see C# as an extension of C++ and Java. Yes, a lot of WinForms development had taken place using VB in the past, but as Microsoft narrows the playing field between VB development and C# development, we are seeing less and less requirements for VB.NET skills.

Deglan Holland said...

When interviewing a candidate I like to begin with a brief overview of the engagement, and then ask them to describe any relevant previous work. Sadly, you would be surprised (or maybe not) at the number of candidates who aren’t able to cogently describe the problem domain, overall architecture, and, crucially, their contribution to the project. From an experienced developer or architect I’d expect their description to clearly identify application styles and key abstractions in addition to the technology employed.

On the tech side, everyone these days has design patterns and frameworks all over their resume. Try asking a candidate to identify the patterns they have most frequently come across and the benefits and constraints of those patterns. Inevitably, the Singleton always seems to arise in discussion, weaker candidates often are only able to muster a description along the lines of “it ensures you only have one object” – follow up with questions on objects vs. types and ask for an implementation (this stumps many!!!), stronger candidates I would expect to express some concerns with regards to over-use of the pattern – surrogate global/effect on encapsulation – this can then lead into many of the pattern variations (e.g. threadleton, etc.), and you can move on with domain specific questions….

Matt Davey said...

Ignore the question, just pair programmme for 1 hour, you'll soon know if U want to hire the guy. Assuming U are that agile enough to go down the road.

marc said...


Interested to hear if you have interviewed that way in the past, and what kind of programming problem you poseed to the candidate for the pair programming evaluation.

I am not a fan at all of pair programming.. more on this later.