I wanted this post to be about my story and maybe inspire someone in a similar situation, rather than specific questions. (it is a little long, so sorry about that).
I also want to give an immense thanks to the Leetcode community. This site is an invaluable resource.

I structured this post as follows:

• Interview experiences at each company
• My Journey
• Closing thougths and recommendations

If you are looking for the exact questions, sorry to dissapoint. You can stop reading now. You will be able to find those on the other great L.C. posts. All I will say is that the problems I got were very similar if not identical to the ones in L.C. for the given company.

Experiences at Each Company:

Google

• Recruiter contacted me in Nov 2019
• Skipped straight to on-site
• Virtual On Site sessions mid June:
  • 3 Coding Rounds, 1 L.C. Medium 2 Hards .
  • 1 System Design Round .
  • 1 Behavioral .
• Result: Reject

Amazon

• Submitted application via an internal referal. Recruiter contacted me around Jan 2020
• Did Online Assesement Beg of June -
• Virtual Onsite Mid June:
  • 3 Coding + Leadership Principles. All L.C. medium -
  • 1 Sys Design + Leadership Principles. -
  • 1 Bar Raiser -
• Result: Offer

Facebook

• Recruiter contacted me in Nov 2019
• Phone Screen, 2 problems. 1 Easy 1 Medium. Beg June 2020 -
• Virtual On Site mid June 2020
  • 3 coding rounds. 2 problems each round. 1 LC easy. 1 LC medium -
  • Product Design -
  • Behavioral -
• Result: Reject

Spotify

• Applied via a referral Jan 2020
• Phone Screen Beg June - 1 LC easy -
• Virtual On Site mid June 2020:
  • Behavioral -
  • Sys Design -
  • Coding round - 1 Medium -
  • Case study (troubleshoot an app) -
• Result: Reject

My Story

So, about me. I am in my mid 40s, have a family and am a guy with many interests. Even though I knew some coding, it was mainly relegated to assembly language in microcontrollers. I had to learn from scratch. Many years passed and eventually I transitioned to web development.

I don't consider myself a very smart guy (just a little hard-headed and persistent). I do not have a C.S. background. I had not a clue of what a binary tree was, big O, recursion, etc... To me that was all useless alien voodoo. And why should I? All of that stuff was abstracted away in the libraries I used in my every day work. I was more focused on testing, meeting team and product goals, team dynamics, etc... going happily about my Software Engineering career blissfully unaware of what was under the hood.

Then a few years ago, Facebook and Google recruiters contacted me. I gave a timeline of 3 months. I looked at the off-the-shelf material they sent me and realized I had not a clue. So, I started looking at some books and naively purchased one of those on-line courses with x amount of questions. I had no idea there was such a thing as Leetcode.

I pathetically failed both phone screens. Lesson learned: you gotta really, REALLY up your game.

Time passed. A few companies and roles. Then suddenly, by the end of 2019, I found myself without a job and a nice severance package. Coincidentally (I hate to admit that sometimes there are no coincidences) Google and Facebook recruiters give me a call to see how I was doing. So it seemed all planets were aligned. I had all the time in the world and some resources to pursue this venture. A once in a lifetime opportunity!! (specially for a grown man like me with so many responsibilities). I agreed to follow up later when I was ready to take the leap.

I put myself in the mindset of a professional athlete planning for a marathon. Or an MMA fighter training for a major tournament. I figured that anyone with no major health issues can finish a marathon. You just need proper planning, discipline and training. Same goes for this FAANG interview stuff. Hey, if I implement a jitter supression algorithm in assembly language, design a double sided printed circtuid board or code up a microservice gateway, then surely I can learn this, right?

This time, I wanted to make sure I was absolutely well prepared. I knew there were some very tight goals. I should be able to complete almost any L.C. medium - hard in a reasonable amount of time. I should be able to code clean well organized code. I should be able to properly reason and communicate through problems. I should have my act together on system design. I would have to be able to test myself against these goals to measure progress and have some sense of preparedness along the way.

I put together a very very detailed plan, with milestones and expected timelines. For example: by such date, I will finish reading and thoroughly understanding this book on algorithrms. Or by such other date, I will have completed x number of problems. Or by date X, I will be able to finish most medium problems in less than 40 minutes.

The plan was organized around stepping stones. Starting from the most basic concepts and building up to the more complex ones. I wanted to make sure that my feeble foundation was solid. I couldn't just assume and "wing it".

So, my first step was to get into some C.S. theory. I first started with "Introduction to Algorithms". But after a few chapters, I was noticing I was getting bogged down with math and was feeling I was steering off target. So I switched gears and decided to try Skienna's "The Algorithm Design Manual". I found this book to be way more digestable and to the point (I also enjoyed his war stories). After munching through all chapters and doing most of the exercises I felt I was in a good place to start some problem solving.

So I started probing all around: Hackerrank, Byte by Byte, Leetcode. I also tried the "Elements of programming interviews" book. After atempting some problems, I was noticing I was taking way too long and wasn't really satisfied with my approach. I also noticed I was a little disorganized. After going over many subjects (math, graphs, bit logic, D.P.) , even though I understood the theory behind them, I was failing to efficiently find solutions. My mind would sometimes get stuck in a wondering loop.

