This is my area of expertise - FAANG interviewing (DS&A, SD, behavioral specifically). Also disclosure that my company has fairly expensive coaching, mentorship, practice etc... for these interviews **BUT** I'm giving this answer with my personal hat on and not suggesting that.
The most common issue I see is people practicing LeetCode alone by themselves and fiddling with problems until the tests pass.
It can feel like the interviews are a game to beat, but DS&A is really about testing your problem solving process and communication of that process.
So some advice is to:
1. Follow a consistent problem solving process (you can google around).
2. Practice speaking out load through that process when you practice.
3. Don't underestimate easy and medium problems, don't skip too far ahead to hard ones.
u/controlpy wrote (the comment Michael replied to):
Mostly most of my preparation was on leetcode, but my last intervention wasn't a typical DSA and surprised me, even if it was a easy one.
Answered here so I don't repeat the same question:
https://www.reddit.com/r/cscareerquestions/s/zylknImW89
u/michaelnovatireplied·
FYI, using a problem solving process applies to all problems- beyond LC and more reason to try that approach
u/Azinuru wrote (the comment Michael replied to):
In regards to your first point of advice, I myself did some digging and among the blogs and posts I read, most just mentioned data structures and various problem solving techniques (such as 2 pointer, backtracking, etc.)
What would you suggest is a formulaic process for solvin
u/michaelnovatireplied·★ FEATURED
RE: Problem solving methods, so we're on the same page:
I'm not trying to promote anything so I'll share the one that my company developed that I think is good (because I'm biased) and another one as well.
[https://formation.dev/blog/the-engineering-method/](https://formation.dev/blog/the-engineering-method/)
[https://www.enjoyalgorithms.com/blog/steps-of-problem-solving-for-cracking-the-coding-interview](https://www.enjoyalgorithms.com/blog/steps-of-problem-solving-for-cracking-the-coding-interview)
The idea is even higher level than specific approaches, and instead more about the logistics that people often overlook and rush through problems under pressure and crash and burn when they go down the wrong path.
\-----
The specific techniques you are mentioning I call 'tools' and my view on those is you want to be an expert at using a few simple tools. The most experience handy-person can do a lot with a 30 year old hammer, and you don't need a brand new power tools set to hang a phooto.
So those things are like:
\- DFS/BFS (both recursive and iterative) - you want to be able to write these out as easy as writing your name, many problems include them.
\- sliding window and fast and slow pointers (for various array problems)
\- LinkedList manipulation (a lot of people mess this up under pressure)
\- hash tables and when to use them (getting O(1) lookup with a O(N) setup)
\- binary search and specifically: n-log(n) sort + binary search to reduce polynomial lookup when doing frequent lookups
\- be really comfortable with recursion in general + memoization as a performance optimization (backtracking)