"So you can make Android apps, but can you compute the Ackermann function Ack(4,4) by hand!?"

Having published four apps to the Google Play Store and feeling confident with my Java skills, I decided to buy the holy bible of interview books: Cracking the Coding Interview, 6th edition by Gayle McDowell. Having never properly studied algorithms, I was a little overwhelmed at first. Thanks to my Google-Fu I was able to find Youtube videos, blogs, leetcode.com, and more blogs to break down concepts and get me up to speed in a day. With each example I saw, the concepts like Big O notation and search algorithms became easier to digest. It also didn’t hurt to brush up on data structures.

The book starts out with its stated goal: prepare you to land a job. First, it gives you an idea of what to expect as you go through the typical hiring process in any size company from small to the Big 4. It talks about how important your interpersonal communication skills are and how to improve them. Robots haven’t taken all our jobs... yet. It turns out real flesh and bone humans are still highly desired. I found the information on the “behind the scenes” of the hiring process especially invaluable. It details how the hiring companies tend function and what their motivations are while, say, asking behavioral questions.

Onto the Technical Side.
The book is not useful if you try to memorize solutions. This bares repeating. The book is not useful if you try to memorize solutions. In fact, memorizing solutions could actually hurt you in a technical interview. Technical questions are designed to test how you reason. This is impossible to assess if you regurgitate an answer. If you can’t verbalize your thought process the interviewer will simply ask for a more optimal solution, give you a more advanced question, or both.

The hardest part.
As apparently many people did online, I struggled with this question: How do I get good enough at algorithms if I can’t peek at the solution? This is where an important concept called “Figure it Out” comes in. It’s my name for the algorithm to solving algorithms. Of course you can peek at the solution, but only as a last resort.

The “Figure it Out” Algorithm:

1. First thing I do is attempt the solution.
2. Then I walk away for a few minutes and attempt the solution again but like my life depends on it.
3. After that I take a look at my approach.
4. Analyze any blindingly obvious assumptions.
5. Try to solve again.
6. Go to the back of the book and look at the hint.
7. Try to solve again with the hint.
8. “Rubber ducky”. Verbally explain to an inanimate object and/or write down, in excruciating detail, what you’re stuck on.
9. Analyze the hint and compare it to what I already know.
10. Repeat steps 7,8,9.

You will struggle!
(It’s expected.)
If you still haven’t found the solution, that’s perfectly okay. In a way, you’ve already demonstrated competency in being able to verbally reason about the problem and getting “close enough”. Going to the back of the book and reading hints for problems is not cheating. The interviewer will give you a nudge in the right direction (hint) while you struggle during the interview. Getting stuck and being able to “rubber ducky” your way closer to a solution given a few hints is a tremendous feat!

If all else fails.
Find the solution in the back of the book. And analyze how the solution differed from your approach. Sometimes it’s something dumb like “I forgot to decrement this variable in a binary search”. Other times the solution is clever or a paradigm shift like “I need to think of this type of problem in a conceptually different way”. The important part is understanding how to reason your way through the problem.

One last observation.
I find it easier to learn and work through algorithm problems when I can appreciate the mathematical concepts involved. Sometimes the problems seem so trivially dumb that, in the back of my mind, I’m thinking, “When would I ever need to solve this in real life?”. Usually I try to think of a comparable problem that relates to the real world. If that fails I try my best to appreciate the problem from an academic mindset. The problem can be interesting in and of itself.