@rkenmi - Tenets of Leetcode

Tenets of Leetcode


Tenets of Leetcode


Back to Top

Updated on January 27, 2021


Disclosure

I'm a simple guy who did a handful of interviews at tech startups and enterprise companies until I landed an offer at FAANG. I'm also fairly involved with interview loops at my FAANG company. I like to follow these tenets for practicing.

Tenets

  • Write a English pseudocode before you start (yes, on Leetcode)
    • Don't go straight to code
    • Just write comments on Leetcode, you can imagine that in an interview scenario you would do the same thing
    • Make it readable but try to save word space where you can (less typing)
    • Step-by-step + bullet point style is better than numbered lists (i.e. 1. Draw, 2. Pseudocode 3. Run Test Cases). It is more work to update numbered lists if you miss a step. Not a big deal for Leetcode studying in particular, but in a real whiteboard interview it can be time consuming
    • You can type/draw diagrams or data structures if it helps
    • tl;dr: It leads to cleaner code later. You can proof-check with the interviewer if your logic seems off or correct before you even write the real code.
  • Don't spend longer than 30 minutes on Medium problems
    • If you are spending 30 minutes or longer, then you're most likely already at the implementation phase and you are messing up on edge cases or not correctly solving the problem
    • For the former, don't spend that much time trying to solve subtle edge cases. It's not imperative (although in a real interview, you definitely have to be conscious of it and inform the interviewer)
    • For the latter, the core algorithm and approach is what counts. If its not correct, just give up and look at the solution. Fail fast for best use of your time and read up on the solution to remember where it went wrong.
    • tl;dr: Throw your pride or stubbornness away and give up within 30 minutes if you can't solve it. It's totally okay to not solve it. Read the solution after.
  • Avoid working on lots of Hard problems
    • Hard problems are challenging and rewarding but its not realistic in an interview setting because majority of them are very time consuming. Some problems aren't exactly "Hard" in the algorithm itself, but more so just "Hard" in the coding/structuring phase. You should expect to have only 15-25 minutes or so (as a form of discipline) to solve each problem, and Hard problems generally don't fit this bill.
    • tl;dr: Do a few for fun, but don't count Hard problems as the meat of your dish. Focus on Easy/Medium.
  • Don't write a crap ton of code
    • If you're writing a crap ton of code, then you might have missed some key things for solving the problem
    • Remember that in a real whiteboard interview, you don't have much space to begin with. Always clarify with your interviewer on how much you should write.
    • Most Leetcode Easy/Medium problems can be solved with less than 25 lines of code. Consider that before you feel like you need to write a wall of text
    • In rare cases where you have to write a lot, try your best to follow DRY (Don't repeat yourself) and write modular, re-usable designs.
    • tl;dr: If you're about to write a LOT of code, take a step back and figure out if there's a different way

Article Tags:
unlistedinterviewleetcode