My routine at home was also very inconsistent. To make matters worse, the great COVID pandemic struck and now my wife and I had the kids at home and had to split duties to keep them educated and entertained. I had to make a very drastic change.

I decided to shift my schedule and wake up at 5:00 in the morning, so I would have a few precious hours to really focus. Then I also agreed with my wife to some strict schedule so I could have a consistent amount of blocks of time to be able to grind.

I also needed to adjust my strategy to give it some structure. I went through many discussion forums looking for how other engineers approached it. What strategies. What books. What timelines. What plans.

After this regrouping, I narrowed down my strategy to this:

• Focus just on L.C. Start with easy ones. Once I felt comfortable, go up to mediums and then hards.
• Go wide rather than deep. Don't focus on just one subject, but rather be varied.
• Focus on lists. Example "100 top interview questions", etc...
• Keep a record of time.

On that last subject, I wanted to be able to gauge my progress. Like weight loss. You don't know what you can't measure. So, I put together a google sheet with the following columns:

• type (array, DP, graph, etc...)
• problem name and link
• level (easy, med, hard)
• start date time
• end date time
• total time spent
• timing . (red yellow green)
• outcome (red yellow green)
• notes (did I nail it? why? why did I fail? what to look for?)

On timing and outcome, the idea was to use a color code to score my performance. If for instance I was able to solve a medium in about 20-30 minutes then that was a green. If around 60, then that was a yellow. More or not at all then that was red. For the outcome, if the solution was on spot as far as optimization and simplicity, then that was a green. Other wise yellow. And If I couldn't solve, then it was a red. This would give me a visual gauge of my progress. As I accumulated more and more problems, I could reflect and see my progress and confirm I was moving forward.

So with this approach, things started to get a little better and more organized. I would come up with solutions, code them. Then compare with solutions on discussion forums. I feel the discussion forums is were I learnt the most. Were I was able to extract the most interesting patterns to add to my toolbelt.

On systems design, because of my years of experience at companies building web products, I had a lot of exposure on infrastructure (specifically AWS). I felt confident I would be able to pass the systems design interview. But I didn't want to take this for granted. So after reading some forums, I decided to purchase "Building data intensive applications". I also got grocking system design interviews at *** i o. After going through that material I realized how lacking I was.

The final piece in the plan was getting some real world checks. If you just study by yourself, even though you are solving things to your satisfaction, there is absolutely no guarantee you will succeed in a real interview, with all the surprises, and time pressure. The same way a marathonist will perform some preliminary short races before approaching the big race. Or a fighter sparring at the gym.

I started booking mock interviews. I first tried p-r-a-m-p. Here you take turns to interview a fellow engineer on a problem provided by the platform. This helped in getting a reality check. But I wasn't very happy with the interviewers. I was feeling that most had no experience interviewing nor understood what signals to look for in candidates. So feedback was not that great.
I then tried i-n-t-e-r-v-i-e-w-i-n-g-.i-o Here I felt I met my match. I was consistently failing on all mock interviews. Not only on problem solving but also on timing. I started getting a little desperate and discouraged.

So I adjusted my plan again. I took a break from mocks and focused on timing. I used the L.C. mock interview feature. First thing in the morning I would do, was take one or two L.C. mock interviews. That was tallying a consistent 4 easy to med problems just in the AM.

I also noticed that there were some emerging patterns in most of these problems. Even though in an ideal world, you shouldn't attemp to just "pigeon hole" a problem to a pattern, I felt that given the time constraints and nature of interviews, trying to narrow down to patterns was a good strategy. This was also confirmed by a session I had with a real Amazon engineer on a mock interview I got from g-a-i-n-l-o . He basically told me to structure my training to these timing milestones:

• 10 minutes, clarify assumptions, edge cases, define method. Define pattern:
  • straight forward
  • BFS / DFS
  • Flood fill
  • Brute Force
  • Backtracking
  • D.P
  • Greedy
• 10 minutes come up with a brute force solution.
• 20 minutes, code
• 5 minutes, test

Those milestones were also corroboarted by some passages of Gayle Lackman's "cracking the coding interview"

To learn more about patterns, I purchased also from e-d-u-c-a-t-i-v-e the "Patterns for coding questions". It was very helpful (although not full-encompasing and must be taken with a pinch of salt).

One of the things I struggled the most (and noticed most Leetcoders do as well) was Dynamic programming. There was no damn way around it! It was pure esoteric magic. There was a course in e-d-ucative as well and that helped inmensely (next to a TON of practice).

Months passed. I was getting better, but still not were I wanted to be. My timing was not there yet. I was participating in L.C. contests, but never finishing all 4 problems. Mock interviews were sometimes succesful, sometimes not. But I was getting used to it. Essentially developing a thick skin against judgement from some random person I would never ever meet in my life again and not letting that affect me. Also getting smarter with time, probing questions, coding some Brute Force solution if no optimal was found, to at least deliver something.

