Iñigo Montoya: "Naturally, you must suspect me to attack with Capa Ferro"
  Man in Black: "Naturally… but I find that Thibault cancels out Capa Ferro. Don’t you?"
Iñigo Montoya: "Unless the enemy has e'studied his Agrippa… which I have."

       - how to spot REAL talent (in a fight to the death), from "The Princess Bride"

How can you identify the "Evil Mort"s, and the wrong kind of "Einstein"s, during an interview, in order to avoid hiring them?  Below, are the actual guidelines I recommended at my previous company (updated with .Net 3.0/3.5 references), which we used to evaluate new hire candidates for open .Net engineering positions.  I purposely used very open-ended questions intended to maximize the candidate's opportunity to sell themselves and demonstrate some evidence of passion, a willingness and ability to learn, and sensitivity to maintenance and process concerns... IN ADDITION to testing their understanding of .Net.  We needed candidates who were still able to support unmanaged C++ and MFC code, so each candidate first underwent a separate, fairly rigorous, C++ exam, and my portion of the interview didn't involve any actual coding.

New Hire Candidate .Net Interview Questions

We should be seeking PROFESSIONAL Windows developers – candidates who not only have a good understanding of .Net (as well as MFC and C++), but who are PASSIONATE about software, and who can also think in terms of ARCHITECTURE and development PROCESS.

Many of the questions below do not have “correct” answers. We’re looking for responses that demonstrate thinking beyond simply implementing assigned tasks (ie: “I think unit testing is a waste of time because…”, or “I prefer Lowy’s component focus to the inheritance focus in Microsoft’s class design guidelines because…” etc.)

General (10 mins):

1)  General questions, based on examination of the person's resume

What made them decide to leave companyA after 8 years? Why did they only stay at companyB for 6 months?  How many developers were on projectY? etc.

2)  Try to separate development technologies in which they have MEANINGFUL experience (and interest), from the usual dump of token resume keyword references.

Do they consider themselves to be primarily a C++/MFC developer with some .Net experience, or vis-versa?  Do they have more of a back-end, or GUI, focus?  Has their .Net experience primarily been with ASP.Net, or desktop clients?  Did their C++ experience extend into COM/ATL, or C++/CLI?  Any managed or unmanaged DirectX?  What experience do they have with specific remote communications and data access technologies? etc.

3)  What .Net authors/resources do they recommend, or consider to be required reading for developers, and why?  Do they track any RSS feeds?  If they can’t come up with any .Net examples, what about resources for other development technologies?  What was the last development-related book that they read?  How much experience with .Net 3.0/3.5?  Have they worked with LINQ, Lambdas, Blend...?  Have they heard of F#?  (ie: do they stay CURRENT with engineering practices and technologies?)

Qualified developers should know some of the Windows dev. community luminaries, and have definite opinions on good (and bad) books and online resources (favorite Blogs etc.).  I would probably expect them to name MSDN Magazine (certainly MSDN online), and at least one of Richter, Sells, Lowy, Petzold, Adam Nathan on WPF etc.  Non-.Net references might include Scott Meyers, Martin Fowler, Kent Beck, Bob Martin, Richter’s Advanced Windows, Don Box on COM, Prosise on MFC, MFC Internals…  More than any other question, I think this identifies desirable candidates.  Developers who are not actively keeping up with the evolving technologies are dead weight.

Attitude Check (20 minutes):

1)   What was the “best” project they were ever on? Why (what made it so good)?

We should see some evidence of PASSION in response to this, and the next question.

2)   What was the WORST project they were ever on?  What made it bad, and what should have been done to FIX it?

Developers who are passionate about software are constantly analyzing the development process, and will have strong opinions about how things OUGHT to be done – while still being reasonable about the need to accommodate trade offs for valid business concerns.

3)   What would they consider to be important coding guidelines?

They should express moderately pro-guideline feelings, and be able to list at least a few specific examples, such as not exposing member fields, not using magic numbers, avoiding multiple classes in a single file, some reasonable approximation for when method size could indicate a problem…  Ask how they would ENFORCE a coding standard.

4)   Determine the extent of the candidate’s understanding of (and attitude toward) modern STRUCTURED development cycle and process elements.

Ask them to describe the process they would set up to ensure successful delivery of a product, on a project staffed by a small team of junior developers, where they had been given complete authority over all aspects of the development process, able to define exactly what needs to occur, and in what order.  The candidate’s answer should reflect some reasonable middle ground between fascism and anarchy, and might include mention of requirements, design and specifications, code reviews, handling of change requests, unit testing, coordination with QA, milestones, the use of specific tools such as CruiseControl… and possible mention of MSF, Scrum, or other formal methodologies.  Do they like or dislike particular methodologies?  What conditions might cause them to increase or decrease the level of "agility" in their process? 

Base Line Technical (30 mins):

(Ask them to briefly identify, and expand on the significance of, terms they recognize in the list below)

A qualified candidate should be expected to be able to use many of these topics as a launching point, to describe related technical and process issues, whether it be the role of Design Patterns, or technical differences between .Net and MFC, or the trend toward process support in the IDE, implementation of the Dispose pattern etc.

• CLR
• Internal
• Delegates
• DRY
• Singleton (probe general knowledge/use of Design Patterns)
• UserControl vs. custom control
• Dataset
• Marshalling into UI thread
• Attributes
• NGen (probe knowledge of JIT compilation)
• Patterns and Practices Group (PAG)
• Refactoring
• lock(this)  -- do they understand the problems with this pattern?
• Test-Driven Development (TDD), or Behavior-Driven Design
• S.O.L.I.D
• Visual Studio Team System (VSTS)
• Enterprise Library
• Juval Lowy, Chris Sells, Jeffrey Richter… others?
• Reflection
• Xaml
• Extension Methods
• FxCop
• Lambda
• Dispose
• WCF/WPF/WF
• P/Invoke
• Continuous Integration
• Func<T,TResult>
• “Agile” Development
• CodeDOM
• DataTemplate
• ControlTemplate 
• LINQ 
• Blend
• Attached Property 
• MVC/MVP/M-V-VM  
• Routed Events
• EndPoint
• F#
• SOA

In terms of evaluating a candidate's performance in this "vocabulary" section of the interview, when the candidate sees "Singleton" in this list of terms, its expected that they will be able to identify it as a Design Pattern, and we can use this as a lead-in, to discuss the use of patterns in general.  If they display familiarity with the debate over the advisability of USING singletons, it shows that they are plugged into the developer community, and possibly gives some indication of the degree of passion they have on design issues (watch for overly-contentious foaming-at-the-mouth radicals).  If the candidate can discusss double-check locking in the context of a singleton, it provides some additional clues on the depth of their engineering expertise, and if they are aware that CLR rules for static constructors can eliminate the need for double-check locking, it suggests the candidate may be less likely to write unecessary code in ignorance of existing framework features.