Viber Data Engineer Interview: Questions, Experience & Prep (2026)

Viber is a global messaging and calling platform, part of the Rakuten Group, with a large international user base. Their data engineering team handles real-time event ingestion, user engagement analytics, and the infrastructure that keeps pipelines running at messaging-app scale. Engineering decisions at Viber involve processing dense event streams from chat, calls, groups, and notification delivery across many device types.

As of July 2026, Viber has 36 open Data Engineer roles, a clear signal of active team growth. Candidates typically go through a multi-round process: a recruiter or HR call, a technical round covering SQL and Python, a system design or coding challenge focused on pipeline architecture, and a final discussion with a hiring manager or senior engineer. Viber's interviews lean toward real-time processing depth, data modelling for event-driven systems, and hands-on debugging scenarios.

Salary bands for Data Engineers in India (knok jobradar, July 2026):

Given the product complexity, Viber roles tend to suit mid and senior engineers, though entry-level openings do appear in the current listing.

Here are the questions candidates report seeing most often in Viber Data Engineer interviews:

1. Walk us through how you would design a real-time pipeline to process chat, call, and notification events at scale.
2. How do you handle late-arriving or out-of-order data in a streaming setup, and how do you reconcile it downstream?
3. Describe your hands-on experience with Apache Kafka. How did you manage consumer lag and partition rebalancing?
4. How would you design a schema for tracking user engagement on a messaging platform? What modelling approach would you choose and why?
5. You find out that a key business metric has been showing incorrect values for several days. Walk us through your response.
6. When do you choose batch processing over stream processing? Walk us through a real trade-off decision you made.
7. How do you build data quality checks into a continuously running pipeline with no planned downtime windows?
8. Tell us about a slow query you debugged and optimised on a large production table.
9. How would you design a system to detect sudden drops in message delivery rates or push notification success rates?
10. What is your experience with cloud data warehouses (BigQuery, Redshift, or Snowflake)? How did you balance cost and query performance?
11. How do you manage schema evolution when an upstream team changes their event format without advance notice?
12. How would you model notification engagement data across multiple delivery channels such as push, in-app, and SMS?

Q: Walk us through how you would design a real-time pipeline to process chat events at scale.

*Situation:* At a previous company, we ran a social platform where user activity events needed to power a live engagement dashboard used by the product team.

*Task:* I was responsible for building an end-to-end streaming pipeline that ingested raw events, applied transformations, and served aggregated metrics with low latency.

*Action:* I set up Kafka as the message broker, partitioned by user_id to preserve ordering within a user session. A Spark Structured Streaming job consumed from Kafka, applied watermark-based deduplication, and wrote to partitioned tables in our data lake. For the reporting layer, I materialized hourly rollups into a Redshift table that the BI tool could query directly. I also added a dead-letter queue for malformed events so they could be inspected and replayed without blocking the main pipeline.

*Result:* Latency dropped from multi-hour batch refresh cycles to near real time, and the product team could monitor feature rollouts as they happened instead of waiting for the next day's report.

---

Q: How do you handle late-arriving data in a streaming pipeline?

*Situation:* On a mobile analytics pipeline I owned, poor network conditions on user devices meant client events sometimes arrived well after their event timestamp.

*Task:* I needed accurate aggregated counts (daily active users, session counts) without reprocessing entire warehouse partitions every day.

*Action:* I implemented event-time windowing with a watermark tolerance in Spark Structured Streaming. Events within the grace window were folded into the correct time bucket. Events arriving beyond the threshold were written to a 'late arrivals' staging table. A nightly reconciliation job then patched the affected partitions in the warehouse. I added a monitoring alert to flag when the late-arrival rate crossed a baseline, so the team could catch drift before it affected reporting.

*Result:* Aggregate accuracy improved noticeably, the reconciliation job kept the warehouse consistent, and the team had clear visibility into data freshness quality, which also helped build trust with stakeholders who had previously doubted the numbers.

---

Q: Describe a time you debugged and optimised a slow query on a large production table.

*Situation:* A core reporting query on a user events table was timing out for the analytics team. The table held several years of history with no effective partitioning strategy.

*Task:* I needed to bring query response time within acceptable limits without a full table migration that would disrupt running jobs.

*Action:* I ran EXPLAIN ANALYZE to read the execution plan. A full table scan was the main bottleneck. I added partition pruning on the event_date column, rewrote all high-frequency queries to always include a date filter, and added a composite index on (user_id, event_type) for the most common join pattern. I backfilled the partition metadata during off-peak hours and coordinated with the analytics team to cut over their queries in stages.

*Result:* The query moved from timing out to returning results well within acceptable thresholds. Ad-hoc analysis became practical for the analytics team, and the change eliminated a category of oncall alerts that had been firing on a regular basis.

