InMobi Data Engineer Interview: Questions & Prep (2026)

InMobi is one of India's best-known adtech companies, building mobile advertising and marketing technology products used by brands worldwide. With 91 Data Engineer roles currently open (as of July 2026 per knok jobradar), InMobi is actively scaling its data engineering team.

Data Engineers at InMobi typically work on high-throughput ad event ingestion, real-time bidding pipelines, campaign analytics, and ML feature engineering. The tech stack candidates report includes Apache Kafka, Spark or Flink, Hive, Presto or Trino, and cloud platforms (AWS or GCP).

The interview process candidates report typically spans a recruiter screen, one or two technical coding rounds (SQL and Python or Scala), a system design round, and a hiring manager or team discussion. Behavioral questions around ownership and cross-team collaboration appear in most rounds, so prepare strong examples alongside your technical prep.

These questions reflect patterns from publicly shared InMobi Data Engineer interview experiences. Treat them as a guide to the themes that come up most often, not as a guaranteed list.

1. Walk us through a data pipeline you designed end-to-end. What were the bottlenecks and how did you resolve them?
2. How would you design a real-time pipeline to compute click-through rates for each ad campaign at high scale?
3. Write a SQL query to find the top 5 publishers by total revenue, broken down by country, for a given date range.
4. How do you handle late-arriving events in a streaming pipeline using Apache Flink or Spark Streaming?
5. Explain the difference between a data lake and a data warehouse. When would you choose one over the other in an adtech context?
6. A Spark job is running slowly in production. Walk us through how you would debug and optimize it.
7. How would you design a data model to track user attribution across multiple ad touchpoints (click, view, install)?
8. Describe a time you caught a data quality issue before it reached a downstream team. How did you detect it and what did you do?
9. How do you ensure idempotency in a data pipeline? Give an example from your past work.
10. InMobi's ML team needs features computed from raw bid-stream events. How would you design a feature store to serve both batch and real-time needs?
11. How do you handle schema evolution when producers and consumers are on different release schedules?
12. What does your production pipeline monitoring look like, and what alerts would you set up?

Q: Walk us through a data pipeline you built end-to-end.

*Situation:* My team was ingesting clickstream data from a mobile app into our data warehouse, but the pipeline had no validation layer and downstream dashboards frequently showed incorrect numbers.

*Task:* I was asked to redesign the pipeline to add data quality checks and reduce dashboard errors to near zero.

*Action:* I introduced a Kafka-based ingestion layer with schema validation using Avro. I added a Great Expectations checkpoint that ran after each Spark batch job, flagging records with null user IDs or out-of-range timestamps. I set up alerts so any dataset failing the threshold check was blocked from promotion to the production schema, with a Slack notification to the team.

*Result:* Dashboard errors dropped significantly within the first sprint. The ML team, which depended on the same data, reported fewer retraining failures in the following cycle.

---

Q: Describe a time you caught a data quality issue before it reached a downstream team.

*Situation:* During a routine audit at my previous company, I noticed that event counts for one ad publisher spiked unusually overnight.

*Task:* I needed to quickly confirm whether this was genuine traffic or data corruption, and prevent downstream reports from being affected.

*Action:* I queried the raw Kafka topic against the processed Hive table and found that a backfill job had reprocessed several days of data without deduplication, creating duplicate event records. I added a dedup step using a composite key of event ID and timestamp, and coordinated with the analytics team to hold their weekly report until the corrected data propagated.

*Result:* The downstream report was delayed by a few hours but contained accurate numbers. I documented the incident and proposed an idempotency check as a standard pipeline gate, which the team adopted going forward.

---

Q: Tell me about a time you worked with an ML team to provide data for a new model.

*Situation:* An ML team at my company wanted to build a bid-price prediction model but had no clean feature set available from the event stream.

*Task:* I was responsible for designing and delivering a feature pipeline that could serve both offline training and near-real-time inference.

*Action:* I worked with the ML team to define the feature contract, then built a dual-path pipeline: a Spark batch job that computed aggregated features daily into an offline store (S3 with Hive), and a Flink streaming job that maintained a rolling window of the same features in Redis for low-latency serving. I versioned the feature definitions so the ML team could reproduce historical training sets.

