ash0x0's Obsidian Quartz

Coding Interview

4 min read

  1. One main question will take the bulk of the time. Prep for 20 to 30 minute question
  2. If the answer isn’t immediately obvious, try to clarify what the question is asking
    1. Main requirement
    2. Data structures involved
    3. Input provided
    4. Constraints and which you can use or remove
  3. Give the solution you have even if it’s not the best one and try to work on the best one with them
    1. You don’t need to find the best solution. Find a solution than not at all
  4. Think out loud
  5. Ask clarification questions
  6. Call out assumptions
  7. Define inputs, requirements, data structures, constraints, etc. first
    1. Define edge cases first if you can
  8. Google TechDev Guide
  9. Don’t lose time by trying things you know won’t work
    1. Try to come up with examples you know will break it
    2. Then fix it after you break it
  10. More important to solve general case and leave some edge cases
  11. You can leave edge cases and indicate you know it
  12. List the edge cases in the beginning
    1. This will help you testing your possible solutions and approaches
  13. Try to think of the general case first without the restrictions
    1. Treat the restrictions as edge cases
  14. Think of brute force solutions as going through all the possible combinations
  15. Focus on having a working solution at the end of the interview
  16. Start with figuring out the exponential solution as the brute force
  17. Start thinking about just one better level of complexity
  18. Determine the best achievable complexity as you look at the problem
  19. Start going from the worst complexity you can implement then once you have it working improve by one level better complexity
  20. Don’t try solutions you know won’t work
  21. Block time for yourself before the interview
  22. If you come up with an idea just say it but don’t implement it
  23. If you like the idea and want to implement it just ask first if they think that idea is going to work and if they have a counterexample to this
  24. Show that you can build up to a solution
  25. Blocking time
    1. First 5 minutes reading question and asking questions and clarifying ambiguity
      1. Can the values be negative?
      2. Can the values be decimals?
    2. 5-15 minutes coming up with ideas
    3. 15-30 getting a working solution with good quality code
      1. Test it and make sure it’s working
    4. 30-45 optimize the solution and improve complexity
      1. Book 5 minutes in the end to test and make sure things work
    5. Don’t write code until you know you can’t improve on the idea you have or can’t move forward right now
  26. Clean code
    1. Select more meaningful names that are descriptive for the data structures
  27. Mention space and time complexity
  28. The notes are reviewed by committee so you want to make the notes and the code readable
  29. If you need to initialize something (base case) in the recursion or dp solutions you can mention it as you’re implementing and say this is something you know but will leave to the end
  30. Questions often have followups
    1. To see if you can modify the code for changing requirements
    2. Ask the interviewer if they’re planning to do followups so we can leave time for it
    3. They will come up with followups if more time is available
  31. If you get stuck with the task remove constraints
  32. Always best to come up with your own examples
  33. You can ask the interviewer to confirm things for you but not rely on them
  34. If you’re making assumptions about the data, constraints, inputs, requirements, etc. clearly communicate them to the interviewer and tell them the decision you want to make
  35. Ask for help if you get stuck
  36. If I don’t remember the syntax or a function signature I can assume a function call or ask him for it if he knows it
  37. Debug proactively

Graph View