In love with Kathleen['s writing]

I'm distinctly ambivalent about admitting this, but I think I'm in love with Kathleen Dollard. In spite of being a happily-married man with a beautiful baby daughter, something about her writing just does it for me.

It might be the fact that Kathleen doesn't just talk about code generation, but she actually walks the walk as well. I don't think that code generation will necessarily save our sorry developer souls, but we simply can't go on building every piddly little business application like master craftsmen. It simply doesn't scale. SolidCore will be my attempt at climbing this particular Everest.

Or it might have been this explanatory comment on Dino Esposito's blog recently. As well as being an excellent summary of Shadows (in VB) versus new (in C#), it includes the wonderful line: "If you design a system dependent on this behavior, you are a very sick person and I do not want to invite you to any tea parties." I know it's a cliche, but her writing really does fly off the page at me.

Or maybe it's the fact that she appears to be just as involved in debugging as myself.

But...her recent post on hiring .NET developers is not that convincing, at least to me. Especially the emphasis on asking the better candidates to take .NET certification tests, and not putting too much stock in successful projects. Of the best dozen or so developers I've encountered in the last 25 years, I'm not sure that a single one would be guaranteed to pass a .NET certification. And I'm less worried about the quality of the code than the delivery of successful projects - I feel that it's just too easy to get caught up in creating elegant, performant, maintainable code, all at the expense of getting the project out of the door. It doesn't matter how cool your code is, it needs to be shipped. Show Me The Output.

Perhaps rather than criticise, I ought to state what I look for when hiring a (.NET) developer. Bear in mind that I don't ship shrink-wrapped software - all of my work consists of custom software, so that brings a definite slant to my hiring activities. But if you're ever interviewed by me, this is the background preparation that you'll need :)

1) First, I want to hear a good description of a recent successful project that the candidate completed. For me, the ability to communicate well, both technically and with enthusiasm, makes a candidate stand out from the crowd. If she can convince me that the project was technically interesting, and that she solved some non-trivial problems, she's already half-way home.

2) I like to discuss the .NET basics. How well can the candidate discuss stuff about types, namespaces, assemblies, events, error-handling, and so on. I find that I can also get a good handle on a candidate by knowing what technical books he has read recently.

3) What the coolest coding hack that the candidate has ever done? What was his biggest technical screwup, and what did he learn from it?

4) Having picked up on some of the candidate's professed technical strengths, wherever those may lie, I like to drill down until I reach the seabed. I want to feel the dirt between my toes. Does she really understand what she's talking about, or does she start to duck the harder questions? When I was hiring VB.Classic specialists, binary compatibility was always a good subject, because you can talk about this at many different levels. In .NET, something like delegates might serve as a good discussion point. But more often, I'm guided by the technical subject that the candidate seems to be most familiar with.

5) What does the candidate feel is his Unique Selling Point? What makes him different to the other developers that I'm interviewing, so that he stands out from the crowd? What makes you stand out from the crowd?

Of course, there is no silver bullet when it comes to hiring a developer. It's hard to measure somebody's technical abilities in an hour or two, and it's even harder to dig into somebody's work practices and whether he or she will match the team chemistry. I've interviewed over 500 developers, and I still don't get it right more than perhaps 50% of the time. This is a seriously hard problem.