Meta Data Scientist Interview Experience — 3 of 4 Onsite Rounds Done, Last Round Pushed Two Weeks

I finished 3 out of 4 rounds of my virtual onsite yesterday, so while it's still fresh in my memory, let me share the experience. The reason I only finished 3/4 is that right after the third round, the recruiter told me the final Technical session needed to be rescheduled — it ended up getting pushed two weeks out. Such a slow death (I originally wanted to get through the whole thing in one day, precisely because I wanted to die fast rather than suffer a long death).

Since I signed an NDA, I won't give exact details of the content, but I'll still share how I prepared and roughly what kind of questions I ran into:

Prep process:

1. I'd really recommend Jeff Su's videos, and I'll also share the behavioral prep advice from a friend of mine who's currently a director at a major retail company (she sent me a PDF I couldn't upload here, but the content is similar to an article on this topic). The key point: Your career story is not your career history. Actually, I made exactly this mistake a while back when I interviewed for a senior manager role at a large multinational HR company (so I bombed it). But that was my first final round ever, so I'll just count it as practice (nervous sweat).

2. Every session opens with a "short self introduction." So I'd recommend preparing a longer self-introduction (around 2-3 minutes) for the "tell me about yourself" question, and also a short version for icebreaking at the start of interviews. Either way, long or short, my structure was:

• Who I am right now: besides talking about what I'm currently doing, I'd also emphasize 2-3 things I'm good at. For example: leading cross-functioning teams, analyzing customer insights, being a firefighter for ad hoc requests from our VP and SVP whenever they have customer-oriented or purpose-driven questions.
• Who I was and why I became a DS (here I quickly connect my PhD experience to being a DS — besides showing my interdisciplinary background, it also explains why I became a DS)
• Who I want to be in the future

3. For Behavioral, I'd strongly recommend finding someone to mock interview you, especially someone who's a manager or has more senior experience. If you can't find anyone, you can pay a bit online for an interview coach or mock interview — I tried two: Prepfully and IGotAnOffer. Each has its pros and cons. Prepfully is more expensive, and when I did the mock with them I hadn't even finished reading the prep materials yet, plus I had zero confidence at the time, so my mock analytical execution round went terribly. But honestly, that experience woke me up a lot and changed the direction of my studying afterward — it really did help. As for IGotAnOffer, it's a bit cheaper. I picked two different people from big FAANG companies as interview coaches. The first one told me upfront that his DS background leans toward software engineering, so he didn't think he could give me good technical interview advice, but he was a big help on the behavioral side. The second one happened to be a senior DSA employee at Meta — he reviewed my phone-screen responses and also gave me advice on my analytical reasoning process, and finished with a 10-15 minute mock. I think that part helped a lot.

4. ChatGPT is a good friend, but it's not a magic tool: when reviewing some of my behavioral answers, I did use ChatGPT to polish them, but the actual interview is a very different situation. ChatGPT and other AI tools are just aids — the important thing is to internalize the kinds of situations you might face in a behavioral interview and make them truly your own. Also, don't make up stories — in the real interview, the interviewer is very likely to keep digging into your answer, peeling back layer after layer (I'll give an example later).

5. Stories to prepare for Behavioral (these are all necessary if you're interviewing for L5 or above):

• Any work challenge you've ever faced, and how you eventually resolved it
• Any accomplishment at work (big or small), and the impact it ultimately had on people around you
• Any conflict you've ever had to handle

6. Analytical Execution & Analytical Reasoning: I really recommend Emma Ding's videos, she organizes things really well. Embarrassing to admit, I have an MS in Statistics (picked up along the way during my PhD) with a 3.9 GPA, but I'd basically forgotten almost everything after graduating (seriously), and honestly I've been bad at combinatorics since high school (I hate that chapter), and every time I hit a probability question I basically just surrender (this is true). This time I spent two weeks hard at work rehabbing my brain, and looked up a bunch of Bayes' Theorem and Binomial Probability practice problems online. Of course I also reviewed a lot of the required knowledge from a Statistics master's program. Honestly, no matter how the interview turns out, this whole process was still really helpful for my future (because for the first time in my life I actually understood what combinatorics is for, lol).

Bayes' Theorem and the Binomial Distribution are important, because a lot of the design in social media or e-commerce is just click-or-not-click (Binomial), and then when they test probability they often layer Bayes' Theorem on top as a combo move. If it's a dice question, that's uniform distribution — also not hard, as long as you've got the fundamentals down, you won't panic on a variation of the question.

7. The following two videos are ones the senior Meta DSA I paid as an interview coach recommended to me — personally I think they helped a lot. When it comes to framing "how to measure success," I think this is a framework that works for both data and product-oriented roles. There's also a good example out there of Facebook Marketplace Metrics.

Behavior Session:

Mainly focused on a few scenarios: (1) Have you ever seen a coworker around you feel "not welcome" — how did you resolve it? (2) What's something you pushed yourself to learn quickly in a short time? (3) How do you handle it when you run into conflict?

The first type of question was pretty fresh to me, but I think it's a great question. The interviewer also worked hard to "dig into" the details — he wanted to know how I handled both sides of the situation (Group A disliked B, and B felt unwelcomed by Group A). The interviewer asked very, very detailed follow-ups... all I can say is "good thing I actually dealt with something like this before?" (nervous sweat)

Analytical Execution:

The famous fake account question. Honestly, the descriptions I'd found online beforehand were all fragmented, so before I ran into it myself I never really knew "what the question actually looks like" (nervous sweat) — of course that's partly on me for not searching thoroughly enough! I'm the type of lazy person whose heart gives out by page two of search results...

But from looking at how the virtual onsite process went for people who passed or failed, it seems like everyone basically runs into 4-5 questions. So if you also get fake account and manage to get through 4-5 questions in the time given, that probably counts as passing (?)

My interviewer started with the scenario, asking how you'd determine a fake account — we discussed that for about five minutes, and I'm not sure if it satisfied him, but anyway, then we moved into the actual calculation process.

The calculation is closely tied together: they tell you the ratio of fake to authentic accounts, then give you a scenario. The first probability question matters a lot, because you use its answer later for the following calculations. I actually got stuck on the first question for a bit because I overcomplicated it in my head — stuck for maybe 30-60 seconds — but once I figured it out, everything after went smoothly. The first question was actually just simple P = a / (a+b): once you write out the algebra, you can cancel terms and get that probability p, and it has nothing to do with binomial or Bayes' at all.

The second question was related to Binomial. I calculated it a bit fast at first, so the interviewer asked how I got that number, so I spent another 30 seconds expanding out the equation and explaining why I did it that way.

As I recall, only the last question used Bayes' Theorem. Honestly the numbers I got this time were all really clean — for a few questions I didn't even need a calculator. On the last question, to double-check I hadn't misunderstood the question, I proactively used the terms "false positive" and "false negative" to confirm a couple of the numbers (mainly because the numbers were so clean, I wanted to make sure I hadn't misread the question). The interviewer's reaction looked pretty positive, so I think in some way that also confirmed to him that I understood Type I error & Type II error?

Same as the Behavioral round, we left a few minutes at the end to chat with the interviewer, hoping the minute I got stuck on wouldn't be a death sentence QAQ

Analytical Reasoning:

For some reason I have a feeling (some mysterious sixth sense?) that this round is really the main event that decides whether you pass or not.

The interviewer for this round didn't look at the whiteboard at all — he actively listened, discussed, and typed notes at the same time, but he told me "you really don't need to use the whiteboard, because I'm not going to look at it anyway" lol

So this whole round was just me talking to him directly while looking at the screen. I got the (famous?) feature recommendation question. Here's roughly what was asked (all pretty high level, but I could tell the interviewer wanted me to discuss it from a very top-down, cover-everything perspective):

If you were designing a feature today (basically a new product), how would you convince your boss?

• First is mission: what is our mission? Grow users? Grow revenue? Or both?
• Once the mission is settled, discuss whether it's even worth developing a new feature/product on top of the existing product. If so, how do you explain it using both external and internal reasons?
• Externally, overall, is there actually a market opportunity here? Are there similar products? Who are the competitors? Why should we go carve out a piece of that market?
• Internally, what advantages do we gain by adding this feature? What can it add?

That's roughly the angle I discussed it from.

If your boss is convinced, what data would you consider as the basis for your analysis?

• Assuming you're adding the feature within Facebook or Instagram itself, what factors do you consider? Things like posts? What kinds of newsfeed clicks? Lifestyle (places they've traveled, etc.)
• Assuming you're developing on Facebook, besides Facebook's own data, you can also think about whether you can pull data from "sibling" apps under the same parent company, like Instagram, Threads, etc. Usually under the same parent company, certain data can be shared between subsidiaries.
• Is there any other third-party data you could use? Some companies pay to buy third-party data — I'd factor that in too.

If you want to measure this, what would you measure?

• You need to clearly define what your north star metric (NSM) is, and what your counter metrics (CM) are.
• For example: your NSM might be traffic, and the CM could be conversion rate, because higher traffic doesn't necessarily mean conversion rate goes up too.
• Conversion rate can also be broken into many layers depending on different types of engagement — some can be test vs. control, some only exist in the test group — and you need to be clear about why you're monitoring these.

Probably because I talk too much (?), I brought up something maybe fewer people discuss: potential revenue. I said this isn't an NSM or a CM, but it would be a metric to track. Assuming our goal today is monetizing traffic or CTR, then estimating potential revenue matters a lot. If a click generates $0.5 in revenue, then ultimately, based on the experiment, we can estimate total potential revenue.

Honestly, I only brought this up because of my own hands-on experience. The interviewer's face lit up at that point, but I can't say for sure whether that "lighting up" was (a) "I like your answer" or (b) "this rookie is overthinking it, we don't need this." If it's (a), great. If it's (b)... learn from my mistake, everyone QAQ

If you needed to run an experiment today, how would you do it? (Since this feature had never launched before, this was the standard A/B test question.)

• First is selecting the experiment location. Whenever I answered, I kept emphasizing "assume we are going to XXXXX" — I think that assumption is pretty important, since different situations call for different decisions.
• Based on my own experience, I'd pick a city or metro area to start with (if you have enough budget you can obviously pick multiple locations), and that city or metro area should ideally be (1) large enough in population, (2) representative — its demographic distribution should reflect the median of the company's product users across dimensions, or be close to the population distribution of the company's core user base. If the city or metro area you pick represents "the population distribution of that whole country" that also works, it just produces a different kind of result — closer to "how people in that country react to our new product" rather than "how our company's current users react to the new product." (3) Test/control stratification (the interviewer asked very detailed questions here, so I ended up explaining how to build the stratification system, how to score, how to bucket into deciles, and then how to split into test/control after that).

Judging by his expression, I think he was satisfied with my answer on this part? (Of course if he has a poker face, that's harder to tell QAQ)

A bit more I added:

After I finished, I don't remember exactly why, but I added something about the final measurement and decision-making after the experiment. I (probably talking too much again) told the interviewer: even if the final experiment results are really good, that doesn't necessarily mean we should launch. In my report to my boss, I'd also factor in cost considerations — technical feasibility, human resources, etc. — because launching a whole new product globally might require a lot of investment: besides hardware, there's software staffing too — do we have enough engineers to build it, do we need to hire more, how much headcount does ongoing maintenance need afterward. All of that is a consideration. Whether it pays off in the short term or only in the long term — I'd write all of that into the report too (and honestly, if I were reporting to a VP or SVP, I really would list these as considerations).

After I said that, the interviewer looked happy, but again... I have no idea if that's a good thing or if I was just talking too much.

Then we had 3-5 minutes of chat time at the end — we actually ended up going 7 minutes over, hopefully that's a good sign.

Technical Session:

Because the originally scheduled interviewer wasn't available, it got moved to two weeks later QAQ. This is the round I should feel most confident about, but now it feels more like a slow torture waiting for it.