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.
Usually you do not need to wear smart clothes, casual should be fine. T-shirts and jeans are acceptable at most places.
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.
Avoid holding a phone in one hand and only having one other hand to type
It is easier to send links or text across.
Leave space between lines of code in case you need to insert lines between existing code.
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.
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
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.
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.
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."
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.
Read tips and sample final questions to ask.