The problem given for a coding interview doesn’t have to be only algorithms. There can also be language knowledge questions, Object-Oriented design, Functional Programming, Systems Programming. Anything where you may need to write some “working” code on the board. Here’s a few pointers to get through it.

Make sure you know, what you claim you knew on your resume. Perhaps it’s best to grade yourself as {expert, good, fair} for different skills. Remember, doing practice online at a computer is NOT the same as doing it on a whiteboard. At least do it on paper, where it’s slow.

The best is to practice standing up at a whiteboard with someone watching, and of course, it’s better to always be coding.

Questions

I’ve already covered what topics in a previous post, and there’s plenty of information out there about previous questions asked by companies:

  • CareerCup
  • GlassDoor by company
  • LeetCode also filters by company; if you pay.

Designing

Make sure to work out the algorithm completely, until you would normally think about pseudo code level. You probably wont have time to pseudo code it, and they want to see real code.

Remember to mention the brute force quickly, but try to move through it to an optimal solution, going through memoisation or ideally dynamic programming if necessary.

Coding

  • Write APIs; be lazy. Remember that you cannot easily edit the code later.
  • Get the core of the algorithm down first with APIs.
  • Abstract out trivial, non-essential data-structure to implement if enough time and asked.

Testing

Make +ive and -ive test cases, make unusual test cases, don’t fall into the trap of a “simple”, small test case that happens to be a special case.

  • Special cases?
  • Looping.
  • Backtracking.
  • Memory allocation.

Panicking

Interview seems to go be going ok? Suddenly hit a dead end? Don’t just stand there with dead air and no forward progress, take advice from Gayle, run though this n-step plan:

  1. What’s the brute-force solution?
  2. Solve the example problem manually with your brain; can you code that?
  3. Can you solve it for n=0, n=1?
  4. What are the generic base cases?
  5. When can it terminate?
  6. Can you solve a simplified version of the problem?
  7. Can you make a recursive solution from the above?
  8. Make the recurrence relation.

Commit this list to memory. At some point you will suddenly freeze, having a “muscle memory” list to go through can really save you and get you back into the interview.

It’s amazing how good the brain actually is at solving problems, if you get stuck, just let the brain actually have a go.