Over the years I have had to endure many technical interviews from both sides of the fence. As a freelance/contract software developer, I usually have to endure 10-12 technical interviews a year in the quest to land a new assignment. Inevitably once I land a new assignment I am usually presented with the opportunity to interview my new potential team members.
One thing I have noticed of the years is that there are definitely wrong ways to go about technical interviews software developers, however there don’t seem to be a 100% right way. Interviews in any profession are notoriously difficult, which explains the reason why LinkedIn is packed with articles and links to websites offering tips and strategies to all and sundry on how to successfully overcome the dreaded interview process.
The following post is not a definitive guide on how to successfully master the technical interview process, but it may contain some pointers as to what in my opinion are obvious failing strategies. This post is also partly inspired by Mitch Laceys – Technical Interviewing – You’re doing it wrong , which also comes at this from a different angle.
I can’t tell you how many times I have had to undergo a so-called technical interview where questions have blatantly been selected from Scott Hanselmans, What Great .NET Developers Ought To Know (More .NET Interview Questions) . I must admit there are some great questions there and anybody wanting to spend a little time googling the answers to those questions, they are accompanied by many number of stack overflow posts!
The issue I have with this approach is, you are not Scott Hanselman your organisation is not Scott Hanselman, so why are you interviewing like Scott Hanselman?
Your organisation is unique, your software will in some way be unique and probably the way you have solved certain problems is unique. What you are looking for is an individual who can assimilate into your unique team, work practices, environment and software framework. To be honest whether the candidate has Jon Skeet level of understanding of the C# language or not will undoubtedly have no bearing on the outcome of your project. What will have a bearing is how the individual will interact in a team environment. Software Development is a team sport and building a championship winning team requires a lot more than buying star strikers.
I haven’t met a software developer to date who doesn’t consult Google, Forums, Manuals or any other knowledge base to find the answer to a technical question. I’ve even written blog posts in the past discussing a technical discovery, only to come across the same issue a couple of years later and in consulting Google for the answer come across the very same blog post which has the exact same answer I was looking for!
Developers tend to have goldfish memories, and frameworks come and go at a rapid pace of knots, coincide this with the fact that the average software project these days will consist of a number of frameworks so remembering all the finer points of all frameworks to be able to answer at a technical interview is quite frankly not worth anyone’s time!
Ever since Joel Spolsky advocated in The Joel Test: 12 Steps to Better Code that candidates should write code during an interview, some organisations have taken to resort to this as the only measure on how to gauge potential candidates. Typically I try to avoid such organisations like the plague, from personal experience these are not the types of places I would choose to work again.
Based on my personal experience of 2 such organisations, the issues within in the organisation are far deeper than how the software is developed. This is coupled with the fact that if you’re a contractor like myself you will have no doubt that no two organisations make use of the same combination of tools! Let alone software development practices from organisation to organisation differ, and setting the expectation that a developer should deliver a solution which is comparable to your defined level of acceptance in my opinion is lunacy.
One example I have experienced of this, is that I completed a test for an organisation based on multi threading, which I found interesting but once I started the contract I found out that the application they were implementing did not have one element of multi threading involved in it at all. They just thought that having an understanding of how multi threaded applications work, would be a good benchmark to have for all new software developers! It is suffice to say that the organisation is no longer in business today and I elected not to renew my contract after the initial 6 weeks!
An approach that has personally worked really well for me, when I interview potential candidates is that I insist they bring some of their own code to the interview. This could be a personal project they have worked on, or a contribution to an open source project or even when internally recruiting a snap shot of the current code base they have worked on. I ask the candidate to take me through his code, explaining to me what it does, where the initial idea came from, why he chose the tool set he’s working with etc. This provides me with a lot more insight into the mind of the individual in question.
Following this process provides me with an opportunity to assess a number of key attributes I like to assess in individuals:
- How they formulate ideas
- Approach to problem solving
- Their passion for software development
- Their individual coding style
- what good and bad habits they have
- Understanding of the Software Development Life Cycle
- Presentation skills
- snap shot of how they would interact in a technical setting
This approach also enables me to understand the developer on a more human level, rather than just some Code Emitting Unit. It also presents the candidate with his own unique opportunity to stand out, rather than pigeon hole him with all the other cyborgs!
Problem solving questions
Ever since the mythical interview questions from Google or Microsoft were published , 15 Google Interview Questions That Made Geniuses Feel Dumb , there has been an increase in the number of companies that employ this type of tactic to emulate the success of their peers. This is just plain stupidity in my opinion because for a start your company is not Google or Microsoft. Your company does not work on the types of projects employees at Google or Microsoft would work on and also your company will more than likely not offer the types of bonuses or incentives that these two behemoths are likely to offer their elite.
I absolutely agree with taking note of the strategies and practices these supposedly great company’s implement, but don’t try emulate them! There must be unique attributes of your organisation that make it different, or make it a great place to work, focus on those and try to assess how the individual you’re interviewing will fit in.
Be mindful of the ramp up time
Despite what your management or project management team try to sell you, there is no such thing as “Hit the ground running”. I have yet to start in an organisation whereby I could make any meaningful contribution to any project in under two weeks. There is always a gradual ramp up period, whether it be down to an organisation unable to find me a suitable desk to work at, equipment shortages, starting at the wrong time or some other type of impediment. During that time, your new code emitting unit can get up to speed with whatever uniqueness of your code base. So bear in mind that just because he couldn’t remember the constructs of a basic for loop during the interview process, he won’t have it down pat by the time he opens up your unholy mess of a code base!
Don’t let your developers formulate questions
This is an absolute negative point. All you will end up with is the calibre of questions that we’ve already discussed. Rather try think of particularly challenging situations your team has faced in the weeks leading up to the interview stages, get a background and what was the cause of the situations and a brief synopsis of the solutions implemented. Discuss these with your candidate find out if they have experienced similar scenarios in the past, and how their teams came to a resolution. Inevitably they will start discussing what their contribution was and start elaborating on their own technical knowledge of the situation. You can then use this as a guide to further examine their technical expertise by asking probing questions.
The key element I look for in this is how much credit they contribute to the team and how much they claim for themselves. I consider their team work mentality to be of more importance than their technical knowledge. I have found that technical skills and knowledge are easily gained or learned, but team mentality does not happen that easily.
Interviews suck for both parties. They are an unfortunate necessity in the world of work, but they should not necessarily be painful.