Product Sense (10 minutes)
Try to keep your answers fairly brief. Prepare 4-6 main metrics and you don't need to explain in much detail why you picked each one, unless you feel the interviewer wants to hear more or they ask directly. Every interviewer's expectations are a little different, but overall I felt they don't dig in that deep, so don't spend too much time preparing for this part. The question types are roughly: define a success metric / a metric drops, find the root cause / what is the leading metric / what are the business questions for XXX? / what segments can you think of? Watching some product interview videos on YouTube should be enough.
Summary: the key point of this round is the success metrics. If you pick good success metrics, there's a good chance you'll be able to reuse them later in the data modeling round. After you finish writing out your metrics, ask the interviewer if there's any metric they wanted to see that you missed — at that point they'll usually give you some hints.
Data Modeling (15 minutes)
If you don't have much data modeling experience, I'd recommend reading chapters 1-3 of the Kimball data warehouse toolkit. This round is mainly about writing fact and dimension tables. Don't waste too much time writing a ton of columns and dimensions — leave more room for discussion. If you didn't waste too much time in the Product Sense round, you can write 4-5 dimension tables. The key point is that the fact table needs to make sense and be scalable. The question types are mainly: what if I want to track some changes to XXX? (immediately think SCD2) // what are the relationships between table A and table B — one-to-many or many-to-many? // how do you handle a many-to-many relationship?
Summary: the approaches always come down to adding a new column in the dim/fact table // adding a new dimension table (table normalization) // SCD2 // adding a new fact table. Try to use only one fact table, and keep asking the interviewer whether your direction is correct. When solving, try to come up with two or more approaches and their tradeoffs.
After you're done, check if there's time to optimize, then ask the interviewer whether it makes sense or not.
Summary: making sure you understand the question clearly matters more than syntax — but you should still write clean, well-formatted code.
Python (15 minutes)
This is the round where you're most likely to run out of time, so try to find as many different question types as possible and practice a lot. You can use ChatGPT to generate practice questions based on past interview reports, and aim to finish each one within 5 minutes. If you have time, ask one or two clarifying questions — pay attention to edge cases.
SQL (15 minutes)
This one's fairly easy — I barely prepared for it, since writing SQL regularly at work was enough. The key point is to try to write it as a single scan whenever possible — use GROUP BY when you can. CTEs often end up causing a second scan, so read the question carefully. I'd suggest quickly writing a draft first, then revisiting the question.
Discussion
Loading comments…