Leetcode blog: AMZ | Google | Facebook | Offer | Reject| Reject | My journey from failure to offer at FAANG

March 9, 2022

AMZ | Google | Facebook | Offer | Reject| Reject | My journey from failure to offer at FAANG

Here is the article.  

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).

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.