*Result:* The model went into production and the ML team reported that feature freshness improved compared to their previous approach. The pipeline also served as a template for several subsequent ML projects.

For pipeline design questions: Start with the source (what data, what format, what volume). Then walk through ingestion, transformation, storage, and serving layers. Call out where you would add monitoring, error handling, and data quality checks. Interviewers want to see that you think about failure modes, not just the happy path.

For SQL questions: Read the question carefully before writing. State your assumptions (for example: 'I am assuming one row per impression'). Write a clean query with clear aliases, then explain how you would optimize it for large tables using partitioning, avoiding full scans, or adding appropriate indexes.

For system design questions: Use a four-step structure: clarify requirements, sketch the scale, design the components, discuss trade-offs. Walk through each layer verbally: source, broker (Kafka), processing (Spark or Flink), sink, and monitoring. For each choice, briefly explain why you picked it over the alternative. Aim to finish a coherent end-to-end design within the time your interviewer gives you, rather than going very deep on one layer.

For behavioral questions: Use the STAR format (Situation, Task, Action, Result). Keep the Situation brief, spend more time on Action, and make the Result concrete. If you lack a hard metric, describe the qualitative outcome clearly: 'the analytics team stopped filing tickets about that dataset' lands better than a vague claim.

Based on publicly shared interview feedback, InMobi's hiring team focuses on a few consistent themes.

Depth over breadth. They want to see that you genuinely understand the tools you claim to know. If you mention Kafka, expect follow-up questions on partitioning, consumer groups, or exactly-once semantics.

Scale awareness. Adtech pipelines handle very large event volumes. Interviewers want to hear you reason about partitioning strategies, data skew, backpressure handling, and cost trade-offs, not just functional correctness.

Ownership mindset. InMobi is known for a culture where engineers own their work end to end. Give examples where you monitored, debugged, and improved your own pipelines rather than handing problems off to an SRE or ops team.

Cross-functional communication. Data engineers at InMobi typically work closely with ML engineers, analysts, and product managers. Show that you can translate technical constraints into plain language for non-technical stakeholders.

Week 1: SQL and Python fundamentals. Revisit window functions (RANK, DENSE_RANK, LAG, LEAD), CTEs, and query optimization. Practice writing queries on ad-style schemas: impressions, clicks, conversions, publisher revenue. For Python, review pandas, PySpark DataFrame API, and writing unit tests for transformation logic.

Week 2: Distributed systems and streaming. Revise Kafka internals (partitions, offsets, consumer groups), Spark execution model (DAG, shuffle, caching), and Flink windowing (tumbling, sliding, session). Be ready to compare at least two tools for a given use case and explain your reasoning.

Week 3: System design. Practice designing end-to-end data pipelines on paper: a real-time campaign metrics system, a feature store, a data quality framework. Focus on clarifying requirements first, then sketching components, then discussing trade-offs.

Week 4: Behavioral prep and mock interviews. Write out a handful of stories using STAR for ownership, cross-team collaboration, and handling failures. Record yourself answering a design question and watch it back to catch filler words and unclear explanations. Do at least one full mock with a peer.

Going straight to code without clarifying requirements. In both SQL and design rounds, candidates who skip the 'clarify assumptions' step often solve the wrong problem. Ask one or two scoping questions before you write anything.

Naming tools without explaining the 'why'. Saying 'I would use Kafka' is not enough. Explain what property of Kafka makes it the right fit: durability, replayability, decoupling producers from consumers.

Ignoring failure modes. Interviewers notice when candidates design only the happy path. Mention what happens when a source goes down, when a Spark job fails mid-run, or when a schema change breaks a consumer.

Weak behavioral answers. Vague answers like 'my team improved performance' do not land well. Even without a hard number, describe a concrete outcome: 'the pipeline stopped failing every Monday morning' or 'the analyst team could run their reports without asking us to reprocess data'.

Over-engineering in a time-limited round. In system design, a clean simple architecture you can explain fully is better than an elaborate one you cannot defend. Get a working end-to-end sketch first, then add complexity if time allows.