pubmatic Data Scientist Interview: Questions, Experience & Prep (2026)

PubMatic is a programmatic advertising technology company running a supply-side platform (SSP) that connects publishers with advertisers through real-time bidding auctions. Data Scientists here build models for CTR prediction, bid-price optimization, ad fraud detection, audience segmentation, and publisher yield analytics. The environment is data-heavy, latency-sensitive, and closely tied to ad-tech business logic.

PubMatic currently has 62 open roles tracked by knok (as of July 2026). Across India, there are 937 active Data Scientist openings. Bangalore leads with 166 postings, followed by Delhi (46), Hyderabad (27), Pune (18), Mumbai (17), and Chennai (8).

Salary bands for Data Scientists in India, from knok jobradar:

The interview process typically involves multiple rounds. Candidates report stages covering statistics, machine learning depth, SQL and data wrangling, and business case discussions. Expect interviewers to push beyond textbook algorithms and connect your skills to real ad-tech problems.

1. How would you build a click-through rate (CTR) prediction model for display ads?
2. Explain how real-time bidding (RTB) works and where machine learning fits in the auction pipeline.
3. You notice a sudden drop in ad impressions for a publisher. Walk us through your diagnosis process.
4. How would you design an A/B test to evaluate a new bid-optimization algorithm?
5. Describe your approach to detecting fraudulent ad traffic using data.
6. How do you handle severe class imbalance in a fraud-detection model where fraudulent events are rare?
7. A publisher's fill rate drops week-over-week. What metrics do you look at, and what might explain the change?
8. How would you build a user segmentation model for audience targeting?
9. How do you measure the incremental lift of a new ad-targeting feature without a clean control group?
10. What is a second-price auction and what properties does it have from a game-theory perspective?
11. You need to optimize bid prices in real time with strict latency constraints. How do you approach model design?
12. How do you monitor a CTR model in production and decide when it needs retraining?

Q: How would you build a CTR prediction model for display ads?

*Situation:* At my previous company, we ran a display advertising network where the existing CTR model was a simple logistic regression trained on historical click logs.

*Task:* My task was to build a more accurate model that could handle sparse, high-dimensional ad data while remaining fast enough for real-time scoring.

*Action:* I audited the feature set first: ad creative attributes, user behavioural signals, publisher context, and time-of-day features. I used feature hashing to handle high-cardinality IDs (advertisers, publishers), then trained a LightGBM model calibrated with Platt scaling so predicted probabilities were reliable. I chose log loss as the primary offline metric alongside AUC, because calibration matters when the output feeds directly into a bid-price formula.

*Result:* The new model improved log loss in offline evaluation. In an online A/B test, we saw a measurable lift in click revenue. I documented the calibration approach so the team could maintain it independently after I rotated off the project.

---

Q: How do you handle severe class imbalance in a fraud-detection model?

*Situation:* I worked on an ad fraud detection project where fraudulent impressions made up a tiny fraction of total traffic.

*Task:* I needed a model that could catch fraud without generating so many false positives that it penalised legitimate publishers.

*Action:* I combined undersampling of the majority class with class-weight parameters in the model. I chose precision-recall AUC over ROC-AUC as the evaluation metric, since ROC-AUC can look healthy even when the model fails badly on the minority class. I set the classification threshold through a cost analysis, weighing the business cost of a missed fraud event against the cost of incorrectly flagging a legitimate publisher.

*Result:* The model caught a higher share of fraud at an acceptable false-positive rate. The precision-recall curve gave the operations team a clear lever to adjust the threshold based on their risk appetite, which meant the business owned the trade-off rather than it being buried inside a model hyperparameter.

---

Q: How would you design an A/B test to evaluate a new bidding algorithm?

*Situation:* Our team developed a new bid-price optimization algorithm and needed to compare it against the existing one in a live auction environment.

*Task:* I was responsible for making sure the experiment would be statistically valid and that results would be actionable for the product team.

*Action:* I randomized at the publisher-slot level to avoid spillover effects between the two groups. I defined eCPM (effective cost per thousand impressions) as the primary metric and calculated the minimum detectable effect size upfront, which set the required sample size and run duration. I also set guardrail metrics (fill rate, win rate) to catch unintended side effects, and monitored for novelty effects in the first few days of the experiment.

