Archive for March 2014
Years ago I was interviewed by a someone who really liked SQL Server and they liked SQL Triggers in particular. So we started the interview and they asked me a question about triggers and I unashamedly deferred since I knew what a trigger was but hadn’t been using them. It’s something I could easily look up as soon as I actually needed the knowledge.
We moved on but they decided to keep asking me questions about triggers and finally some other SQL topics, almost dumbfounded that I didn’t have this kind of knowledge packed away in my head. I ended up taking that job, but knowledge of triggers played almost no part in my success there.
They thought the questions that would shed the most light on my ability were trivia questions about syntax and such. There is nothing wrong with someone who can tell you the ins and outs of T-SQL, C# or some language, but that kind of knowledge doesn’t tell you if the person can deliver a good product or feature in your code base.
If your interviews are primarily trivia, you are mistaking what a software developer does. You probably think that a developer spends the bulk of their time writing code, when in reality they spend far more time thinking, talking, drawing and planning than they do actually writing code (at least this has been my experience).
You want to hire someone who can interact in your environment and can make good judgement calls about how to design a product, can talk with a client or can add new features to your product. If your focus is on questions like “do they know the syntax for creating a trigger” you are missing the more foundational questions that could actually tell if you if you want to hire the person.
If you want to know their technical skills, have them code in an environment that is familiar to them. Don’t ask them to write a C# in a raw text editor. If your shop uses Visual Studio, give them an exercise in Visual Studio or at least let them pick the environment of their choice. What you are looking for is how they go about solving problems. Do they ask questions at the right time? Can they lay out an algorithm? Do they use any tools or techniques to validate that their design is good and produces valid output? What information do they look up and what do they just know?
If you ask trivia questions in an interview that is fine, but don’t stop there or you will miss evaluating your candidate’s most important abilities.