I want to give back to the community, given that previous interview experiences helped me in my search.

Note: I signed a NDA with all companies, and will not be providing the exact questions. I will share as much as I feel I can.
Also, this is a long post, so be prepared. I will attempt to answer any questions that people might have.

Background: fullstack engineer at a large company. 8 YOE. I had never done a single LC problem before this process and never focused on algo based interviews before. Mostly out of stubborness and spite for the process, and also because I was able to just "figure it out" and never needed to grind. The industry has changed, and I understand I can no longer function in the old way of doing things.

I work at a fairly relaxed company and have good WLB, so studying 2 hours a day wasn't that big of a deal. If you work at a company with reasonable WLB, you will likely have time to devote to this without feeling burnt out.

Studying
I started studying in a fairly relaxed way 12 months ago. I didn't give myself any timelines or pressure, just learning at my own pace. My plan was to interview when I felt ready.

Algos

I have a weak formal background, and didn't attend a strong CS program. Therefore, I was already at a bit of a disadvantage and needed to make up for it.

• I literally read a computer science textbook I found off Amazon. This was extremely helpful from a theory perspective. Before doing any LC problems, I wanted to build a solid base. In the time between school and now, I had forgotten some of my graph theory knowledge, for example. The specific textbook was: Algorithms 4th Edition by Robert Sedgewick. It's not encyclopedic but it's very approachable and a great choice for what I was looking to do.
• 500 LC problems, but I'd say comprehension is far more important than the number of problems. This is just the amount it personally took to even begin understanding some of the algo patterns and data structures. DP took me forever, for some reason. Idk why. Keep in mind I was basically starting from nothing and was never formally schooled in some of these techniques. I never learned dynamic programming, prefix sum, Kahn's in school.

System Design
I have a fair amount of experience here, so I didn't need to study too much. Below are the best resouces I could find. I could write another 1000 words on this topic alone.

• DDIA (designing data intensive applications)
• Gr****king and stuff like that
• System Design Interview on youtube (search for system design top k heavy hitters)
• Various engineering blogs of major companies
• White papers of major database systems (dynamo, TAO etc)
• random stuff like google's non abstract system design paper

Google (Reject)
Big Ideas

• Google questions always start with some constrained question, and the move into a more generalized solution. You want to be thinking about how your basic solution can be generalized into a larger solution. This caught me off guard at first. For example, the engineer might say, our input is static, or, we start at a single index. Then we take that and move into a more complex and general problem.
• Google's process is extremely random. Some people are asked reasonable mediums/hards, some people are asked difficulty probabilistic questions, NP hard, etc. During the process I got conflicting feedback such as "didn't run through enough tests cases" and then the next interview, "too much time spent testing". Expect nothing and be ready for everything.
• Clarity and communication of thought is extremely important for Google. They don't want you to smash problems as much as they want to see how you think and solve.
• You are unlikely to be given the exact problem, unlike FB or Amazon
• You are unlikely to be given a problem you've seen on LC before
• The bar is high, but also somewhat random (see above).

Phone Screen
Question was a hard string problem on LC, one of the most common hard questions in the past 6 months. I hadn't done the question ahead of time, but was surprised to find it on LC. The solution was to create a graph of letters, and if the directed edge does not match our graph, we return false. It was a great conversation and overall was surprised at the fact that I got it (or even close). I think one FB problem, Alien Dictionary, inspired me to use graph theory when it comes to strings.

Onsite
2 system design, 1 behavioral, 2 coding rounds

• Round 1: Behavioral
  • There was nothing really special about this, it was a great conversation and we talked about driving projects, resolving disputes between team members, how to mentor other developers. General job specific stuff. Overall I wouldn't prep for this much and did very well.
• Round 2: Coding
  • I wasn't able to find this problem on LC but I did find some mention in the discuss. The idea was given system events, find whether the event stream hits the error threshold.
  • Started out with a fixed index, and then moved to a more generalized "any index" problem. Solved first with sliding window, then DP.
  • This round went poorly for me, I mostly felt I failed to properly communicate why it worked, the interviewer seemed confused about my time complexity analysis and general solution. I could have done better here, but also felt there was just a disconnect between myself and the interviewer in how we talk about ideas and problems. I felt I had a decent solution for both cases but the interviewer didn't feel my explanation was strong enough.
• Round 3: System Design
  • Design Dropbox
  • There's so much here it's hard to go into details but we went very deep on many things, including password encryption, salting + hashing, multi-data center replication, leader vs leaderless replication. The interviewer was extremely nice but was incredibly knowledgeable.
• Round 4: Coding
  • Never seen this question before, but I quickly deduced it was topological sort and used Kahn's topo sort.
  • Overall a fantastic conversation, the guy was extremely humble and really clicked well with him.
• Round 5: System Design
  • This is such a specific question I don't want to doxx myself, but the problem boiled down to writing a dropbox sync client for huge amounts of data.
  • Think, client/worker patterns, checksums and hashing.
  • I felt my communication on why I was doing some of these decisions wasn't well communicated, and I confused the interviewer by optimizing too early.

Got a call from the recruiter saying I was a strong engineer but there wasn't enough signal to make an offer. Encouraged me to apply again in 9 months. Recruiter said my communications, design and behavioral skills were strong and was a large factor in things moving to close to an offer but ultimately just couldn't justify it. He felt kinda apologetic about it haha, not sure what happened here.

Overall, this was my least likely company to get an offer from, and I was expecting a reject anyways. It was great to get the experience, and I felt the overall process was good for my personal growth.

Amazon (Reject)
Big Ideas

• LPs, LPs, LPs. Amazon is huge on their LPs. Do not ignore this. Provide specific examples, not just vague projects and ideas
• For any given interview, 50% of that will be devoted to LPs. This means that you actually have similar time as FB to reach an optimal solution. This actually fairly stressful, so be prepared for this
• The bar rasier round is also very stressful. They will constantly interupt you, question your knowledge, and cut you off. Be prepared to almost "fight" your interviewer to answer questions.
• The questions aren't that much easier than Google or FB. People say Amazon is an easy offer, but the questions I was given were probably in line with the other large companies.

Phone Screen
This was a matrix/search problem. It's not on LC but if you've done the islands problem or similar matrix search problems you should be good. We talked about DFS vs BFS, how the matrix was actually a graph problem, trees as graphs, A* search, etc. I don't think all of this was necessary but it was an interesting conversation.

Onsite

• Round1: System Design
  • Spent 50% of the time on LPs
  • "Design Uber"
  • If you've done Gr****king, you'll be fine
  • Received high marks on this per the recruiter
• Round 2: Coding
  • bar rasier round, 50% of the time on LPs
  • Hard trie/backtracking problem, probably a few LC problems similar but hadn't seen this before. Think Trie/Boggle problem but a little harder.
  • I had the idea off the bat but the interviewer, talked about the solution and why it would work, but fundamentally he was just not convinced I understood it despite explaining it using a whiteboard, multiple examples, etc . I'm not sure I went wrong here, it just felt like I was expected to fail and there was nothing I could do to convince him otherwise.
• Round 3: Coding
  • Lowest Common Ancestor, tagged Amazon problem on LC, did it in about 10 minutes
  • Follow up: constant space solution
  • Spent a lot of time explaing why it worked, I felt the interviewer wasn't familiar with this question and didn't understand it deeply, it was kinda weird.
• Round 4: OOP Design
  • I hadn't expected this round at all, but we got into library design and OOP principles
  • Honestly I can't even remember the question exactly, it evolved from a very basic question, but along the lines of "build a sorting library".
  • Did well on this, and it was pretty fun. I usually don't get these questions.

The overall vibe from the recruiter was, the bar raiser round wasn't as strong as they had wanted, especially on the LPs. I think I struggled to work effectively while being constantly interupted. Perhaps a good indication of the work culture lol, idk.

Facebook (Reject)
Big Ideas

• FB wants you to grind problems. That part is very clear. Almost every interview had 2-3 problems. You are expected to nail these, optimally, within 15 min per problem. No big mistakes, no serious bugs, if you fail to catch bugs, it's a reject.
• FB asks straight from LC. So grind those problems. But, know that you have to properly and completely explain why it works and not just spit out problems. This ends up being very difficult in practice because you spend 10 minutes explaning, 5 minutes coding.
• Optimal solutions are also important. On almost every question, I was pushed to always do better, both in time and space complexity. n * k is a reject but n log k might be ok. For every problem, learn the optimal solution, not just a working solution.
• The "system design" vs "product design" split is one of the most confusing aspect of the interview. The breakdown is, system design is if you work with large scale systems daily. Choose product design if you're anyone else.

Phone Screen
Less asked but FB tagged problem about doubly linked lists. We actually spent the entire session talking about the solution, optimizations etc. I thought I had failed because we never got to the second problem but was given the onsite pass. So the above "2-3 questions per interview" doesn't always hold.

Onsite

• Round 1: Coding
  • 2 FB tagged mediums
  • I did poorly on this one. One of my implementations had a bug and the interviewer pointed this out. I had to rework the problem and ended up burning some time. We then moved on, but I ran out of time and never got around to running through test cases with the second solution, althought it was correct.
  • I think I was just moving too fast, and it was the first round, hadn't warmed up properly. This was the round that failed me.
• Round 2: Product Design
  • "Design instagram"
  • Did very well here (according to recruiter), focused more on the api contracts and overall design, stayed away from sharding/partitioning/availability etc.
  • Discussion around things like pagination, image resizing service, long polling/websockets
• Round 3: Coding
  • 3 FB tagged mediums
  • Did well on this, able to successfully come up with optimal solutions for every one
  • One interesting thing is this interviewer would test my knowledge. Would ask to improvements to time/space and ask me to explain why/why not it would work. He would ask for improvements in time complexity I knew were not possible, and ask me to defend mt answers.
  • Ended up talking about hypothetical improvements such as A* search and more optimized graph search algos, which was interesting.
• Round 4: Behavioral
  • Felt very Amazon like in focus, talked about why I wanted to work at FB
  • "How did you resolve a conflict with your manager"
  • "How did you resolve a conflict with a peer"
  • etc etc etc
  • Probed very deep into situations
• Round 5: Coding
  • 2 FB tagged mediums, very standard, answered both
  • Nothing special happened in this round, just smashing problems basically

Recruiter said feedback was mostly positive but said that the first coding round was a little rough and ended up being a weak signal. Tried to negotiate to re-do the round but recruiter rejected that idea. Said it was "very close" to an offer but a reject is a reject haha.

Thoughts
The overall lesson: you can't measure your success based on where you are in relation to other people, but where you were before, and where you are now, and where you are going.

• Interviewing is a skill, you owe it to yourself to go through this, just to see what happens and get practice. No amount of LC grinding could have fully prepared me for this.
• People expect you to crush problems, regardless of how well you do on any other rounds or your job level. One bad round and there's a good chance your offer goes with it, for the most part. A good metaphor is a concert pianist. You practice, practice, practice but a few wrong notes during the recital and that's it.
• Communication and behavioral is extremely important and can make up for some gaps in knowledge and skills, but might not make up for an entirely bad round
• This is a hard time to interview and the bar is very high. Don't feel bad for getting rejects, now or ever, it happens. I suspect that you need to get more thumbs up now than in the past.
• Hiring is more random than I expected, your fate is largely up to the interviewer and if you click with them you will do well, if not you may be out of luck
• For someone who has a weak compsci background and didn't grind any LC before this, I'd say this is actually pretty good. I think relatively, I have gotten much better and grown. I went from being unable to do basic easy problems to mostly solving meds and hards (sorta!). I still need to focus on some areas, clearly not there yet, but closer than I've ever been.