Advice for Coding Interviews

  1. It is about coding, but it also isn’t. Technical interviews are not a test, and do not treat them as such. Coding the “correct” solution is a component of the interview, but it is not the only component. It’s totally normal to see a question and not know how to do it immediately. Apart from a correct solution, interviews are often looking for:
    1. Communication: Can you communicate your thought process well, describe the benefits / drawbacks of your approach? When the interviewer offers recommendations, do you try to understand what they’re communicating?
    2. Code Clarity: Is your code easy to read and understand? This often supports communicating clearly
    3. Testing / Analysis: It’s pretty common to make small errors when you code. Do you pick them up? Do you think of good test cases to test your code? Can you analyze the time/space complexity of your code?
    4. Openness to Growth: Especially in entry level and intern roles, people often look for someone who is willing to take feedback, and takes challenges with a good attitude.
  2. Getting stuck is normal. Prepare for it. Here are some strategies when I get stuck:
    1. Make the problem clearer: Sometimes, the problem is just badly worded, it’s the interviewer, not you, and sometimes the problem is expressed in a paragraph and not concise at all, I find it easier to think about the problem after I highlight key points.
    2. Break down into components. Can you break the problem down into individualized components and showcase you can solve parts of it, even if it’s not the whole thing.
    3. Work through an example: Pretend you’re a computer and work through an small example / instance of the problem, and break down how your brain handles the problem.
    4. Prepare to ask for help: Sometimes you need a little push, sometimes the process of composing your question properly helps you think of the solution. When asking for help I always recommend describing what I know first / the problem solving approach I’m thinking, then ask for guidance on a specific area I’m having trouble with. This helps in multiple ways:
      1. It reminds the interviewer what headspace you’re in for problem solving
      2. You are more likely to be given more relevant advice
      3. It better mimics asking for help in a work environment where you provide your coworkers with context, instead of saying “I’m stuck”

  3. Use the time to highlight your strengths appropriately.
    Earlier I highlight that code isn’t the only thing that we’re looking at a lot of the time. Think about how much time you expect to spend during your interview doing what (e.g. how much time is communicating the problem, coding, analyzing, and discussing) – sometimes interviewers guide you on this, but it’s something you should think about too. You don’t want your interviewer to be filling out feedback and have them realize they didn’t get the chance to see your testing skills. I like the UMPIRE Interview Strategy as a starting point on how to structure your interview

  4. Think about strategies for clear communication. Communication can do wonders for your interview. Here ar some things that may be helpful.
    1. Leverage comments when you can. If your someone whose mind runs from thought to thought very quickly. I highly encourage you to practice tabling your concerns and thoughts through comments while coding.If you are in the middle of coding, and realize you need to handle a very -fixable- small edge case - I highly recommend writing a comment, and saying I’ll take care of this at the end.
    2. Write method signatures to break down functionality, implement later. If you’re coding, and you want to say, use a function that you know you can write, but isn’t given to you, write the method signature, and finish the method later.

    These examples offer 2 benefits:

    1. Better communication: sometimes if you’re jumping from thought to thought, it is actually really hard to follow. Not to anyone’s fault.
    2. Solving the important parts first.The core of the problem (often the overall problem solving approach) is a lot of the time more important than the small edge cases you didn’t get to finish, or the method that’s not given, but is really easy to write. In the case you run out of time, it’s much more important you solve the main problem.
  5. Most interviewers do want you to succeed. Every once in a while you do bump into someone who is having a bad day, and seems distracted, try your best to not let that get to you.

Parting words — Be intentional on what you’re spending your time on - both preparing for the interview, and during the interview. Make the most out of every experience - be curious about what other engineers do, even if you feel like the interview didn’t go well. Ask questions to see if where they are is somewhere you eventually want to be.