Why your Tech interview process may be flawed 😐

“There is more to a candidate than identifying if they know how to flatten a multi-dimensional array, what a prototype chain or closure is. Are they approachable and helpful to others? Can they leave pride at the door and do what’s best for the team? …”

I’ve had discussions with many friends about a few of their experiences in technical face-to-face interviews. Some went well, some went bad, and some were just outright ridiculous. You see, sometimes an interview goes wrong, and it’s not always the fault of the candidate. This person may be considered the creative/visual type, with strong expertise in building solid UI elements that can be used in web applications, but then gets asked in the interview how to solve a complex algorithm around binary trees or big O on a whiteboard.

This question — not always — may be valid for a data scientist at a place like Facebook or Google, but most of the time a job doesn’t require such complexity on a daily basis. The job probably involves building common sense features for an existing web application that applies: solid communication with stakeholders, clean, tested and well-organised code, and the incorporation of strong web standards involving accessibility. In the end, code gets shipped by them without complications and gets delivered in a timely manner.

These qualities are so vital in a role and don’t usually get identified during an interview process. The interviewers are more interested in trying to make the candidate look stupid, to find gaps in their knowledge, or just to fulfil their own sense of pride. The mindset of, ‘I know this, but does he?’ You know what? Maybe they don’t know, and it’s okay not to know everything. Not everyone does.

“People who think they know everything really annoy those of us who know we don’t”

Bjarne Stroustrup

Companies also have their own domain knowledge. Which means internally they are familiar with their own terminology, how things work or operate and are accustomed to the common problems they face. These problems could be extremely simple to an internal employee, but someone coming in from the outside not so much, so interviewers should try and see things from the interviewee’s perspective. The interviewer may talk about a problem he is currently facing and ask the candidate how we would go about solving it. Likely they will give a look like a deer in headlights.

Errmm. Can you repeat the question?

I think it’s best not to identify the weaknesses, but instead, identify the strengths of a potential candidate. What do they have that we might be lacking? Do we have an expert in CSS who can simplify some of our rules? Was their previous role more marketing focused which means they know Google Tag Manager like the back of their hand? Someone who knows React at a deep level who can identify performance issues we never considered? Someone who has strong DevOps knowledge that can help us build robust Jenkins pipelines for some of our packages? Someone who is an advocate for 100% test code coverage and can enforce this across teams?

There is more to a candidate than identifying if they know how to flatten a multi-dimensional array, what a prototype chain or closure is. Are they approachable and helpful to others? Can they leave pride at the door and do what’s best for the team? Can they explain technical requirements in laymen’s terms to stakeholders? Do they keep everyone in the loop — who may be affected by the changes they are planning to make?

If you cannot see any potential in the candidate and you feel the technical knowledge is not there, then yes, maybe it‘s best not to proceed, but don’t rule someone out just because they couldn’t figure out a problem on a whiteboard. Check the quality of their code test, the way they came across in the interview, the problems they solved in previous roles. The bigger picture. You’ll be surprised at how many talented people in the industry have — and still do — get turned down.

Check out this website that shows influential people who got rejected. Kyle Simpson, the author of ‘You don’t know JS’ was turned down by a big social network company for ‘not knowing JavaScript’. His books are best-sellers and are fantastic. Max Howell who created Homebrew which is used by 90% of Google employees was turned down at Google for not knowing how to do a binary tree on a whiteboard.

In all seriousness, having a poor interviewing process reflects very badly on the company. If they have a negative experience, they will feed Glassdoor some juicy details. Some of the biggest and most successful companies have huge flaws in these areas, and it’s wrong to think that just because the company is doing well that they should leave things as they are. There is always room for improvement.

Thanks for reading, drop a few claps if you enjoyed.

Shaun Michael Stone.Check out some other posts I’ve written, follow and reach out to me on Twitter.