Meta Data Scientist Interview Experience — SQL and Product Sense in a 45-Minute Screen

Giving back to the forum. I scheduled this interview in late March for early April.

The interviewer was very nice and patiently gave me hints — maybe a few too many hints, so I'm not sure how it'll turn out. I didn't hear anything within 24 hours, so I'm probably out, but I don't think I could have done any better. While it's still fresh in my memory, let me share it with everyone.

Round 1: Technical Screen, 45 min (Data Scientist, Product Analytics)

• 5 min: introductions
• 20 min: 2 SQL questions
• 20 min: several product questions
• 5 min: Q&A

The exact details might not be 100% accurate, so please bear with me.

SQL

Table 1:

• seller_id
• buyer_id
• product_id
• ds
• create_date
• li: number of interactions

Table 2:

• product_id
• country
• category: 'validate', ...

Q1: What's the number of products with more than 3 buyers and more than 10 interaction times?
Q2: What's the percentage of 'validate' interactions of US products in the past 7 days?

For Q1, I first explained my approach — listing products — and the interviewer reminded me it was asking for the number of products. After I corrected that, the interviewer pointed out it needed to be distinct buyers, not just buyers. Then the interviewer asked me to explain what HAVING means.

For Q2, I again explained my approach first — the logic was fine, and I used a LEFT JOIN. The interviewer hinted that a LEFT JOIN might not be the best choice, but I didn't catch what he meant and kept explaining what a LEFT JOIN is and why I used it. In the end, the interviewer said what he wanted was just a JOIN — an INNER JOIN is more efficient.

Product

Q1. Facebook has a marketing feature we want to extend to Instagram. The feature has not been launched yet. What do you think about convincing the PM about the necessity of the feature? The feature is like a button that can introduce more similar products to the buyers — that's roughly what it was.

I clarified that the goal was to improve user engagement, not revenue, and then said we could use click-through rate.

Q2. The interviewer hinted: just use the data from the SQL table — we haven't launched this product yet, so there's no CTR. How would you measure it?

I said based on the data in the table, and confirming we want to improve user engagement, not revenue: we can use the number of interactions per product / number per user. If it increases, the user can access similar products, and the button is necessary. We can use a model to analyze it, based on some threshold.

Q3. How would you build the model?

Using the above metric as the output, collect the necessary data: user characteristic data like age/country — briefly explaining that users in this group might have similar preferences and buy similar things; and user behavior data like duration on a product. Based on the sample size we can get, we could use a different ML model — if the sample size is too large, deep learning; if not, a basic decision tree or regression model — and use the model to predict buyer performance. If it's above some threshold, convince the PM to build it.

Q4. How do you decide whether to launch the product?

I clarified whether this meant designing an experiment. The interviewer said yes. So I said before the experiment, we need to confirm the metric and the randomization unit. The metric was mentioned earlier, or we could define a new one. For the randomization unit, since users might be influenced by their friends, we should rule out network effects here — I briefly explained why users might be influenced by friends, and briefly explained that clustering could be based on country or networks (close friends), and based on that clustering, randomize into control and treatment groups.

Q5. How do you define the control group and treatment group?

The control group has no change — it's the old version — and the treatment group uses the new button. Since we only have one feature to test, I recommended an A/B test; there's no need for a multi-variant test.

Q6. How do you finally decide whether to launch? What guardrail metrics come into play?

I said based on the significance level we set, if it's reached, we reject the null hypothesis and can launch. But we also need to consider other factors, like engineering team cost — recommending the button for more categories might mean more maintenance cost. Also, CTR isn't necessarily a good metric — if our goal is to make more money, users might click the button but not end up placing an order, and so on...