Landing a SWE job at Google is no easy feat. Being self-taught seemingly hinders one's chances, but how about adding to it:
- being thirty-something years old (closer to 40 than 30 😅)
- having wife, small kid and a dog
- being only source of income for family
FAANG interviews are notoriously difficult. Good news is that if I could do it, so can you! Here are some battle-tested tips how to prepare.
How to study
In my circumstances time I could spent on learning was pretty limited. Full time job, small kid, wife - there is not much time and energy left in a day.
I tried to do 8 hours on weekends and fail miserably because kid wants to play (and I want it to!), wife wants to go to IKEA (and I want it to!), dog wants to go for a walk (and... you guessed it).
I tried late nights after family goes to sleep and failed again. I would do some productive work for first hour and then sit for next 3 staring at the screen not even noticing that I'm just passing time and depleting myself from sleep.
What changed my approach was to stop thinking about prepping to "the interview" but rather to be better software engineer. From being goal oriented - passing the interview - to being process oriented - being better software engineer.
I would do 30-60 mins daily sessions and that was a game changer. Not only I had more energy for my family, but it also learned at higher pace. Having shorter sessions allowed me digest the material better, think about it throughout the day and make it stick to brain's long-term memory.
Know your basics
Think about it as your tools. You need to have them handy and know how to use them. In 30-40 mins that you have to solve a problem(s) there is no time to figure out how BFS, DFS, works - you HAVE TO have this knowledge available to you at will.
Must know topics IMO in no particular order:
Data structures:
- Linked lists
- Arrays
- Maps
- Sets
- Trees / Graphs / Tries (this tend to very useful)
- Heaps
Algorithms:
- basic sorting algorithms
- Dijkstra's algorithm - a lot of interview problems are some sort of variations
- backtracking
- dynamic programming
- tree traversal (DFS, BFS)
Practice
I distinguish two phases of practice:
- Basics
- Problem solving
Basics
For basics there is not other way that just writing code. Once you understand basic concepts you need to be fluent in transcribing those ideas to code. Don't memorise implementation, understand well enough that you can implement it without effort.
The goal is to build ready to use mental blocks. If part of the problem is to traverse a tree you could say "I'm going to use breath-first-search, it's going to be O(n) time complexity" and focus on next part of the challenge.
You need to be ready to talk about details of implementation, but chances are that you won't need to write it down.
Problem solving
This might be a bit controversial, but I believe that you either know the solution or not. There is to little time to figure it out on the spot. This is where purposeful learning comes to play.
Start with easy problems, get comfortable. When it's getting to comfortable start moving to medium difficulty. Up the ante enough to keep you engaged but not discouraged. If you're stuck for more than 15 minutes, then just read the solution - that's how you learn!
Once you're fairly comfortable with coding up the solutions... stop coding. Solve it in your head and check answers in forums to verify. My rule of thumb was no more than 10 minutes per question. Again, if you can't solve it just lookup the solution, try to understand it and move on - chances are you will encounter this question again.
This approach should develop in You some intuition what data structures to use, what kind of algorithm problem lends itself to. You will rather not encounter the same question in the interview, but it might be similar.
During interview
Think out loud
Your thinking process matters. Your interviewer can't read your mind, read it to her. If you considering array, say it. If it's something You discard, explain why. This also allows your interviewer to push you in the right direction.
One thing to pay attention to is rambling. If you notice that your thoughts are chaotic and you interviewer is confused, stop for a second. Say that you need a minute to think and relax.
Explain your approach
Before You start writing code you have to have clear picture how to arrive at solution. Write down your algorithms in plain words and discuss it with your interviewer. I always ask directly "shall we proceed to coding?". Most interviewers will signal to you if she has some concerns and you should correct your approach first.
Use helper functions
Focus on high level solution first using helper functions and fill them out later. For example: if you have algorithms that need topological sort, just write it as you would have it - topologicalSort(items) - and tell your interviewer that you will implement it later. Here it's important that you know your basics and can identify time/space complexity for those helpers so interviewer feels confident that you know how to implement it.
It is possible that interviewer will get enough signals and you won't have to fill in those helper functions. The key point here is to have complete algorithm in time. Chances are that there is a follow up question and your helpers become irrelevant anyways.
Just try!
Let's face it, chances that you will nail it in first try are slim. Why not get some practice then? Apply early and see where you stand. Don't get me wrong - try your best, prepare like your life depends on it, but keep in mind that it may not be your last time applying ;) I applied to all FAANG companies and others known to have similar interview process, just to get some reps in. Even if you apply to company that is not you first choice you might ended up getting hard to reject offer (BTW that's how I ended up at Amazon in Berlin).
There is a lot of stress involved and you will forget about details so take notes about the process:
- what questions were you asked
- what worked and what not
- what areas to focus next time
It will come handy next time, trust me.
Final thoughts
It's not easy, but it's doable. Treat it as a marathon, not a sprint. If you think about the whole thing as a means to become better software engineer, with a possible side effect of landing your dream job it will become easier and pay dividends in your career regardless of the outcome.
Resources
Grokking the Coding Interview: Patterns for Coding Questions - great place to start
LeetCode - hands down best practice platform
Abdul Bari's youtube channel - some more advanced topics for curious ones
AlgoExpert - easy to follow, worth the money
This article was originally published on my blog stuffs.dev
Top comments (0)