Leetcode Strategy
This is a walkthrough of what to do and how to approach a coding interview question when you’re sitting opposite an interviewer from a tech company who is expecting you to reach a solution in the next 30 minutes.
For most questions that you don’t already know the answer to, this strategy should work -
First 5 mins -
- Manually go through/type out example cases for the question, just to understand the input/output if it’s a difficult question. Can draw boxes & lines on paper if you don’t know where to begin. Make sure you are familiar with input/output and constraints before starting to think of a solution. This simple but important step removes any silly mistakes early on.
- Create an example testcase of your own, so you can confirm with the interviewer if the example is correct. This allows the interviewer to correct you sooner.
Next 10 mins -
- Think up some approaches/algorithms and write them out. Type high-level english pseudo-code for each approach, then work step by step through the input to make sure it leads to the correct output. This will help point out if you’re missing anything or have any wrong assumptions. Try out 2-3 wacky test cases to demonstrate your careful thinking. A mistake is to begin writing code straightaway, better is to type out high level pseudocode which helps to clear your thinking too. And the interviewer can correct you quickly leaving enough time to correct your approach or try another one if necessary.
At the 15 min mark - half the time left - if your approach seems ok - you can start coding in earnest.
- Just convert your high level pseudocode to the final code. It may make you nervous to spend half the interview without writing any code, but it turns out to be a good technique because once the pseudocode is finalized, just writing it out shouldn’t take too long. And you avoid situations where after 20-25mins, you have to change your approach because it doesn’t work.
- Hopefully the code is written out with 5-10mins left. Instead of waiting for the interviewer to point out any bugs - (there will probably be a bug in your code! over 50% of the time I have bugs) - try to take 1-2 testcases and run them mentally/manually through the code, pretend to be a human compiler. Type out the variable initialization values, go line by line and update values, try to not skip any line.
If at the end your answer is correct, congratulations! Otherwise, remember - sometimes you win, and sometimes you learn.
Also generally try to say out loud what you’re thinking, try not to be silent for more than 30 seconds, and keep confirming with the interviewer during the first 15mins if what you’re thinking is correct. This is if you are fluent in English, otherwise do what seems comfortable to you.
A great resource for practicing interviews is Pramp, which you can use to practice 30-min interviews with real people at any time every day, and it’s free.