5 Key Elements I Evaluate in Every Code Interview

Feb 13, 2024

The code interview is a critical juncture, serving as the gateway to subsequent rounds of the hiring process. Contrary to what the term might suggest, it encompasses far more than merely writing code. Occasionally, a candidate might complete the task at hand (though this is not too common), yet there are still chances for failure due to other overlooked aspects.

After a failed interview, if probed, some recruiters might offer generic, somewhat unhelpful feedback, such as "communication needs improvement," or "coding skills need further development." However, beneath the surface, there are numerous facets often neglected by many junior developers. Addressing these overlooked aspects correctly can significantly boost your chances of advancing to the next round. In this article, I wish to shed light on what I evaluate in every code interview (a practice common among many experienced interviewers). Thankfully, these are skills that can be developed with some practice.

Good Coding Habit

The very first aspect that catches my eye is whether the candidate demonstrates good programming habits. This includes everything from using keyboard shortcuts and command line operations to automating a few repetitive tasks.

Take, for example, the scenario where you need to search for a function by name during the interview. It would count in your favour if you could swiftly use Command + Shift + F, or when asked to enlarge the system screen fonts, you opt for Command + Space to launch Spotlight, then type "system" to find Display settings, rather than navigating with your mouse and clicking around.

I’ll list a few common shortcuts I use daily. You might already be using some of these, but if not, adopting them could be indicative of a good developer mindset 😄:

Command + T to open a new tab in Chrome, ready to input URLs and press Enter.
Command + L to jump to the browser address bar, and Command + C to copy the URL.
Command + Shift + { or Command + Shift + } to navigate to the previous or next tab in Chrome.
Use Command + Tab to switch between applications, and Command + backquote to switch among multiple windows of the same application.

Please note, my judgment isn’t based on familiarity with a particular tool per se; it’s more about the habit, the mentality – are you constantly seeking ways to be more productive? Do you generally care about efficiency in your work?

Another interesting point is the use of the command line. It might not be as common as it once was, but having some knowledge of command line and shell scripting can generally assist in automation tasks.

A good example is when you need to verify some tasks before pushing to remote. You might want to run some checks, like eslint --fix, unit tests, or pact tests, and you need some basic knowledge of executing such tasks in a shell environment.

Again, it’s not only about the tools themselves but more about the attitude towards effectiveness and efficiency.

Tasking

I’ve discussed this technique in many articles before, but it remains the most critical skill a proficient developer can possess. That’s the ability to break down tasks.

During an interview, I often ask the candidate to outline their plan, such as what the first prototype would look like, and how they would verify its success. This step reveals how the candidate thinks about incremental programming and considers the definition of done even before starting, which are key merits of a good developer. Most importantly, this skill can be honed through practice a few times. And I genuinely believe it benefits significantly when applied to real-world coding.

person writing bucket list on book — Photo by Glenn Carstens-Peters on Unsplash

You could use Post-its or whatever tool you’re comfortable with to jot down a few tasks you intend to tackle (envisioning what done looks like for each), and then focus on one at a time. Once you complete a task, we can discuss the results and decide on any potential improvements, or simply move on to the next task.

Honestly, adopting such a mindset or habit always yields better results, regardless of the task at hand, be it implementing a complicated feature, fixing a legacy defect, or performing some arbitrary tech ops tasks.

Thinking Out Loud

This technique is equally important as completing the coding task itself. Especially in an interview setting, I evaluate candidates on how well they can think - but since I cannot observe the thinking process directly, the only reliable indicator is how well you can verbalize it.

It may be a bit distracting for some to code and talk simultaneously, but it’s a crucial practice to demonstrate clear thinking to the interviewer. And again, this is a skill that can be improved with a bit of practice. The "rubber duck" method has been proven to be an effective way to uncover issues while debugging. It seems that talking through a problem increases the chances of arriving at an "aha" moment compared to working through it silently.

Remember, completing the coding task is just one aspect of a code interview, and often, it’s the less important one. It’s vital to express yourself clearly, discuss alternative options, and articulate the pros and cons of the path you chose over others.

At the beginning of an interview, I usually ask the interviewer if they would like me to write tests first (as I frequently practice TDD), and their response provides an opportunity to impress. It demonstrates that 1) you are knowledgeable about TDD, 2) you care about the process (or code quality), and 3) it opens a window to showcase your other programming habits if they respond positively.

Feedback Reception

In most cases, I will pose some questions to see how the candidate responds. For instance, "I noticed you've manually performed X action many times; what about using a keyboard shortcut?" or "Do you think the function name or the for loop could be simplified in any way?"

Most of the time, candidates are open to such feedback and eager to learn more. However, there are instances where they become defensive and unwilling to change their approach, which raises a red flag for me.

Asking for Clarifications & Being Honest

Normally in an interview, the coding task - the problem you are supposed to resolve - is new to you. Maybe it's the domain, the constraints, or even the language; they’re designed to be challenging. And it’s entirely okay, in fact, encouraged - to ask for clarifications before you start, or if you find yourself stuck.

Perhaps you’re overthinking a condition, or focusing too much on an edge case. It’s always beneficial to ask and understand what the interviewers truly expect from you. Don’t guess. Because in many cases, your guess could be incorrect, and possibly far from what the interviewers are evaluating.

It can sometimes be difficult to admit "I don’t know" the answer, especially when you are keen on securing the job. However, this is common and even expected. No one knows everything; we all have something new to learn every day.

Summary

In conclusion, excelling in code interviews extends beyond the mere ability to write code. It encompasses demonstrating good coding habits, effective task management, clear communication of thought processes, receptiveness to feedback, and the humility to ask for clarifications or admit gaps in knowledge. By focusing on these aspects, candidates can significantly improve their chances of not just succeeding in interviews but also in advancing their development careers. Embracing these principles reflects a well-rounded, growth-oriented mindset that is invaluable in the dynamic field of software development.

Other articles about growth and programming interview: