Pubmatic Software Engineer interview typically runs 4 rounds: HR screening, three technical rounds. The process takes about 2-4 weeks and is broad, mixing coding, design, and backend fundamentals.
$126K
Avg. Base Comp
$136K
Avg. Total Comp
4
Typical Rounds
2-4 weeks
Process Length
Our candidates report that PubMatic is less interested in a single specialty than in whether you can move cleanly across the stack. Across both experiences, the same pattern shows up: core Java and data structures are treated as baseline fluency, not a bonus. Even when the questions started with familiar DSA prompts, interviewers quickly pushed into implementation details, from DFS explanations to linked-list loops and array rotation, and they expected candidates to connect those answers to real backend work.
A recurring theme is that PubMatic wants engineers who can reason about tradeoffs, not just produce correct code. One candidate described an LRU cache discussion that went well beyond naming a hashmap and doubly linked list; another was asked to scale a project to a million users and to talk through Spring MVC, indexing, multithreading, and bean scope in the same conversation. That mix tells us the bar is built around practical engineering judgment: can you explain why a design works, where it breaks, and how it would behave under load?
We’ve also seen that project discussion is not filler here. Interviewers repeatedly used resume-based questions to probe whether candidates could tie their past work to architecture decisions, performance, and reliability. Even the more unexpected topics, like anomaly detection or GenAI, seemed to test whether someone could stay grounded and technical when the conversation widened. The candidates who did best were the ones who could switch gears without losing precision.
Synthetized from 2 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Pubmatic process.
The hardest part for me was realizing how broad the interview was going to be. PubMatic started with an HR screening call, which was pretty straightforward, and then moved into three technical rounds. The first technical round was mostly on linear data structure questions along with Java basics, so it felt more like a fundamentals check than a deep coding round. I was also asked to explain DFS on a graph, which came up in a way that tested whether I could talk through the traversal clearly rather than just recite the definition.
The second round shifted into low-level design, and that was where the interview became more interesting. I had to design an LRU cache, and the discussion went beyond just naming the data structures — they wanted to see how I would think about the implementation and tradeoffs. The third round was high-level design, and there was also a good amount of project discussion mixed in throughout the process. I was asked two LeetCode-style problems overall, so there was still an algorithms component, but the emphasis felt balanced between coding, design, and practical experience. The interviewers were engaged and the process felt smooth and well structured, but it was still rigorous enough that I can see why they filtered carefully. I didn’t get an offer in the end, so my main takeaway is to be ready for strong fundamentals in Java and data structures, plus both LLD and HLD discussions rather than focusing only on problem-solving.
Prep tip from this candidate
Be ready to explain DFS clearly on a graph and to design an LRU cache in detail, since those came up directly. Also review Java and Spring Boot basics alongside linear data structures, because the first round leaned heavily on fundamentals rather than advanced algorithms.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Pubmatic
Select the 2nd highest salary in the engineering department
| Question | |
|---|---|
| Empty Neighborhoods | |
| Top Three Salaries | |
| Merge Sorted Lists | |
| Subscription Overlap | |
| Comments Histogram | |
| Random SQL Sample | |
| String Shift | |
| Rolling Bank Transactions | |
| Customer Orders | |
| Employee Salaries | |
| Closest SAT Scores | |
| First Touch Attribution | |
| Raining in Seattle | |
| Prime to N | |
| Size of Joins | |
| Upsell Transactions | |
| Largest Salary by Department | |
| Monthly Customer Report | |
| Minimum Change | |
| P-value to a Layman | |
| Find Bigrams | |
| Last Transaction | |
| Scrambled Tickets | |
| Friendship Timeline | |
| Top 3 Users | |
| Google Maps Improvement | |
| Delivery Estimate Model | |
| Address Schema | |
| Download Facts |
Synthesized from candidate reports. Individual experiences may vary.
The process starts with a straightforward HR screening call to cover basic background, role fit, and logistics. This stage appears to be an initial filter before the technical rounds begin.
The first technical interview focuses on core data structures and Java fundamentals. Candidates were asked LeetCode-style problems such as rotating an array, detecting a linked-list loop, and explaining DFS, along with resume-based questions on Spring MVC, Java Streams, OOPS, and database indexing.
The second round goes deeper into backend engineering and practical Java/Spring knowledge. Topics included multithreading, race conditions, bean scope, singleton design pattern, B-trees and indexing, the diamond problem in Java, and another DSA-style problem such as tic-tac-toe winner detection.
The final round combines low-level design, high-level design, and project discussion. Candidates were asked to design systems like an LRU cache or Snake and Ladder, discuss scaling a system to a million users, and talk through their past projects and broader engineering topics.