I was in touch with recruiters, but kept pushing the date of the interviews, since I was still feeling unprepared. Months passed. 4, 5, 6. Literally 400 leetcodes. Dozens of mock interviews. I was still not satisfied. Something was missing. It got to a point in which I felt I was stuck beyond repair. Seemed like I wouldn't be able to get any better during this period. Maybe the next planet alignment would bring a better harvest?

At this point, I just had to take the leap. No matter how many more L.C.'s I would do, I didn't feel I would get any better. Plus my resources were starting to dwindle and for my own sanity I really needed to start working. Be in contact with other engineers. Work towards a common goal.

So I decided to take the plunge. I figured that if I didn't get any offer this time, at least I would have done way better than the last time. And I would be able to do much better in any other non-top-tier company.

I was scared of getting bad interviewers or impossible questions. I was concerned about embarassing myself. During the day of interviews I was feeling like cancelling the whole thing and hiding under my pillow. To relax, before sessions started, I woul play a few funny youtube videos.

Phone screens, online assesments, virtual onsites, behaviorals, systems design, coding. All came and went.
Got several rejections. But, somehow planets, asteroids, galaxies, commets, and aliens were all aligned for Amazon and got a call from recruiter and an offer.

Closing Thoughts and recommendations:
If you made it up to here, I really really apreciate you took the time to read about me. Sorry if it was too long.

• Have a plan. Put clear milestones. Clear objectives. Clear Dates.
• Be willing to adjust your strategy several times during your journey
• Measure yourself.
• Don't be foolish. Don't assume you'll wing it. Be honest. Identify your shortcomings. Work on those.
• Get reality checks. Get out of your comfort zone. Do those mock interviews. Get used to the uncomfortable interviewers. Get used to the disapointing feedback. It WILL make you stronger.
• Be disciplined. Be consistent. Write down your progress. So you can see that you ARE in fact moving forward.
• Reward yourself. Be kind. This shit is hard. Very hard. You deserve rewards for your hard work. Take a few minutes to watch some silly youtube. Go to the coffee shop (or order online if social distancing) and get that pastry.
• A very very small percentage of the engineers at FAANG are Alan Turing kind of geniuses. The rest are guys like you and me who most probably failed 2, 3 or 4 times until they got the gig. They went through the exact same journey you did.
• Force yourself to solve problems before looking at solution. But put a reasonable time-limit. Say 2 hs. 1.5hs... then look at solution, take notes of what you learned.
• L.C. community is pure gold. You'll find invaluable explanations, patterns and workarounds.
• DO contribute. Even if your solution does not seem great, do post it. Try to add explanations. This gets you into the mindset of communicating and explaining why your solution works. Plus, if it sucks, you might get the gift of feedback from a fellow Leetcoder.
• Narrow down your coding options. If your language has 10 ways of accesing a hash map, focus on the one or 2 that fit most cases. Same for other coding structures (loops, conditionals, etc..) This will save you time.
• Take note of patterns and try to memorize them. Level order BFS traversal should be a no-brainer and you should be able to code it with your eyes closed. Same for Initializing a hashmap with frequency of occurrence counts. Or a BFS for exploring adjacent cells on a matrix. Or iterative Binary search and it's many cousins...know them by heart and be able to invoke them on a moment's notice like a Pokemon Master.
• During interviews, make sure you are giving interviewer the signals they are looking for. Try to manage time well. Ask them "how are we doing with time". Ask good probing questions "Does this approach sound good? Should we code this?"
• Try to get a brute force approach first thing. If you can't optimize, at least you can code that and interviewer will know how good your code is. The outcome might be "weak hire" vs "no hire".
• Placeholder methods are your friend. Specially on tight time. If your algorithm requires initializing an MxN array of distances, just abstract that in a method, put the placeholder signature, let your interviewer know what it does and that you will code it later and keep moving! Most probably the backtracking method that will follow is the most important piece that the interviewers are looking for.
• Don't underestimate testing your code. Always do it. Start with small inputs and simple cases. Then consider edge cases and expand to more complex ones. Go line by line. Pretend you are the IDE debugger and update variable values as you go. Demonstrate that your thing actually does what it claims.
• On system design, don't just read the hell out of everything. Practice whiteboarding solutions from scratch. Reason and talk through them. Just like with your L.C. grind, try to get sys design each day. Ask yourself why 5 times, when deciding on a given db technology, a parition key, a given db index, realtime vs async, etc... You need to be able to justify your decisions and your case has to be bullet proof.
• Behavioral: Use STAR format. Put on a doc your whole work history. Then isolate individual situations, projects, successes, failures. Make a story out of each.
• That last point is specially important for Amazon and their leadership principles.
• Luck can be a big factor. So don't put all your eggs in one basket. Maximize probability of succesful outcome, by getting lots of interviews, strategically timed out.
• Don't give up.
• Don't beat yourself. You are amazing.

This is just a journey. The destination doesn't matter that much, but what you've learned along the way. These months have taught me a lot about myself and how far I can go. I am overall a better engineer now and am starting to think about embarking on projects that seemed like rocket science a few months ago.

Don't feel bad if you didn't make it this time. There are a ton of amazing companies out there with incredible people from all walks of life, from whom you will learn a lot.

Finally thank you once again for reading me.
I wish you the best.