I’m here to tell you, from the perspective of an interviewer, exactly what we’re looking for in our candidates when we throw them head-first into a coding interview. In other words, exactly what will make us happy and more likely to want to hire you.
Executive ability is non-negotiable
First, let’s get the ugly stuff out of the way. You must be able to execute. That means, when given a coding problem, you must be able to do what it takes to get it to completion. We’re interviewing you for a software development job. You must be able to develop software.
That said, an interview gives a very limited picture of a candidate’s executive ability. Time is limited. Scope is limited. The only thing we can do to get a more complete picture is to do more interviews but that obviously takes more time and resources, which is why large corporations are more equipped to do that sort of thing.
We get it, there’s time pressure and the problem might be unfamiliar. But you should be able to demonstrate in the time given that you’re able to write code to solve a problem whenever a problem is presented to you. A major part of this depends on the interview problem being well-designed — we’ll get into that later.
Fail to plan, plan to fail
Having a game plan is important. Not everyone can be like Indiana Jones, do whatever they want at the spur of the moment, and have it work out. (Unless you are the coding equivalent of Indiana Jones… in which case you deserve that job.)
A good candidate should have some idea of what it looks like when the problem is solved, as well as what it takes to get there. They should have some process or methodology for solving a problem. And not everything may work out according to plan; they will also have to accept a certain degree of uncertainty and deal with it when the time comes.
In the absence of a plan, trying to solve the problem becomes a process of trial and error. This is time-consuming, has low chances for success, and displays no positive signals to the interviewer — anyone can do trial and error, but we’re looking for someone who isn’t just anyone.
Run your code often
This is probably the main takeaway from this article, in case you were looking for one. Now, unless you’re the aforementioned Indiana Jones, your code isn’t likely to run perfectly on the first attempt. Therefore, you have to work on the solution step by step. Incidentally, this also shows that you have the planning capability we’re looking for.
Being able to work on a solution step by step means writing some code, running it, writing some more code, running it again, and so on. This means you have to be able to get your code in a working state and keep it there, even if it’s not solving the problem, or even if it’s simply outputting numbers to the console. The interviewer would like to see progress; if your code is not running, then there is no way to see progress.
This is also a critical skill in the software development industry. Good habits to develop include keeping commits and code reviews small, ensuring our builds pass, never checking in broken code except to experimental branches, and developing good logging practices.
There are no dumb questions
Okay, maybe there’s a caveat: time is short in an interview, so maybe you shouldn’t ask questions that don’t help you solve the problem. Then what sorts of questions should you ask? What would help you solve the problem? If there is anything unfamiliar with the problem space, you should ask for some background. If there is anything ambiguous or was not mentioned that should be mentioned, you should ask them to clarify.
And when all else fails? Ask for help. Know when you’re stuck, acknowledge it, and tell the interviewer. They’d be more than happy to help you, because they want to engage with you and work as a collaborator. Sometimes, all it takes to gain insight into a problem is to ask some questions, then see what ideas flow from there — but that won’t happen if you never ask.
A look from the other side…
So there you have it — we’re looking for those things in general. Now we can ask, what makes an interview problem well-designed? Our goal as an interviewer is not necessarily to make a pass or fail judgement; rather, we want to get the most accurate picture possible using a limited amount of time.
Hence we need to design a problem that captures as many of those signals I mentioned above as possible. That means the problem should allow the candidate to ask questions, formulate a plan, iterate quickly, and execute to the best of their ability. That means the problem should be:
- Open-ended enough to have some ambiguity, and allow for a variety of alternative approaches.
- Complex enough to require planning and prioritizing of tasks.
- Designed to allow for continuous observation and feedback as the candidate works on multiple iterations of their solution.
- Fun! Who’d want to be there if not for fun?
Of course, as interviewers we are also constrained on time and resources, so we don’t want to make the problem too difficult for us to assess. However, this type of problem is a valuable thing to have in your interviewing repertoire — it may find you that engineer you were looking for.