How not to do technical interviews

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 undergo on average 10-12 technical interviews a year in the quest to land a new assignment. I have also regularly over the years been presented with the opportunity to interview my new potential team members, once I have been engaged on an assignment.

One thing I have noticed of the years is that there are definitely wrong ways to go about conducting technical interviews for software developers and most organisations go out of their way to implement most of them. However there does not seem to be a 100% right way either.

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 from both sides of the interview desk!

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 some obvious failing strategies, is also partly inspired by Mitch Laceys - Technical Interviewing - You're doing it wrong , which comes at this from a different angle.

Managing expectations

One of the first issues many organisations have is that they haven't clearly identified what their expectations are. For the most part, they just rattle off a load of skills, which they think may be required, as if it is some kind of shopping list. In most cases, it may be a list of skills of the person they are attempting to replace, or some kind of composition of the list of all people within a team.

It is in my experience, that whenever an organisation identifies that they need a new technical person, they only vantage point they generally have is what types of skills worked for them in the past, without considering what skills will be required in the future.

A tech stack in an organisation is constantly evolving and the way technology keeps changing it will continue to do so.

Technical questions

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 in the post and anybody wanting to spend a little time googling the answers to those questions, they are accompanied by many great stack overflow posts, where even those fabled 10x developers have struggled to answer.

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!

Just because the candidate possesses the ability to remember some obscure fact about the C#, C++, Java, JavaScript or any other software development language in an interview setting does not necessarily make them the best fit for your software team.  Regardless of your bench-marking strategy!

Not providing your candidates the opportunity to actually review your code

Its a fact that despite contrary belief, Software Developers spend more time reading code than they do writing code! So the reality is they are probably going to spend most their time, reading your code than they will actually writing it.

They are also inevitably going to be spending most of their time Debugging, Analysing, Tracing, Understanding and working with your existing code base than they will writing new code. Despite this, I have never been to an interview where an organisation has ever had any of their code available or even offered to have scrutinized by candidates.

I personally find this perplexing! That the majority of technical interviews are only focused on the 10% of what a developer will actually do. In essence, the Hire or Fire decision is primarily based on the 10% of their ability.

From experience I can tell you that the majority of the challenges a new recruit will face within their first 6-8 months working in your organisations will mostly be the result of confines, restrictions and decisions within your existing code base! Very rarely the result of new code they are going to generate!

I have often requested at interviews with companies to have the opportunity to view their current code base, which has often been rebuked due to apparent Confidentiality and Intellectual Property restrictions which to be honest I find somewhat hilarious. I can almost assure you that at least 90% of any organisations code base has no real Intellectual Property value at all, because it will most probably be on stackoverflow already!

Technical Assignments

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 their code, explaining to me what it does, where the initial idea came from, why they chose the tool set thery're 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 their own unique opportunity to stand out, rather than pigeon hole then 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.

Furthermore, it is highly likely 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 blindly emulate them! It just makes your company look stupid!

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 and immerse themselves in your culture.

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 your candidate couldn't remember the constructs of a basic for loop during the interview process, they won't have it down pat by the time they open up your unholy mess of a code base!

Soft Skills deserve more credit

Time and again I witness companies making the same mistake over and again! In that they seem to only focus on the technical skills. Obsessing themselves over whether a candidate is able to explain the intricacies of string immutability while paying no attention what so ever to if the candidate is able to offer any other unique or compelling attributes.

Technical deficiencies can be addressed quite simply - provided the candidate has the necessary Soft Skills to do so. In my opinion I believe these skills to be far more important.

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.

Conclusion

Interviews suck for both parties. They are an unfortunate necessity in the world of work,  but they should not necessarily be painful.

I am not a guru on this topic, and I would be the first to admit that maybe my style probably isn't the best. However, I know what has worked for me, when I have been responsible for building teams, my focus has never really been technical wizardry.

In the book, The Five dysfunctions of a team there is no mention of lack of technical competency being a dysfunction. So regardless whether your candidate could explain the JavaScript Closure in an interview setting or not, will inevitably have no effect on your project at all.