My thoughts on how to conduct practical interviews for Software Engineering candidates.
Any professional software developer has been through it, standing in front of a whiteboard reciting some algorithm you are supposed to have memorized, that you have never once used for anything in your career. Obviously, that isn’t a good test of ability. Classical software interviews are clearly a different skill than software engineering. Talented engineers get rejected for silly reasons. How do we make this better?
The first problem, to me, is untrained interviewers misinterpreting the idea that false negatives (rejecting good candidates) are better than false positives (hiring bad candidates). This has been a topic of discussion for a very long time, probably since the early days of computer science. I agree that an incompetent engineer is more of a liability than an asset, for many reasons. What I don’t think is right is what we call a “false positive”. To explain, we need to define what a good candidate is, and then infer what an interview should entail.
There is a lot more to a bad hire than just poor technical skill. Poor personality, poor communication, and an inability to adapt are all far more damaging traits than not being a top notch programmer. Poor personality and communication negatively affect other engineers morale and make their jobs more difficult and stressful. Inability to adapt leads to dated ideas and eventually your technology falling behind the competition. Quickly summarizing, a good candidate must be technically skilled, adaptable, communicative, and personable. I’ve found that many companies ignore some or all of these factors, often relying completely on random technical puzzles to determine who to hire. You would be better off hiring with resumes on a dartboard.
I’ve recently gone through the process myself and come to some conclusions based off my experience. It’s not absolute, but I’ve been on both sides of the interview table and I think I’ve found “Must Do’s”, “Could Do’s”, and “Must Not Do’s” in an interview that will make interviewers better judges of candidates.
Must Do’s
Technical Skills – The candidate must write code, on a computer, using any resources they would normally have. I don’t think you can interview an engineer without asking them to code, but the code should be simple, straightforward, and relatively easy to manage in the time allotted for the interview. In this part of the interview, correctness and completion are not important, it’s much more important that they know how to use the tools at their disposal, the basics of programming language, and how to consume information from the internet.
Adaptability – The candidate could show they can pick up a project and understand what it is doing. This may be redundant if the technical skill question(s) are exceptionally well written, but the point is clear. The candidate should be able to show they can learn and understand something unfamiliar and parse the information, quickly.
Communication – The candidate must explain, in detail, the design of a project they have built. They must be able to explain the design decisions they have made. They must explain what alternative designs were considered and explain the trade off well. This interview is about communication, not the choices they made. If they can explain themselves rationally that is more important than if you agree with their design decisions.
Personality – The candidate must show they are easy to get along with. He must be personable, driven, and empathetic. The candidate must interview with the team he will be working with, and meet his future manager, PM, and peers. You should never have to introduce a new hire to his new manager. The fact that companies do this regularly baffles me.
Could Do’s
Specific Technology – Tl:dr, If you are interviewing for a DBA, ask a database question. Ideally, this shouldn’t be necessary, as most engineers are smart enough to pick things up on the fly. I would suggest only doing this if the role requires daily use of whatever specific technology this role is. I’ve seen UI interviews for engineers who will never once touch JS in their job. I’ve also seen SQL interviews for a React JS frontend only role. That is not useful.
This should be made very clear before bringing candidates in, otherwise you are wasting both your time and the candidates time.
Public Presence / Evangelism – Ask about a public GitHub profile, or open source contributions. Maybe blog posts they have written. Not every engineer is in a position they can do these things, but if it exists it’s a great resource to the interviewer. It lets a candidate show his communication skills, his passions, and his philosophy.
Server Architecture – This should be covered in most cases by the technical communications section above. I know the modern web design question is extremely popular nowadays, but the answer is extremely formulaic and not a good judge of an engineer. REST Api + Normalized DB tables + Load balancer / App server / DB / Queue, etc…. It’s something that can be easily practiced and doesn’t actually tell you much about the engineers knowledge.
Must Not Do’s
Irrelevant Technical Skills – One of my interviews in my last job search was a bunch of math and physics brain teasers. This is completely not relevant to the software engineering job at almost any company I can think of. It’s extremely important not to waste time vetting a candidate on something that does not matter for their job. As an interviewer, make sure you are actually gathering useful information every minute of the interview. You do not have enough time to waste on irrelevant skills.
Large Homework projects – Do you want an engineer to be biased because he spent more time on the homework project than the next guy? If you want to give a project, it should be both timed, and less than 2 hours. You do not want to bias against people who do not have time to spend 30 hours on a mock website for you. It will probably scare the talent away anyways.
Tricks – If your problem can be found in CRACKING the CODING INTERVIEW it’s probably not a good question. If it requires an algorithm the candidate learned 10 years ago, it’s probably not a good question. Nothing you ask should have a “trick” or an “a-ha” moment to figure out the solution. By doing this all you do is bias towards people who have spent time studying for the interview, and biasing away from people who actually spend their time developing software.
Veto – Never let one engineer veto the hiring decision in an onsite interview. This is to protect the interviewer from their own emotions. I’ve seen an interview say no before they even meet the candidate. If you see an interviewer doing this regularly it may be time to take them out of the interview panel.
Single Answer Questions – Do not ask an abstract question, perhaps about a product decision, then fail the candidate because they did not answer how you would have. Separate ways of thinking are healthy and should be encouraged, not shunned.
Conclusion
I’ve seen that many companies, particularly larger companies, do not do a single thing in the “Must Do” list. It’s very easy to get lazy and forget what the point of an interview is, and it’s also very easy to use unskilled and untrained interviewers as the company grows. I understand. But you must fight that. It’s important to train the interviewer well, using well defined standards for your company. It’s important to keep the interview process predictable, consistent, and applicable. Do you do everything in the “Must Do” list?
As for the candidates out there, just remember that the process is a little broken, very inconsistent, and there is no way to get every job you apply for. Practice, play the game, and don’t get too sour when you come across a bad interview. There are still more CS jobs out there than candidates to fill them, so there should be a place for you.
References
http://stevehanov.ca/blog/resume_comic.png
https://github.com/poteto/hiring-without-whiteboards
https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
https://techcrunch.com/2015/03/21/the-terrible-technical-interview/
https://salesforce.quip.com/2UKIAhvKyZf0
https://triplebyte.com/blog/how-to-pass-a-programming-interview