Meta: coding interview preparation

https://www.geeksforgeeks.org/graph-and-its-representations/

https://medium.com/@nickciubotariu/ace-the-coding-interview-every-time-d169ce1fd3fc https://medium.freecodecamp.org/coding-interviews-for-dummies-5e048933b82b

I used 3 main resources. Cracking because it's the classic. However after going through it 2 times I was missing some (deeper) theory and implementation details. That's what 2 offers. I especially liked the Java best practices. As a reference I used 3 although a lot (including 4) propose Skiena's The algorithm design manual

Graphs for example

Most of my information on graphs comes from 2 (theory and problems) and 3.

Graphs are important, says Google. However 1 has almost no theory on graphs and only one problem specific to them. Graphs can be implemented in 3 ways, says also Google4 Both 2, 3 (and [5]) only mention adjacency matrix and list though. Both 2 and 4 agree that Dijkstra is probably off limits for a technical interview though.

Before

  • Prepare for remote coding using simple editor without autocompletion for online. Most companies go for this method (e.g. Google->Google Doc, Microsoft->Codepad, Palantir->Hackerank). That's when you realise how much you rely on autocompletion. Stripe was interesting in that they let you use your IDE while you screen share with them.
  • For onsites: simple paper (or whiteboard if you have one). In Uber they asked me for my laptop so I practiced on an IDE too.

On the interview

  • Clarify the format of the input and output, e.g. battleship question.
  • Take a minute to think and sketch the algorithm in paper, it helps you visualize things.
  • Start discussing the simplest, naive, brute-force solution first - and say that you are doing that
    • It gives you confidence to have at least solved the problem even in a trivial way.
    • It could be all they ask for (the problem is too difficult or you will discuss -not write- an optimized way)
    • The only problem with this approach is if a brute-force solution is not performant enough or not even correct and you need DP or something else. While discussing with the interviewer you should figure out if the brute-force leads to a dead-end and you need another approach.
  • Don't run your edge cases first!

In a rush?

  • Recursion (especially in trees, lists)
  • Iterating 2D arrays (row and column wise!)
  • Graphs and their representations
  • Permutations/Combinations
    • Only the coefficient code, not that common in my experience
  • Generate all sequences
  • Language Specific
    • Reference system, garbage Collection
    • Conversions among Types
    • Collections/Streams API
  • Sorting
    • High level repetition, implementation of insertion sort.
  • Binary search
  • Dynamic programming: high level

Groups of problems - TODO

  • Given an array, find subarray where a condition is fulfilled and return the number (not the array)
    • Sum is X (17.8 in 1)
    • Product is Y (Leetcode 152)

Resources

  • Cracking the Coding interview1 and the accompanying repo
  • Elements of Programming Interviews in Java2 and the repo
  • Algorithms in a Nutshell
  • Palantir