Get better at coding interviews

Interviewing is a crucial part of professional software development, yet nobody actually teaches people how to do it well. The problem is that interviewing is not scalable: it requires full attention from at least two people. As a result, there is a strong drive to automate the process. Unfortunately, interview training via automated code puzzles can teach the wrong lessons. I'm going to provide some suggestions on how you can improve the interviewing skills on your own.

Interview goals

First, let's talk about the misconceptions about why we interview. People think that a coding interview is an impartial test of their software engineering skills and worth, likely due to similarity to university exams. It isn't. If anything, an interview is a test of communication skills.

Your primary task during an interview is to help the interviewer make a decision. Solving the puzzle is incidental. It is entirely possible for you to solve the coding puzzle in a way that leaves the interviewer unconvinced. You could say that a coding interview is like a game demo (and you are the game).

Fix 1: This is a demo, not a (unit) test

Anything you do (analyse the question, come up with a solution, check the solution) should happen in the interviewer's head and not just your own. Instead of mumbling to yourself, say the thought out loud to them. Instead of keeping variable values in memory, write them on the whiteboard (or in the document). Tell them what you're doing, step by step. The most interesting information to the interviewer is how you worked it out. They already know what the solution is.

This likely won't come naturally to you.

Start with solo practice. Solve an example question, one where you already know what the answer is. Then explain the solution out loud to a voice recorder. Then listen to the recording. Is it easy to understand? Is it well-organised, are you following a plan when explaining? Are you explaining why you're taking certain actions, or are you simply reading back what you've written ("add it to stack... now subtract one...").

This is how people prepare for public speaking. Extroverts may need to practice too - nervous babbling and information overflow also make for bad communication.

Later, switch to in-person practice interviews. (pramp is an example of a service that lets people swap in-person practice.) This will help you get used to the habit of explaining everything to a real live person, and hopefully act as exposure therapy to performance anxiety.

Fix 2: Problem solving sub-skills

This one is the most straightforward, in that you can find books about it, including the well-known "Cracking the Coding Interview" by Gayle Laakmann McDowell. Here are some sub-skills you can learn to get better at code puzzle solving:

• Learn a few meta strategies like "solve for the most trivial input, then solve for trivial+1, then extrapolate to N". Try to solve a few questions by following these strategies to the letter, even if the answer is evident to you.
• Collect a list of common input properties (example properties: a list of numbers can be empty, sorted, partially-sorted, infinite, contain only positive numbers...)
• Practice finding edge cases for every question and testing your solution against them (example: test for 0/empty array in order to find the off-by-one cases)
• Practice solving one coding puzzle a day. Use easy ones to get yourself in the habit of verbal explanation and following the puzzle-solving strategies. Then try medium ones to level-up problem solving.

Fix 3: Give yourself more time

If a coding interview were a computing problem to solve with a hard limit on execution time, you would optimise the repeating parts in order to give you more time for the actually valuable and difficult parts.

The most repetitive and least appreciated part of an interview is writing. You should get better at the physical act of writing (either typing or on the whiteboard).

Secondly - and this is more of a personal opinion based on observations - I think that unless there is a compelling reason otherwise (e.g. people specifically told you which language to use), you should use Python. You might not work in Python; doesn't matter, learn it (with flashcards) for the purpose of interviewing. The set of language features, data structures and libraries which you need for a coding interview is limited. Python is currently the language in which it is possible to write the least amount of code to perform typical code interview tasks.

(You may have a favourite language that is more expressive, but remember that this is about communication. It doesn't matter if you write poetry in code form if the interviewer can't appreciate it during the interview.)

Motivation

People often express their frustration with how interviewing is a separate skill from actually doing the work. Most of the above skills, however, are transferrable, and will come quite handy at work. You will be able to:

• explain your train of thought and persuade coworkers and managers,
• write relevant documentation and comments
• come up with better variable/function names (famously one of the hardest problems in computer science)
• improve your understanding of what the code does and why

So make sure you are familiar with how the learning process works, give yourself some time to suck at first, and schedule some regular practice - in order to level up as a software engineer.