Standing Out LOUDER in the Technical Interview

So now you have an interview and you've done all your research, so you're good to go right? Wrong. Solving the coding challenge is only one part of the technical interview. Another aspect of the technical interview that candidates often overlook is the behavioral components. I have experienced it myself and heard others' experiences about having tunnel vision into the code while forgetting to demonstrate other essential skills like communication and collaboration. I will share with you my framework for finding success in any technical interview, and how you can stand out as a candidate.

The LOUDER Framework to Stand Out

The first key aspect to standing out is to literally put yourself out there: think out loud. Interviewers care more about how you solve a problem and less so how fast you can get to an answer. Most candidates are too busy rushing to the end, that they forget to demonstrate their communication and collaboration skills. If you want to nail the technical interview, you need to think LOUDER.

1. Listen to the other person
2. Orient the problem statement
3. Uncover the scope and requirements
4. Deliver a plan
5. Examine the solution
6. Reflect

Listening to the other person means trying to understand the what, the how, and the why of the problem. Most candidates only think about the "what" and will forget to collaborate with the interviewer. Why am I being asked to solve this, and how am I expected to? This is what you should ask yourself upon hearing the question.

Orienting the problem statement means to re-frame the problem statement, summarizing the prompt. By summarizing the problem statement, it gives you an opportunity to demonstrate that you understand the prompt. And if you misinterpreted – it gives the interviewer the chance to help you course correct.

Uncovering the scope and requirements is where you will define the outline of your strategy to solve the requirements. It's in this step that you will define the majority of how you solve the problem. There are two kinds of requirements: main case and edge case. Most of the time, the prompt will include the main case requirements. Sometimes it will also include edge-case requirements, however, you should always ask yourself: what are the edge cases? Try to identify any relevant edge cases, and when you've exhausted your search, you should ask the interviewer follow-up questions. A good example to ask: "have I covered all of the edge cases?"

Delivering a plan means having an idea of how to solve the problem, and then trying to deliver that solution. In this process, it's helpful to start with a high-level approach, using whiteboarding or pseudo code. Consider evaluating multiple solutions, and talk through the tradeoffs (for example performance and scalability) of each solution. I always recommend starting there before writing code. Once you have planned a solution, start writing code. The reason why we take this approach is that it's possible to pass the interview without writing all the code. Moreover, it's possible to fail the interview because all you did is write code. A plan communicates that you are able to think strategically, evaluate multiple solutions, and deliver the best solution.

Examining the solution is an often overlooked part of the process. A bad interview goes like this: you solve the problem and then say "okay I'm done." Instead, we want to incorporate collaboration into the process, and invite the other person to participate. What I recommend doing after you're finished solving the problem, is to examine your solution out loud. Similar to a code review, you should review the problem and present the solution back to your interviewer. Talk through the main cases and edge cases that you outlined in the uncovering phase, and how your solution works for these test cases. In the process, you may even uncover an issue with your solution, and intervene quickly. It's also a great conversation to talk about how it could further be improved if you had more time.

Reflecting is the final step to a successful interview. When you've finished examining your work, the next step I recommend is to ask your interviewer: what do you think? At this moment, you invite your interviewer to give you feedback about your work, and a pulse on how the interview is going. Listen carefully to the feedback to understand the what and the why. This is a good opportunity to demonstrate your ability to collaborate and take feedback – it's important that you be receptive.

Together, these actions demonstrate the skills of a mature candidate, who embodies communication and collaboration. By listening to the other person, it shows you are able to gather context effectively. Orienting the problem statement shows the interviewer you can lead a technical conversation. Uncovering the scope and requirements is a valuable skill that expresses one's ability to translate non-technical constraints into technical limitations. Developing a plan to solve the problem, and then doing so, shows how you strategize and prioritize. Examining your work gives you the opportunity to add more value, and demonstrates your work ethic. And lastly, reflection shows how well you are receptive you are to feedback and how well you collaborate with others.

I hope this framework helps you in your journey to stand out as a candidate in the technical interview. If it does help, I love hearing success stories – reach out to me on Twitter.