8 Tips to Consider when Preparing for FAANG & Other Competitive Interviews
I regularly interview candidates, and see brilliant folks failing for preventable reasons. I'm sure adopting at least one of these, will improve your interview performance and help you prepare for that daunting interview. It's a competitive job market and even a small edge can make a huge difference in outcomes, here you go:
1. Beware of Autopilot (muscle memory)
- The Curse of Familiarity: Encountering a coding problem you've coded up before can trigger your muscle memory. This is particularly dangerous if the real problem you're facing has subtle differences. By the time you realize (if you do), you've probably wasted so much time, and might not be able to recover.
- 💡Tip: Might seem counterintuitive, but in the days leading up to interviews, shift your focus from coding out full solutions to mental revision or mental coding. The idea here is to focus on being able to solve, and not having coded solutions fresh in your memory. Obviously, if you try to code mentally and struggle, then definitely try to code out the relevant chunk of code.
2. Have an Objective Measure of Your Interview-Readiness
- Beyond Problem Counting: Completing a high volume of problems doesn’t guarantee readiness. Real-world readiness requires the ability to perform under interview conditions.
- 💡Tip: Engage in realistic mock interviews, ideally with experienced interviewers who can provide a hire/no-hire decision. A good rule of thumb is, if you do 10 realistic (throw-away) interviews or mock interviews of the standard for the role you're aiming for, getting hire decisions in 8 out of 10 is a good signal. The advantage of doing these with experienced interviewers versus, say, your classmate is they are better able to factor in the quality of candidates and the hiring bar of the current job market in their hiring decision.
3. Don't Burn Out - Be efficient
- Preserve Mental Stamina: Grinding for 3-4 hours daily, especially with a full-time job, is cognitively draining, and you may not realize the decline until you burn out. You want to keep yourself fresh for the interview, especially if you'll be having back-to-back interviews.
- 💡Tip: Say you want to solve 100 problems prior to your interview, they'll have some things in common like declaration of function interfaces, for loops, if-else ladders, etc. Once you know how to do these, there isn't much value in coding them out a 100 times. If you have to code, focus on the crux of the problem. You can lay out skeleton code solutions with comments, mentally visualize what you intend to implement but offload to AI (e.g., GitHub Copilot) to implement your intent, so you can verify your solution. The usual things like taking regular breaks, getting enough sleep, eating & hydrating also apply.
4. Context Preload
This is slightly similar to the above but more relevant to companies that repeat questions e.g., Meta. The idea here is to ensure you build a mental model for the context of their problems e.g., the asteroid collision problem is a common Meta problem. Having to think about the different combinations of asteroid directions and what this means for the next state is time-consuming and tricky to do under pressure in an interview, especially if first time. If you're already familiar with this, on the interview day you can just focus on understanding the variation, figuring out a solution & implementing correctly.
5. Time Allocation by Phase
When faced with a coding challenge, you can break down your actions into categories:
- Algorizing (evaluating different approaches)
- Verifying correctness
- Implementing
- Fixing bugs
- Communicating with the interviewer
You should have a time-box for each of these e.g., for a challenge where you have 30 minutes, you can say 10 minutes for Algorizing and 5 minutes for the other phases. Make sure you practice working under these time constraints. This is just a baseline, to keep you on time, and of course, you can tweak; any time saved in one phase can be used in other phases. Usually, if you can come up with an optimal solution in 5 minutes or less, that's like 50% of the battle won.
6. One-Shot Mentality
When practicing, having 5+ submissions before having a solution that passes all test cases is suboptimal, and a painful way to learn. You need to form the habit of one-shot submission i.e., being confident that your solution is correct before hitting run/submit. You won't be able to do this when you're still in your learning phase, and your mentality should be more focused on learning rather than solving. If stuck for about 10 mins, or not confident, then treat the challenge as a learning exercise and plug the gaps. This technique is particularly important for companies that don't let you run your code (Jane Street, Meta etc)
7. Hungry Judge Effect
There's a well-known study that shows that judges are less harsh after they've had a meal, and the judges are not necessarily aware of this. An interviewer is essentially a judge, so it's probably a good idea to schedule interviews after lunchtime just in case. I'd say something like 2:30 pm is probably a good time slot.
8. Rescheduling
For highly competitive roles, such as those at FAANG, Quant firms where small mistakes are costly. If you feel unprepared, don't be afraid to reschedule. If you feel you have a 50% chance of passing, you're probably going to fail, better to reschedule, just make sure you give the recruiter advance notice.
For more ways to optimize your interview prep and performance, check out these resources:
- 10 Interview Tricky Scenarios that will throw you off, and how to handle them
- An optimal 4-stage approach to getting interview-ready
- This expands on some of the points above like Auto-pilot but in video form
- 10 Techniques to adopt in live interviews (this is focused on interviewing techniques)
P.S: There's this Discord community for interview-prep optimisation that you're welcome to join
Subscribe to my newsletter
Read articles from Coditioning directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by