Everyone who knows me knows I am currently working at Facebook as a Software Engineer. However, not everyone knows I failed the FB internship interview on my first attempt. My journey to become an engineer at a big tech company was a two-year bumpy ride.
Recently, I have been flooded with many Facebook messages asking about my process of getting an internship and a full-time offer from a big tech company. Questions like “Is it hard to land an internship at Facebook?”; “How long does it take you to find an internship?” “How did you apply?”, these questions don't have universal answers. This is because the answers highly depend on your efforts and your backgrounds. By sharing my story — a job hunting journey, I hope I can inspire you and offer you better insights into the big tech interview process.
Disclaimer: The following is not a step-by-step guide for cracking the interview because there exists no one-size-fits-all solution. I cannot ask everyone to attend the competitive programming contests like I did. Participating in hackathons or having 3 to 5 internships is also not compulsory. It might not be viable if you don't have a strong background in computer science or coding like your peers. Therefore, I am just going to share something I learnt through the interview preparation and from my interviews I have done. I hope you new graduates find these tips about how to crack interviews with tech companies helpful.
Let’s get started…
Before preparing for the interview, you should completely know what the interview process exactly looks like (by asking friends who applied for the same companies or googling) so I won’t go into details about this.
I am going to start with reaching out to recruiters. Before that, prepare your resume thoroughly. If you don’t currently have one, I recommend you google “Software Engineer Sample Resume template” today. At the end of my freshman year, I started building my resume by collecting resumes of people studying in Vietnam but still able to get big tech offers to find out what I need to improve. I made a check-list, asking “What I need to do?”. Then I started to perfect my resume month by month.
The next step is reaching out to recruiters in any way possible. I will list out three common ways graded from easy to difficult:
1. Ask for a referral: You can ask your friends or someone you know who is working at your dream company to refer. Referral is the most effective way to get to recruiters when you are applying for a job. Don’t just ask “Could you write a reference letter for me?” or “Can you refer me?”. Give them enough information about your background, the position you prefer, your resume, a short introduction, and even a cover letter.
2. Apply directly: Most of the companies detailed job description and positions on their websites. All you need is uploading your resume, your cover letter (sometimes) and some links to your personal projects or your blogs.
3. Waiting for a recruiter to reach out to you first: Is it truly wishful thinking? It is not. You completely can catch recruiters’ attention by enhancing your linkedin profile, owning an impressive github project or website, and participating in well-known contests such as Google Code Jam, Facebook Hackercup, Hackerrank, world wide Hackathon, etc.
Interview preparation
I read some articles such as “Solving 100 Leetcode problems to get to Google”, “Solving 200 or 500 Leetcode problems to crack a [company] interview”. I do not raise any objections against these notions because I always believe in Practice Makes Perfect. However, I just don’t recommend them. I know someone who had done no more than 100 leetcode problems but did not fail a single technical interview. To me, quality is more important than quantity!
Secondly, never ever ever learn solutions by heart. In my opinion, interviewers know everything they are asking. What they expect to see from you are your problem-solving skills, logical thinking, and coding skills. I failed the first Facebook internship interview. As I remember, I did so well and was so confident about my answer because I had encountered this problem before and known the solution. I was so surprised by the result — “Failed”. I will explain more in the Interview part.
Thirdly, you do not need to practice hard problems at all if you are still struggling with easy and medium ones. It’s better to understand the approaches you’re using and learn to come up with a solution by yourself in time instead of looking up answers and learning them by heart.
For people who have just started learning algorithms for upcoming interviews, I completely understand how difficult it is to solve a problem yourself. Instead of immediately jumping into all the problems frequently asked by the company you’re applying to, you should spend more time studying basic algorithms. You should practice at least 10 problems or any number of them until you are familiar with each basic algorithm. This certainly helps you easily come up with a solution by yourself for a whole new problem that contains patterns you have encountered before (this is the ‘intuition’ that everyone is talking about — the feeling that you know what data structures you should use and how you should approach the problem in the most reasonable way). Also, I advise you to gain better insights into time and space complexity of all algorithms and data structures. I know numerous people using built-in functions often (such as insert / remove a character in a string) without being aware of time complexity of these functions — O(n).
Besides Leetcode, you can use other websites to practice coding problems such as:
- Interview Bit (my favorite website for interview preparation).
- Pramp (which I used to do mock interviews every single day for 2 months before my actual interview).
- Hackerrank (in which coding challenges are created by startups and companies so this also may be a great source for you to prepare for technical interviews),
and a must-read book: Cracking the Coding Interview (in which you can find all basic algorithms potentially appearing in interviews).
Coding Interview
Interviewers definitely look out for these qualities:
1. Problem solving skills (the most important thing).
2. Coding skills.
3. Communication skills (Teamwork ability).
4. Ability to test your code.
Here are some common mistakes we often make during the coding interview.
1. Never clarify the question first:
Not all the questions are clear (it does not mean they ares confusing or tricky) so you should have these questions in your mind and also ask them out loud:
- Can the array be empty?
- Are there any negative numbers in the input array?
- Do I need to handle duplicates (or whitespace, or case-sensitive)?
Don’t assume anything. Asking questions also proves to your interviewer that you are a careful person. Furthermore, you can provide some additional test cases (input/output) to make sure your understanding is correct.
2. Start coding right away! ⚠️
Many candidates start coding as soon as they have a solution. That is a common mistake. Someone does not have much interaction with the interviewer about the codes he or she is about to write so you might come up with an inefficient solution. The underlying reasons are mainly that you might misunderstand the question or you devise a not-so-reasonable approach to the problem. Therefore, if you discuss with the interviewer and explain your thought process out loud, the interviewer can navigate you towards a much better route, especially when he or she notices that you are heading to an impending dead end.
In short, the correctness of your solution is not the main factor that decides whether you can get an offer or not but your problem solving skills and logical thinking abilities. Therefore, even if you are confident with your solution (because you have encountered it before), you should still communicate with the interviewer. This really helps you to show your teamwork ability.
3. Never analyze the time and space complexity
Complexity is the only “unit” we can use to compare algorithms. It is important not only for coding interviews but also for working in real projects. In the interview, when you can come up with two solutions, which one will you choose? Randomly? How do you know and even convince the interviewer which function is better than the other? Analyzing time and space complexity is a good way to do that. Sometimes you have to deal with two trade offs solutions: one is faster, and one uses less space. Analyze both time and space complexity. Interact with the interviewer to get which one they prefer. If you can do at least those two things, it’s awesome!
4. Never review your code with your own test cases:
Do not immediately end the coding interview if you still have time to check your code. One thing you can do is to create your own test cases. Don’t be afraid of encountering a bug in the last minute. From my perspective, it’s better for you to find your own bugs rather than let your interviewer do that.
I often list out all edge cases I can think of such as an empty string, an empty array, or an array filled with all negative numbers, and the list goes on. Just list out some test cases as such can reflect your carefulness as well.
5. Be afraid of asking for help
There is no problem asking for a hint. Do not be afraid to do that when you’re stuck. If the interviewer gives you a hint, take it and develop your idea based on it. Do not forget to discuss with your interviewer about what you are thinking about. Almost all interviewers are happy to help you. Sounds ridiculous? Nope. I always believe that “All companies, all interviewers, they interview to hire you, not to reject you”. This positive perspective boosted my confidence and relieved my tensions throughout interviews. Trust me, a positive attitude makes a huge difference.
The interview I like most is the Google one because 80% of the questions I was asked were new to me. I had to ask for hints. And of course, the interviewers helped me navigate the problems when I had questions. However, to my ultimate disbelief, I passed the interview with positive feedback.
6. Feel terrible when forgetting a syntax
It is natural even for the best programmers to forget a function or syntax they have been not using for a quite long time. However, you’d better choose a language that you mastered to minimize the syntax error in your code.
In an onsite interview with a Vietnamese tech company, I ran my code and got a syntax error. I had no idea what was going on so I asked the interviewer to google the syntax. He approved. And then I checked it on the internet and completed my code. Ultimately, I passed that interview.
In my second Facebook interview, I came up with an O(n) solution, though my interviewer asked me to think of an O(logn) solution. Extremely confused, I plucked up all of my courage to convince the interviewer there was no other way to solve this problem in O(logn). Surprisingly, he laughed and told me I misunderstood the question. We moved to the second question. However, I passed that one.
In an onsite Google interview, I came up with a silly solution using the KMP algorithm which I had not implemented for over 2 years. I honestly admitted that I forgot it and asked to leave the KMP function empty and finish it later. He was ok with that idea. I completed my main function and had 15 minutes left so I got back to the KMP function. However, I totally did not remember how to implement it. I hopelessly wrote something on the whiteboard to reprove that algorithm. He looked eager with the thing I was writing on the board. He asked me to code it. Although I knew it was not 100% correct, I was stunned by a positive result at the end of the interview.
Clearly, an interview is not as horrible as you thought, right? I have not been an interviewer yet so I can’t guarantee all of the things I mentioned hold true, but they are past lessons and experiences I gained after struggling with technical interviews for 2 years. Again, only one important thing you cannot forget is
“More important than the solution is
how you work at getting the solution.”