For system design questions: Walk through data flow in order: ingestion, transformation, storage, serving. State your assumptions first (event volume, latency requirements, consistency needs), then choose tools and justify each choice. Viber's core context is real-time messaging, so favour streaming-first architectures. Show that you think about failure modes: what happens when Kafka lags, when a consumer restarts mid-batch, or when an upstream schema changes without warning.

For SQL and coding questions: Think out loud before writing code. State your approach, mention edge cases (nulls, duplicates, skewed partition keys), and briefly note performance considerations such as indexes or partition pruning. Interviewers want to see your reasoning, not just a working query.

For the STAR framework (behavioural questions): Keep Situation and Task to one or two sentences each. Spend most of your answer on Action. Be explicit about what you personally did, not what the team did. Close with a Result that has a concrete outcome, even if qualitative: reliability improvement, analyst time saved, incident category eliminated. Vague endings like 'it worked out well' lose points.

For handling uncertainty: If you are unsure of a technical detail, say so and explain how you would investigate. Viber interviewers typically value intellectual honesty over confident wrong answers. Saying 'I would check the Kafka documentation on this specific behaviour' is better than guessing.

Real-time pipeline depth. Viber processes event streams from chat, calls, groups, and notifications at scale. Interviewers want concrete experience with streaming pipelines, not just familiarity with the concepts. Be ready to discuss failure modes, reprocessing strategies, and how you have operated pipelines in production, including how you handled incidents.

Data modelling for event-driven systems. Messaging platforms generate dense, complex event graphs. Interviewers look for an understanding of how to model this data for both analytical queries and real-time operational dashboards, and how those two use cases sometimes require different schemas or storage layers.

Ownership and reliability mindset. Candidates report that Viber interviewers frequently ask how you responded to production data incidents. They want engineers who treat data correctness as a personal responsibility, not just a QA task. Examples of proactive monitoring, self-initiated fixes, or post-incident documentation all land well.

Communication clarity. Data engineers at Viber work closely with product managers, analysts, and infrastructure teams. Interviewers look for candidates who can explain a technical trade-off (for example, why you chose a Lambda architecture over a Kappa architecture) in plain language that a product manager could follow.

Cloud and tooling fluency. Familiarity with at least one major cloud data warehouse and one orchestration tool (Airflow is commonly cited for roles at this type of company) is expected. Depth on one platform is valued more than surface knowledge of many.

A focused four-week plan:

Week 1: SQL and Python fundamentals
Practise window functions, CTEs, lateral joins, and query optimisation using EXPLAIN ANALYZE. Revisit Python data processing with PySpark or pandas. Aim for at least one SQL problem per day. Focus on queries that operate on event or log tables, which mirrors Viber's data context closely.

Week 2: Streaming and pipeline architecture
Review Kafka internals: partitions, consumer groups, offset management, and lag monitoring. Build or revisit a Spark Structured Streaming project. Understand watermarks, late data handling, and exactly-once delivery semantics. Read Kafka and Spark release notes from 2024-2026 to stay current on features interviewers may reference.

Week 3: System design practice
Practise designing a real-time analytics pipeline from scratch: ingestion (Kafka), transformation (Spark or Flink), storage (data lake plus warehouse), and serving layer. Study how messaging platforms handle event fan-out, notification delivery tracking, and user session modelling. Time your walkthroughs so you can finish a complete design discussion within a typical interview slot.

Week 4: Behavioural prep and company research
Prepare three to five STAR stories covering: a pipeline you designed end-to-end, a production incident you resolved, a cross-team disagreement you navigated, and a time you improved data quality proactively. Research Viber's public product updates and any available engineering content. Practice answering out loud, not just in your head.

For checking which of Viber's 36 open roles match your exact experience level, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you can put your energy into preparation rather than manual searching.

Jumping to tools before defining requirements. Many candidates open a system design answer with 'I would use Kafka and Spark' before stating constraints. Interviewers flag this consistently. Always start by clarifying event volume, latency requirements, and consistency expectations.

Under-preparing SQL. Candidates who work primarily with high-level frameworks or ORMs sometimes treat SQL as a formality. Viber's technical screens typically include hands-on SQL problems. Brush up on window functions and query execution plans before the interview.

Vague STAR answers. Saying 'we improved pipeline performance' without context weakens your story. Describe the impact qualitatively if precise numbers are not available: 'eliminated a category of oncall alerts', 'allowed the analyst team to run ad-hoc queries without workarounds'.

Skipping data quality in design answers. Many candidates design a pipeline for the happy path and leave out monitoring, alerting, schema validation, and dead-letter queues. Including these components shows production maturity and often separates mid-level from senior-level answers.

Not preparing questions to ask. Candidates who ask no questions at the end of rounds are remembered less positively. Prepare two or three genuine questions about the team's current data stack, a challenge they are actively solving, or how data quality ownership is shared across teams.