Geeks With Blogs
Blog Moved to Blog Moved to
I'm still prepping a few posts on F# and Design by Contract (DBC), so stay tuned in the next day or so.  But, I recently read through the altdotnet mailing list about conducting interviews and phone screens.  Jeremy Miller had a great response to this that I felt needed its own response.  I've been interviewing people all throughout my career and I've definitely picked up on things as time goes on, honing the craft as it were.

Cloning Myself

It's true in the past I've been guilty of wanting someone who thought like me, shared some of the same ideals or even solved problems like I do.  Soon after, I came to realize that we needed fresh ideas and that a mono-culture of mini-me's isn't the right answer for this.  Instead, I've come to appreciate that there are at least six answers to every problem in the software world.  Some of course are better than others and more applicable, some most are equally valid.

Sometimes, I would have slapped my forehead if they didn't know many of the GoF patterns and their applications.  Instead, this person worked in a SOA world, where many of those things are nice to know, but not as required.  Geez, they didn't know you should use a singleton pattern here and a decorator pattern there?  What's wrong with you????  Or something like that.  That's something I had to get over.

The Lightning Round of Trivial Pursuit

In the past, I've gone through many phone screens where it just seemed like they were reading off a sheet of paper, line by line asking a question, without having known the answer themselves.  Just when you thought the questioning was over, ok, done with C#, now time to move onto ASP.NET, now time for SQL Server, now time for BizTalk, etc.  My mind was swimming a bit more than if I were on Jeopardy during the speed round.  What's worse is that many of these answers were quite obscure and you wouldn't know about them unless you hit a certain pain point and had to do the research yourself with any given point technology.

Of course during these lightning rounds, some like to pull tricks out of their hats that nobody in their right mind would know unless they've felt the pain and had to do workarounds.  They are kept in the back pockets in case they feel that the interviewee is doing too well.  I know, I've been there!

Where I've Gone

I've been more of a patterns and practices person myself.  Instead of asking very pointed question about a certain BizTalk adapter's properties, I'd ask when you would use what and why.  I also like to have them explain BizTalk patterns such as Serial and Parallel Convoys and why they matter.  Pick some favorite code of yours and explain why it is.

I like to give logic puzzles and see how they work through an issue.  For example, the elevator queuing problem is always a great one to ask.  Ask them how they would design something like that with given parameters and off they go!

Better yet, if in a room with a whiteboard, the FizzBuzz problem is always a great one to ask.  It's a basic logic puzzle that has little to do with the language implementation, as I've done it in C/C++, C#, Java, Ruby and even PHP.  Any pseudocode will do.  Also, I'll show a screen of code and ask for code smells and possible refactorings.  It's always interesting because you'll get a new answer each and every time.  Heck, you might learn something.  But, I'd like to see if they grok TDD as well.  It's not an easy thing with just an hour interview, but, given a scenario, they should be able to handle Red, Green, Refactor with just a simple ASP.NET MVP pattern, testing a Presenter.

It's about looking for passion, looking for willingness and eagerness to learn.  I love it when a candidate actually blogs, and contributes to the community as a whole.  That shows to me true dedication to the craft of software development.  The willingness to get up in front of a crowd and explain what and why they did a certain thing, and defend it is great.  But, what's also great is that they listen as well.  I've had plenty of cocky interviewees and it's a big turnoff.  Yes, you're confident, but it also shows you may not listen to your customer either.

Of course the conversation won't be completely devoid of technology, but the when to use what and why is pretty important.  For example, knowing between using SQL Server Broker, versus SSIS versus BizTalk is a pretty good topic to know.  When would it make sense between a WPF application, a WinForms app or a Web application?


So, over time, in my adventure in the software world has evolved, as has my interviewing style.  It's less important of getting clones of myself, but more of diversity of ideas, the willingness to share, mentor and learn.  It's not about lightning rounds of trivial pursuit, it's a way of tackling problems with logic.  The technology comes easier when you know which angle to tackle that problem.

Now, back to your technology posts!

kick it on Posted on Sunday, January 27, 2008 11:57 PM Off-Topic | Back to top

Comments on this post: Interviewing Redux

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Matthew Podwysocki | Powered by: