99% Of Engineers Never Get Into FAANG And Here's Why - How To Interview Prep

Most people do shallow interview prep that doesn't actually help them learn. Lists like Blind 75 and Leetcode 75 are not enough to truly master the technical interview for Big Tech companies.

Hi! I’m Rahul, a software engineer and founder with a passion for teaching.

#TechCareerGrowth

[itsZio]

A couple thoughts on this video and algo/FAANG in general:

It's funny how in the beginning you talk about all these interview prep programs that are taking advantage of people wanting a quick way in to FAANG when Formation is one of those. A quick look at their site and it's just algo and system design. I guarantee they have nothing special compared to other one's, they all do the same thing in showing you how to approach problems, the process, how to think etc. The bigger problem is not that these companies take advantage of people, the problem is the interview process not being related to the day to day job. You woudn't test someone who runs marathons on how fast they can sprint a 100m dash despite both requiring running.

Earlier in the video you (Rahul) mention that algo's are not a good way to test skill because it's not related to the job. Then at 8:48 the guys says if you didn't do well on an algo, you probably wouldn't do well on a bug or feature. I don't understand how he makes that correlation. For example, if someone spent 75% of their time building apps and 25% leetcode, and another person 75% leetcode and 25% building apps, wouldn't you say the first person would be better suited for the job? The person who spent most of their time building apps probably knows how to deal with bugs and build features better than the 2nd person.

Why don't FAANG and these companies design tests for actual things you would do on the job? There's like 2k leetcode questions, yet millions of bug's that developers could encounter. Why not create problems to the related position? The job postings always show the required skills so a candidate would know what to expect and information could be sent out before an interview on what to prepare for.

Lastly, it would be interesting to interview high level engineers at non FAANG companies that don't have algo style interviews and don't have that FAANG mindset to get their thought's on the industry.

[Derin]

Daniel is the best! I am a current formation fellow and I think he has the incredible ability to make complicated things simple!

[gmt]

I got a job recently at a non faang company to build software for invasive surgery. My interview was not based on leetcode style questions rather emphasis was placed on operating systems and system design questions things I will do on the job.

I personally enjoy solving algorithms/data structure questions but I’m of the opinion that technical interviews are broken. You should not have to study for something you’ll never use on the job. A better and more cost effective approach will be to ask people questions relevant to the job. This will require them brushing up on the required skills leading to reduced ramp up time if they get the job.

[ChocolateMilkCultLeader]

People not understanding concepts and just being Leetcode Champs is something I've been writing about for a while. This is very true. That is why I have atleast 2 days a week dedicated to ideas and theory. However, I do believe that the system rewards this kind of behavior. If I have limited time and energy, why would I dig into the intracasies of graphs when I know that my interview is judged on the LC? In a limited time span, I won't have the time to show my detailed appreciation of graphs, their ability to encode relationships and everything else. Better I stick to 7-8 Graph Problems, get them very well and forget about everything else. Most people couldn't explain the significance of the Well Ordering Principle, even though that is the theorectical basis of recursion.

The hiring itself is fundamentally stupid. It doesn't incentivize learning or depth. I think from a pragmatic perspective, there is no point in learning the ideas in depth, because the interviews will almost never test for them. An anecdote from my own experience helping people with their interviews-

You can go from knowing nothing about CS to acing junior level interviews in 3-4 months. One person I worked with started not even knowing what recursion was (she had 2 years of FE dev). I gave her very surface level explanaition of important concepts, and how they fit together. Then we spent the rest of the time on Leetcode, and specifically communcation during them to portray knowledge. She aced interviews left and right. Till the hiring is fixed, people will continue to try and find shortcuts

Just my 2 cents.

[gagang]

I don't think anyone is trying to "trick" an interviewer into hiring them by memorizing a list of problems. In an ideal interview with an interviewer as experienced as Daniel, you might be rewarded for your approach and how you solve problems. But you still might have another interviewer on the same panel who is expecting an end result and doesn't care how you got there. Unfortunately, there needs to be a structure to train engineers to be better interviewers and give incentives to engineers who are good at interviewing. Therefore you have people who pick a problem 30 mins before an interview and ask that. So, in that case, working on the top most requested questions list or blind 75 is quite helpful.

I have been a coder for 15 years and am still waiting to see a leetcode-like problem in my day-to-day work. It's not fair to judge developers for their ability to solve these Algorithmic Puzzles(which they don't do in their daily job) within 30-45 mins produce a workable result. But that's the reality & people are trying to find an optimized way to deal with that. I know some top-notch developers who refuse to leetcode cause they have better commitments in life. FAANG companies are missing out on this subset of talented engineers because they need help solving the scaling interview problem instead of picking a random question off leetcode.

[quackquack]

1. not every interviewer is like Daniel who focuses on the process. many interviewers got in themselves grinding leetcode style questions.
2. my experience (ex-FAANG) is that companies actually use a rubric to evaluate the candidate's answer on correctness, style and algorithmic efficiency.
3. solving a problem methodically takes time. Obviously, this depends on the problem, but candidates are also expected the produce working, compilable code within 20 - 30 minutes. A candidate will get sympathy points if they make progress through a problem, most of the time if they fail to produce working code they'll get rejected.
4. from the interviewer's perspective, they need to provide their evaluation of the candidate in the interview feedback. It's always easier to pass the candidate based on whether the candidate came up with a working solution, rather than to explain why the candidate should pass the interview based on the progress they made on the problem. This has to do with training, but that takes time and energy, and one may not have the incentive to make such an investment.

[mikedelta]

This is a super and honest feedback for me. I'm preparing for the Meta's Software engineering interview. This is so useful for me.

[wstdonwiteout]

It sounds great to say you are being graded on your communication and thought process but the reality is that's not what I've observed. Very few FAANG interviewers will pass you to the next round if you don't get a working solution in the time provided. And if you only get a brute force solution but not an optimal one, you will likewise be unlikely to pass. You could have amazing communication skills and walk them through every step of the process....and then run out of time because you spent too much of it thinking out loud and not enough coding. This has happened to me many times....and it's why - if you are like most of us who don't have the luxury of 6 months for interview prep - you are still better off grinding leetcode instead of really understanding the DS and algorithms.

[evgenirusev]

Wow this is incredible value. Thanks for sharing these principles.

[subratsingh]

Amazing!!! Now i know why is it taking so much time to go through these.

[shanky]

Nice video, gives a lot of insight to what interviewers are expecting

[vulpixelful]

This was a great interview but I have rarely come across this ideal tech interview. Even if you go through your thought process and keep communication open with the interviewer, you won't be able to go to the next stage without getting to the end in 45 minutes. It would be better if it was a cumulative interview where you go on to behavioral and system design, then your _total_ performance is weighted and graded. I have _only_ gotten job offers where the results of multiple interviews were taken into account, since I'm better at system design than coding challenges at this point in my career. These jobs were at companies with a great culture too, so maybe their way of recruiting is just better 😊

[jaskaranvirdi]

Have to disagree with Daniel here! He paints an idealistic picture of tech interviews. The ground reality is quite the opposite though.

Hate it or love it, Leetcode style problem solving is the only way these big tech companies hire, especially companies like Facebook and Google.

A lot of startups however are learning from this and realizing what a shit-show these problems are. They have problems which are again coding/API design but modified to a company's use case.

Having given tons of interviews recently, one thing that stood out to me with a lot of the big companies is that even if you complete the code and run it but there is some bug(which could have been just a 1 line error or a matrix dimension mismatch for example), you get a prompt rejection. Solution correctness along with completing everything well under time is super important.

Pros of Leetcode -
- Standardized process, the interviewer or company doesn't have to come up with new questions.

Cons of Leetcode -
- Low correlation with on the job effectiveness.
- High False positives or False negatives

Pros of non-leetcode problems -
- High correlation with on the job effectiveness.

Cons of non-leetcode problems -
- Non-standardized. Grading rubric is a bit difficult to calibrate.
- Eng/Company have to actively come up with new interview problems.

[dhakkad_chora]

why would anyone want to join fanng except google after seeing all layoffs?

[mr.mystiks]

A lot of people disagreeing think Daniel is defending every interviewer in big tech. In reality, he’s just explaining cases where the magic list does not guarantee an offer. He’s also talking about how these interviews should be done, caring about process over outcome. Just because some interviewers care more about outcome over process, doesn’t mean Daniel is suddenly wrong. Gayle McDowell has mentioned everything Daniel said, and this isn’t really new.

[TheKrazyjet]

your title is a bit misleading. 99% of engineers *who apply to faang* never get into faang. thats a big population difference. ~20M developers and ~120K faang developers. people who get into software engineering nowadays are typically probably in it for the prestige and salary hence why faang is a buzz word. there probably isnt much of an overlap between being a good engineer and being an engineer at a faang company.

[shoooozzzz]

Formation: the tech interview prep site that costs a mere $2, 500 USD per month. Or it can be yours with a low interest rate loan at 27%.

[Keepedia]

Is this practically true? What percent of big tech hires actually did this, or could've done this? I have heard that in practice you don't hear back if you don't get the optimal solution. Would you agree

[nan]

Do you get brownie points even if you don’t solve the problem?

[resetengineering]

A question to the point where the mention is about the process and not about the answer. Doesn't Google expect a running code? I am sure most other companies do. While I agree with the ideal nature of the things said, not sure if it is applicable in real scenarios. I am from India and start-ups here too, don't operate this way.