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 Google^{4} 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 interview
^{1}and the accompanying repo - Elements of Programming Interviews in Java
^{2}and the repo - Algorithms in a Nutshell
- Palantir