Let Me Tell You About the Time I Interviewed at Facebook
A Shot in the Dark
Honestly? It started with me sending cold messages to strangers on LinkedIn and not expecting much back. I know how awkward that feels -- your finger hovers over "Send" and you think, "They're never going to reply to me." But here's the thing: they did. I heard back from recruiters at Amazon, Microsoft, Snapchat, Bloomberg, and Apple, all from messages I sent to people I'd never met. Then one day in August, an email I'd sent landed me a recruiter call from Facebook. I remember staring at my phone thinking, "Wait, really?"
If I could go back and tell myself one thing, it would be this: getting that first recruiter call is the hardest, most patience-testing part of the whole journey. Don't wait until you feel "ready" to start applying -- you'll never feel ready. Just start. And here's something most people don't realize: once a recruiter reaches out, you can ask for months of preparation time before scheduling your first interview. They're used to it. Take the time you need.
Gotta Nail It
So there I was, two weeks out from my technical screen, trying not to spiral. The format was straightforward enough: solve two questions in 45 minutes. The questions turned out to be fairly basic -- an array problem and a string problem -- but let me tell you, "basic" feels a lot less basic when someone is watching you code in real time.
One thing that saved me, and I mean genuinely saved me, was the test run. Here's what that means: your code isn't actually compiled and executed in the interview. Instead, the interviewer asks you to pick a test input and walk through your code line by line, showing how it would run. I know it sounds tedious, but it became my secret weapon. Running through a test case right after writing my solution let me catch the obvious mistakes myself -- missing an index, off-by-one errors, that kind of thing. It's so much better to find those yourself than to have the interviewer point them out with that polite-but-you-know-it's-bad smile.
For the second question, I came up with two different approaches and walked the interviewer through both. He asked me to compare them and analyse the advantages of one over the other -- which was actually a fun conversation once the initial nerves wore off. The last five minutes are reserved for you to ask the interviewer questions. I don't think this part factors into your evaluation, so just be genuine and curious.
Oh, and one resource I absolutely have to mention: Leetcode is well-known for interview prep, and it deserves the hype. But the real hidden gem is Leetcode Discuss. People share their actual interview experiences and questions there, and believe me -- questions do repeat. It felt like finding a cheat code, except it's completely legitimate.
Onsite Interview
Facebook moves fast -- and I mean that literally. I heard back from the recruiter within two days, and before I knew it, I was on a flight to London for the onsite. Four interviews in one day. I remember walking up to the building and thinking, "Okay, this is actually happening."
Facebook AR/VR division office. There are two more Facebook offices in London.
Coding interviews (x 2)
Each coding round had two questions to solve in 45-50 minutes. The topics ranged across binary trees, strings, stacks, and lists. The format is to discuss your approach with the interviewer first and then write your code on the whiteboard.
Here's the technique that carried me through: immediately after writing my solution on the board, I'd say, "Let me test-run this on a generic example and debug it before we go further." The interviewers always seemed to appreciate that. And it works -- the obvious mistakes jump out during that first walkthrough. A missing null check, a loop that goes one step too far. Finding those yourself gives you a quiet confidence, and it buys you thinking time to consider the edge cases you might have missed.
System Design Interview
This round was the one that intimidated me the most, and honestly, it turned out to be the most important one. For entry-level engineers, this is relatively new territory. The idea is to design a system from scratch. The problem statement usually looks something like:
- Design an existing product like WhatsApp, Facebook, Google search, etc.
- Design a particular feature of one of these applications; say, implement a timeline in a Facebook app.
- Design a completely hypothetical scenario; say, create a system to store logs of three servers situated far apart.
If you do nothing else to prepare for this round, go through Grokking the System Design Interview. Seriously. It was the single most useful resource I found for this kind of preparation.
The reassuring thing is that there are no "correct" answers. What matters is whether you can justify your design choices and clearly articulate the tradeoffs you've made. It's more like a conversation than an exam, once you get past the initial jitters.
Behavioral Interview
This one felt like a breather -- and I think that's by design. It's the easiest of the four rounds, but don't sleepwalk through it. Any red flags here can still cost you. The questions are about leadership, teamwork, handling disagreements -- the kind of stuff that's hard to fake but easy to prepare for because the question set is fairly predictable.
The night before my onsite, I went through a list of popular behavioral questions and thought about specific stories from my work that matched each one. Real stories, with details, not rehearsed corporate-speak. That preparation paid off -- I walked out of the behavioral round feeling genuinely good, and that confidence boost carried me into the remaining technical interviews.
What I Learned (The Hard Way)
Looking back, and after reading my feedback, two things stand out more than anything else:
The system design round was the decider. I cannot stress this enough. You need to present your ideas in a structured way -- don't just sketch boxes on a board and wave your hands. Think about database schema, protocol definitions, the details that show you've actually thought this through (the Grokking the System Design Interview course covers these systematically). Take the initiative and drive the conversation in a logical order: gather requirements, sketch the high-level design, then dig into the pros and cons. The important sections to practice are: gathering requirements, defining protocol, high-level design, database schema, data size estimation, component design, and tradeoffs.
Facebook expects you to be sharp on algorithms. They notice the small things -- traversing an array twice when once would do, a suboptimal data structure choice, a missed edge case. Do test runs, discuss edge cases, try to optimize, and write quickly on the whiteboard. I know that sounds like a lot, but here's the encouraging part: every question I got had a beautifully simple solution. Nothing felt impossibly clever. The hard part was getting there under pressure, not the solution itself.
The Google Story -- Starting From Scratch
Cracking Google Interview starting from scratch!
Okay, now let's talk about the big one. If you're reading this and thinking, "Sure, but I didn't go to IIT or Stanford, so Google would never look at me" -- I get it. I had the exact same insecurity. But I'm going to tell you something that I had to learn the hard way, and I hope it saves you some of that doubt:
Google values problem-solving abilities and attitude above everything else including your college.
That's not a feel-good platitude. That's what I experienced firsthand. Being honest with yourself about where you are and putting in sincere, consistent effort -- that's the only path that works. Google's software engineering interviews revolve heavily around data structures and algorithms, so let me walk you through exactly how I'd approach the preparation if I were starting over today.
I've broken this down into 4 stages. Jump to whichever one sounds like where you are right now -- no need to read from the beginning if you're already past the basics.
Stage 1 -- Finding Your Feet
This is for you if you haven't picked a programming language yet, or if you've just recently chosen one and everything still feels unfamiliar.
Pick any language -- C++, Java, Python, whatever calls to you. If you're truly starting from zero, I'd nudge you toward C++ because it forces you to understand what's happening under the hood. But honestly, the language matters less than you think. Once you're comfortable in one, picking up another later is surprisingly easy.
Once you've chosen, go through a language-specific training track on something like HackerRank's C++ challenges. Try to work through at least 70% of the problems -- that's roughly 30 or so. Don't rush through them; the goal is to feel at home in the language.
Then, start entering contests on platforms like Codeforces, CodeChef, or HackerEarth. On Codeforces, you'll begin in division 2 (div2). Participate in as many live and virtual contests as you can stomach. When you can reliably solve div2 A and B every time, and crack C occasionally, you're ready for the next stage.
Stage 2 -- The Grind That Changes Everything
You're here if you can comfortably solve div2 B and sometimes div2 C during a contest. This is where it starts to get interesting -- and humbling.
Start working through div2 C problems from past contests. Just the C problems. You'll run headfirst into topics like graphs, dynamic programming, and number theory -- concepts that might feel alien at first. That's normal. The strategy that worked for me: spend at least 15 minutes genuinely trying before looking at the solution. If after 15 minutes you don't even have a clue, read the editorial. Read it once, twice, three times until it clicks. Study the underlying algorithm. Then -- and this is the crucial part -- close the editorial and write the code yourself from scratch. No peeking.
Keep at this until you can consistently solve A, B, and C during live contests. It takes time. There will be weeks where it feels like you're not improving. You are. Trust the process.
Stage 3 -- Where Concepts Start Clicking Together
You're here if you can always solve div2 C and are starting to crack div2 D sometimes. By now, you're not just learning algorithms in isolation -- you're starting to see how they combine.
Apply the same approach from Stage 2, but now focus on div2 D problems. These are trickier -- they'll throw multiple concepts at you in a single problem, and the "aha moment" often comes from seeing a connection you wouldn't have noticed a few months ago. This stage is where preparation starts to feel less like studying and more like genuine problem-solving skill.
Stage 4 -- You're Ready (Yes, Really)
If you can consistently solve div2 C and nail div2 D at least 7 out of 10 times -- congratulations, and I mean that sincerely. You have a strong command of your language and solid algorithmic thinking. You should be entering Google's annual competitions like Kickstart and Code Jam. Perform well in those, and there's a very real chance a Google recruiter reaches out to you directly.
Once you're comfortable at Stage 3 or solidly in Stage 4, start applying through Google's career page or through referrals from friends who work there. Read interview experiences and past questions from interview preparation sites. You probably won't get the exact same questions, but you'll develop a feel for what they're looking for -- and that intuition is worth more than memorizing solutions.
One Last Thing
I want to be honest with you about something: I never expected switching jobs to be this difficult. Not just technically -- emotionally. There were days when I questioned whether I was good enough, whether I'd picked the wrong career, whether the whole thing was just a waste of time. If you're in that place right now, I want you to know I've been there too, and it's not a reflection of your ability. There's a real element of chance and luck in the interview process that nobody likes to talk about.
During those darker moments, I kept coming back to a Sanskrit verse from the Bhagavad Gita. It's not just a nice quote to put on a poster -- it genuinely kept me sane. It reminded me that the only thing I could control was the work itself, not the outcome. And somehow, letting go of the outcome made the work better.
рдХрд░реНрдордгреНрдпреЗрд╡рд╛рдзрд┐рдХрд╛рд░рд╕реНрддреЗ рдорд╛ рдлрд▓реЗрд╖реБ рдХрджрд╛рдЪрдиред
рдорд╛ рдХрд░реНрдордлрд▓рд╣реЗрддреБрд░реНрднреВрд░реНрдорд╛ рддреЗ рд╕рдЩреНрдЧреЛрд╜рд╕реНрддреНрд╡рдХрд░реНрдордгрд┐рее
You have the right to work only, but never to its fruits. Let not the fruits of
action be your motive, nor let your attachment be to inaction.
Do the work. Do it honestly and fully. And then let go. That's the best any of us can do.