Coding interview cheatsheet: Best practices before, during and after

As coding interviews mature over the years, there are now firmer expectations on how candidates should behave during a coding interview. Some of these practices also help you to exhibit "hire" signals to the interviewer by displaying your ability to communicate well and deal with roadblocks.

Deriving the best practices from top candidates and also based on how you will be evaluated during a coding interview, we have summarized some of the top tips for how to behave during a coding interview in an exhaustive checklist - including top mistakes to avoid.

You should read and familiarize with this guide even before you start practicing your coding interview questions. Accompanying LeetCode grinding with this guide will allow you to ingrain these important coding interview behaviors early on.

What to do before your coding interview​

Usually you do not need to wear smart clothes, casual should be fine. T-shirts and jeans are acceptable at most places.

For virtual onsite coding interviews​

Summary of what to do before a virtual onsite coding interview

In case you need to jot and visualize stuff. Drawings are especially helpful for trees / graphs questions

Avoid using speakers because if the echo is loud, communication is harder and participants repeating themselves will just result in loss of valuable time.

Set up the editor shortcuts, turn on autocompletion, tab spacing, etc. Interviewers are impressed if you know the shortcuts and use them well

Most remote interviews will not require video chat and leaving it on only serves as a distraction and hogs network bandwidth.

For phone screen coding interviews​

Summary of what to do before a phone screen coding interview

Avoid holding a phone in one hand and only having one other hand to type
It is easier to send links or text across.

For onsite whiteboarding coding interviews​

Leave space between lines of code in case you need to insert lines between existing code.

What to do during your coding interview​

Summary of what to do during a coding interview

1. Make a good self introduction at the start of the interview​

Follow our guide on how to make a good self introduction for software engineers
Speak with a smile and you will naturally sound more engaging.

2. Upon receiving the question, make clarifications​

Do not jump into coding right away. Coding questions tend to be vague and underspecified on purpose to allow the interviewer to gauge the candidate's attention to detail and carefulness. Ask at least 2-3 clarifying questions.

Make sure you understand exactly what they are asking.

A tree-like diagram could very well be a graph that allows for cycles and a naive recursive solution would not work. Clarify if the given diagram is a tree or a graph.

Can you modify the original array / graph / data structure in any way?
How is the input stored?
If you are given a dictionary of words, is it a list of strings or a Trie?
Is the input array sorted? (e.g. for deciding between binary / linear search)
Inputs: how big and what is the range?
Values: Negative? Floating points? Empty? Null? Duplicates? Extremely large?

E.g., you are asked to write a palindrome checker, before coding, come up with simple test cases like "KAYAK" => true, "MOUSE" => false, then check with the interviewer if those example cases are in line with their expectations

3. Work out and optimize your approach with the interviewer​

The worst thing you can do next is jump straight to coding - interviewers expect there to be some time for a 2-way discussion on the correct approach to take for the question, including analysis of the time and space complexity.

This discussion can range from a few minutes to up to 5-10 minutes depending on the complexity of the question. This also gives interviewers a chance to provide you with hints to guide you towards an acceptable solution.

  1. Use nested for loops. This would be O(n 2 ) in terms of time complexity and O(1) in terms of space.
  2. In one pass of the array, you would hash a value to its index into a hash table. For subsequent values, look up the hash table to see if you can find an existing value that can sum up to the target. This approach is O(N) in terms of both time and space. Discuss both solutions, mention the tradeoffs and conclude on which solution is better (typically the one with lower time complexity)

Mention the Big O complexity for time and explain why (e.g O(n 2 ) for time because there are nested for loops, O(n) for space because an extra array is created). Master all the time and space complexity using the algorithm optimization techniques.

4. Code out your solution while talking through it​

In so doing, demonstrate mastery of your chosen programming language.

You want to type slow enough so you can explain the code, but not too slow as you may run out of time to answer all questions

Always go for a clean, straightforward implementation than a complex, messy one. Ensure you adopt a neat coding style and good coding practices as per language paradigms and constructs. Syntax errors and bugs should be avoided as much as possible.

Good variable names are important because you need to explain your code to the interviewer. It's better to use long variable names that explain themselves. Let's say you need to find the multiples of 3 in an array of numbers. Name your results array multiplesOfThree instead of array/numbers.

E.g. reduce , filter , min , max should all be ok to use

Let's say you're asked to build a car. You can just write a few high level functions first: gatherMaterials() , assemble() . Then break down assemble() into smaller functions, makeEngine() , polishWheels() , constructCarFrame() . You could even ask the interviewer if it's ok to not code out some trivial helper functions.

E.g., "Under non-interview settings, I would write a regex to parse this string rather than using split() which may not cover certain edge cases."

5. After coding, check your code and add test cases​

Once you are done coding, do not announce that you are done. Interviewers expect you to start scanning for mistakes and adding test cases to improve on your code.

Read through your code with a fresh pair of eyes - as if it's your first time seeing a piece of code written by someone else - and talk through your process of finding mistakes

Given test cases are usually simple by design. Brainstorm on possible edge cases such as large sized inputs, empty sets, single item sets, negative numbers.

This allows you to remind yourself to spot issues within your code that could deviate from the original time and space complexity.

6. At the end of the interview, leave a good impression​

Read tips and sample final questions to ask.

What to do after your coding interview​

Summary of what to do after a coding interview