*Result:* The experiment ran for two full weeks to account for weekly seasonality in ad demand. The new algorithm showed a statistically significant improvement in eCPM, guardrail metrics stayed healthy, and we rolled out the algorithm fully with confidence.

For metrics and diagnosis questions: Use a funnel breakdown. Start at the top of the funnel (total ad requests), then move through each stage: bid rate, win rate, render rate, click rate. Identify at which stage the metric drops, then hypothesize causes (data pipeline issue, algorithm change, external demand shift, policy change on the buyer side).

For model design questions: Follow a 'problem to production' structure. Start with the business objective. Convert it to an ML task (classification, regression, ranking). Define offline and online metrics. Describe feature engineering. Explain training and validation strategy. Then discuss how you would monitor the model after deployment and decide when to retrain.

For statistics and probability questions: State your assumptions clearly before computing. PubMatic interviewers commonly test Bayesian reasoning, hypothesis testing, and probability distributions relevant to auction events. Walk through your logic step by step rather than jumping to a number. Showing your reasoning process matters as much as getting the right answer.

For business case questions: Anchor every answer on a metric the business cares about: revenue per publisher, fill rate, or eCPM. Show that you understand how a model output translates into a real business outcome, not just an improvement on an offline benchmark.

Candidates report that PubMatic interviewers look for a blend of technical depth and domain awareness. On the technical side, expect scrutiny on gradient boosting methods, model calibration for probabilistic outputs, proper experimental design, and handling imbalanced data. On the domain side, interviewers expect you to know how a programmatic auction works, what fill rate and win rate mean operationally, and why inference latency is a hard constraint in real-time bidding environments.

Business intuition is weighted heavily. If you can only talk about AUC and not about what a fill-rate improvement means for publisher revenue, that gap will show. Connect every modelling decision back to a business trade-off.

Communication clarity is also tested. Data Scientists at PubMatic typically present findings to non-technical stakeholders including sales, publisher relations, and product managers. Candidates who can explain a complex model result in plain terms tend to score better than those who go deep on maths but struggle to explain the business implication.

Week 1: Ad-tech fundamentals. Study how programmatic advertising works: SSPs, DSPs, ad exchanges, real-time bidding, and second-price auctions. Many free industry blogs and explainer articles cover these topics clearly. Be able to draw the full auction flow from ad request to impression and explain where ML sits at each step.

Week 2: Core ML topics. Revisit gradient boosting (XGBoost, LightGBM), model calibration, feature engineering for sparse high-cardinality data, and evaluation metrics beyond accuracy. Practice explaining the bias-variance tradeoff, regularization, and the difference between log loss and AUC without slipping into jargon.

Week 3: Statistics and experimentation. Review hypothesis testing, confidence intervals, and A/B test design including sample size calculation and choosing the right randomization unit. Work through problems involving class imbalance, the precision-recall tradeoff, and basic Bayesian reasoning applied to ad events.

Week 4: SQL and case practice. Practice window functions, aggregations, and joins on ad-style datasets (event logs, impression tables, click streams). Run through two or three product metric diagnosis cases using the funnel breakdown framework described in the answer frameworks section.

Final days: Prepare three to four STAR stories from your own experience. Aim for at least one story each covering model building, experimentation, and diagnosing a production issue. Do at least one mock interview out loud, not just in your head, so you hear how your answers actually sound.

Skipping domain context. Answering CTR prediction as a generic binary classification problem, without mentioning auction dynamics, feature sparsity, or calibration needs, signals that you have not prepared for ad-tech specifically. Interviewers notice this gap quickly.

Using accuracy as your go-to metric. With imbalanced classes (fraud, rare clicks), accuracy is misleading. Lead with log loss, precision-recall AUC, or F1 and explain why you chose it given the class distribution.

Over-engineering the model answer. Proposing a deep learning solution when LightGBM would suffice at PubMatic's scale and latency requirements is a red flag. Show that you understand practical serving constraints, not just offline benchmark performance.

Not defining success before diving into algorithms. Interviewers want to see you clarify the business objective and choose a metric before jumping to model selection. Skipping this step makes answers feel unfocused and shows a gap in product thinking.

Weak A/B test design. Saying 'I would run an A/B test' without discussing the randomization unit, primary metric, sample size, test duration, and guardrail metrics is not enough. Be specific about each design decision and the reasoning behind it, because experimentation rigour is central to the Data Scientist role at PubMatic.