Interviewing Tip #3 - Focus on Fundamentals

Apologies for the significant delay, but I wanted to pick up the interviewing tips to get at least two more topics off my chest before turning to other posts.

Jon Kruger is a coworker of mine and I'd clone him and staff 5 of him on every project if I could. Lately, I've been striving to understand what the qualities are in Jon and some other elite developers I've worked with that increase the velocity of the teams they work on. I'll expand more on the positive and negative characteristics of elite developers in later posts, but in regards to interviewing, one of the big things that I now focus on are fundamentals.

I was fortunate to have some good mentors early in my career who pushed me to truly understand the pros and cons of every possible solution. That drive lead me into study of object oriented programming, evolutionary design, and foundational principles of development like SOLID. Uncle Bob, Bertrand Meyer, Martin Fowler, and others instilled within me, if nothing else, enough questions to keep pushing to look at solutions from all angles. I'm far from being the authoritative source on which solution is "best", but I will always continue to ask questions to try to find pros and cons of different approaches.

I've at times let people slide in an interview without much pressure on their foundational knowledge, but no more. I could care less at this point if you know whether SQLException is a Checked or Runtime exception in Java. You better be able to talk through the tradeoffs of having it either way, though. I used to dismiss Bruce Eckel's suggestion of asking potential candidates "What's the object model of a chicken?". I have used it a number of times though and it's a great question to start probing how someone may decompose a business domain into OO concepts. If you get scheduled for an interview with me and you can't argue why you would or wouldn't favor composition over inheritance, then we're not ready to work together. I'm not naive enough to think that all interviewers are like me, but if you can talk at a foundational level on design tradeoffs, I can't imagine an interviewer not wanting to talk further with you or hire you the very same day.

Jon's post here is a great call to arms for software devs. If your interviewer focuses on the APIs of Silverlight or MVC, and not on the benefits or drawbacks of either solution, you need to question whether you are interviewing with the right company. Similarly, if you can't articulate a number of outstanding refactoring items from your last project, or openly debate the benefits and drawbacks of some design decision you made on that project, then you probably need to brush up more on the fundamentals of programming and design before you look at making a career change.