Skip to content

Latest commit

 

History

History
46 lines (38 loc) · 3.36 KB

coding.md

File metadata and controls

46 lines (38 loc) · 3.36 KB
Raw

Coding Interview

Tackling the coding interview.

Evaluation Criterion

  1. Communication. Ask for requirements and clarifications as necessary. Don't dive into the code, and instead make it a conversation.
  2. Problem solving. Ability to comprehend and explain complex ideas. Provide the reasoning behind a particular solution. Develop and compare multiple solutions. Use appropriate data structures. Analyze space and time complexity. Optimize your solution.
  3. Coding. Ability to convert solutions to executable code. Write well-organized code that captures the logical structure correctly.
  4. Verification. Consider a reasonable number of test cases or come up with a good argument for why your code is correct. Ability to explain what the code does, and walk through the logic, while finding any bugs along the way.

Steps for Success

Total time: 15-20 minutes

  • Understand the problem. (finish by 2-4 minutes in)
    • Misunderstanding the problem will cost you dearly! So make sure you get the problem straight.
    • Take non-trivial examples, and make sure the expected output is what you expected!
    • Ask for clarifications, and input/output constraints (e.g., input size, input/output types, corner cases etc.)
    • If the problem is not algorithmic (e.g., "Build a csv parser"), make sure to discuss the use-cases, and come up with an appropriate data representation (e.g., row-wise vs. column-wise grouping).
  • Think out loud, while planning your approach. (finish by 6-10 minutes in)
    • This is important, as it helps your interviewer follow along, learn about your reasons for not considering various approaches, and provide hints if needed.
    • State the expected time and space complexity of the approaches while you consider them.
    • When you arrive at a solution, be sure to get the interviewer's thoughts on it before you start coding.
  • Write a working solution and iterate. (finish by 12-16 minutes in)
    • Better to have a non-optimal but working solution than get lost in the pursuit of optimality.
    • If your interviewer expresses doubts on a certain part of the code, they're likely hinting at an opportunity to improve your code, so don't ignore them!
    • Ask clarifying questions about constraints/assumptions as you go along.
    • Suggest ways to optimize your code and get feedback before coding it up, to ensure what you're trying to do is correct and not overly complex.
    • If your solution is getting messy, step back. Most interview questions are designed to have reasonably elegant solutions. Look for patterns that could be generalized.
  • Run through the code verbally, with an example. (finish by 15-20 minutes in)
    • Test your code, put in an input to see what happens.
    • Make sure to read what is there, not what you think is there.
    • It's good if you find bugs and fix them yourself!
  • Restate the complexity. (Optional if it's still the same, or due lack of time.)
    • Is it different from your initial expectations after you have implemented?

More Tips

  • Restate the problem as you see it if it helps clarify things.
  • Do not jump straight into coding!
  • It is totally okay to ask for hints if you're stuck.
  • Start with the basic approach -- brute-force -- but don't code!
  • State/analyze the time and space complexity of every approach
  • While coding, be sure to modularize so that it's easy to focus on the interesting parts
  • Ensure edge-cases are covered