Viber Software Engineer Interview: Questions & Prep (2026)

Viber, part of the Rakuten Group, is a messaging and calling platform with a large global user base (publicly reported). As of July 2026, Viber had 36 open Software Engineer roles tracked by knok's job radar, spanning mobile, backend, and infrastructure work. The interview process typically includes a recruiter or HR screen, one or two technical coding rounds, and a system-design or architecture discussion for mid-to-senior levels. Candidates report that the exact number of rounds and the format can vary by team, so it helps to confirm the structure with your recruiter after the first call.

Viber's engineering priorities center on real-time reliability: messages must arrive in order, calls must stay clear under poor network conditions, and the platform must handle traffic spikes without degrading. Interviewers test not just whether you can write correct code, but whether you naturally think about failure modes, latency, and the consequences of design decisions at scale.

These questions appear consistently in candidate reports and align closely with Viber's core technical domains.

1. How would you design a real-time messaging system that reliably delivers messages even when the recipient is offline?
2. Viber uses end-to-end encryption. How does your experience with secure communication protocols or cryptography apply here?
3. Walk me through how you would build a message-status feature (sent, delivered, read) that works at scale.
4. How do you handle race conditions in a concurrent, multi-user chat environment?
5. Tell me about a time you optimised an application for low latency. What did you measure, and what did you change?
6. How would you reduce battery consumption and data usage on a mobile messaging client?
7. Describe the most complex distributed system you have worked on and explain how you handled partial failures.
8. How would you design a push notification pipeline that works reliably across Android and iOS?
9. Viber supports voice and video calls. How would you debug a call quality issue affecting users in a specific region?
10. How do you ensure backward compatibility when updating a messaging protocol running across a large number of app versions?
11. What is your experience with WebSockets, long-polling, or other real-time transport mechanisms, and when would you choose one over another?
12. How would you architect a system to absorb a sudden spike in message volume during a major live event?

Q: How would you design a real-time messaging system that reliably delivers messages even when the recipient is offline?

*Situation:* At my previous company I was on the team building an internal communication tool used across offices in three cities.

*Task:* I owned the message delivery layer. It had to guarantee no message was lost, even if the recipient was offline or switched from Wi-Fi to mobile data mid-conversation.

*Action:* I designed a dual-path approach. Online users received messages over a persistent WebSocket connection with server-side acknowledgements. For offline recipients I wrote incoming messages to a durable queue and fired push notifications via FCM and APNs. On reconnect, the client used a cursor-based sync protocol so it only fetched messages it had not yet received. I added a server-side retry loop with exponential back-off for any unacknowledged messages.

*Result:* Internal monitoring showed reconnect syncs completed reliably even on slow connections, and the product team reported a clear drop in user complaints about missing messages. The delivery layer later served as the foundation for a group-calls feature launched the following quarter.

---

Q: Tell me about a time you optimised an application for low latency.

*Situation:* I worked on a data-feed service at a fintech startup that pushed real-time price updates to connected clients.

*Task:* Clients were reporting a visible lag between a market event and the price update on their screen, which was hurting trust in the product.

*Action:* I profiled the full path using flame graphs and found that most of the delay came from serialisation. The service used a verbose JSON format that was parsed and re-serialised at multiple hops. I migrated the hot path to Protocol Buffers, cutting payload size and parse time substantially. I also switched from a blocking thread-per-connection model to an event-loop architecture and pinned event-loop threads to specific CPU cores to reduce context switching.

*Result:* Observable latency on the hot path dropped to a level the sales team was comfortable demoing, and support complaints about lag fell to near zero within two months of the release.

---

Q: How do you ensure backward compatibility when updating a messaging protocol?

*Situation:* My team was shipping a protocol update to add reactions and polls to a chat product, with a large portion of users still on older app versions.

*Task:* A forced update was not an option because many users were in low-bandwidth regions with strict data limits.

*Action:* I introduced a version field in every message envelope so older clients could read the base fields and silently ignore unknown extensions. Each new message type included a 'downgrade fallback' field, a plain-text description that older clients would display if they could not render the rich type. I maintained a compatibility matrix in the internal wiki and ran a canary rollout while monitoring error rates on both old and new client versions before widening the release.

*Result:* The rollout completed with no forced-update requirement. Error rates on old clients stayed flat throughout, and the pattern became the team's standard approach for all subsequent protocol changes.

For behavioral questions, the STAR structure keeps answers focused and easy to follow. State the Situation briefly, name your specific Task, walk through your Actions in enough detail to show technical depth, and close with a concrete Result. Aim for three to four minutes per answer and resist the urge to over-explain context before getting to what you personally did.

For system-design questions, a consistent structure helps you cover the ground interviewers expect. Start by clarifying scope and scale (how many users, what latency targets). Sketch the high-level components before going deep on any one piece. Name trade-offs explicitly: 'I am choosing eventual consistency here because...' rather than leaving the interviewer to guess. Viber-specific design questions often reward candidates who proactively mention failure handling, reconnection logic, and protocol versioning, not just the happy path.

For coding questions, think aloud. State your brute-force approach first, estimate its complexity, then refine. Interviewers at communication-platform companies tend to test on graphs, trees, heaps, and sliding-window problems, all of which show up in routing, message queuing, and notification scheduling.

Viber interviewers typically look for a combination of technical depth and product instinct, because the engineers who thrive there understand why the constraints exist, not just how to code around them.

Ownership mindset. Candidates who describe their work with phrases like 'I designed...' or 'I decided...' rather than 'the team did...' stand out. Show that you drove decisions, not just implemented them.

Communication-scale intuition. You do not need to have worked on a messaging platform before, but you should naturally ask about reliability, ordering guarantees, and what happens when a service goes down. Interviewers flag candidates who jump to a solution without considering failure modes.

Clean, readable code. Viber's codebase spans mobile (Android and iOS) and backend services. Whatever language you use, interviewers look for clear naming, appropriate abstractions, and code that does not need a comment to explain what it does.

Comfort with ambiguity. System-design prompts at Viber are intentionally open-ended. Candidates who ask clarifying questions and state their assumptions score higher than those who pick one interpretation and barrel through it.

Practical security awareness. Given Viber's focus on end-to-end encryption, even backend and mobile candidates benefit from knowing the basics of key exchange and why encryption happens at the client rather than the server.

A focused plan over two to three weeks covers the most important ground for a Viber Software Engineer interview.

Week 1: Core data structures and algorithms. Practice problems on graphs, trees, heaps, and sliding-window patterns. These are the most commonly reported coding topics in Viber interviews. Work through problems until you can state the time and space complexity of your solution confidently.

Week 2: Real-time systems and distributed design. Study how WebSockets and long-polling work, how push notification pipelines are built, and how message queues such as Kafka or RabbitMQ provide durability. Review the CAP theorem as it applies to messaging: when is eventual consistency acceptable, and when is it not?

Week 3: Viber-specific domains. Review the basics of end-to-end encryption and the Signal protocol, which is publicly documented. If you are applying for a mobile role, brush up on Android or iOS power and data optimisation. Practice talking about your past projects using the STAR structure so your answers are crisp.

While you prepare, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so you can spend your preparation time on skills rather than on job hunting.

Jumping straight to a solution in system-design rounds. Candidates who start designing without clarifying scale, constraints, and user expectations often solve the wrong problem. Always spend a minute asking questions first.

Treating behavioral questions as formalities. Viber interviewers use behavioral rounds seriously. Thin or generic answers ('I worked in a team on a big project') are a red flag. Prepare specific stories with measurable outcomes.

Ignoring failure paths in designs. A design that covers only the happy path is incomplete. Interviewers expect you to discuss what happens when a service goes down, a message is not acknowledged, or a client reconnects after a long offline period.

Using jargon without explaining it. Saying 'we used eventual consistency' without explaining the trade-off signals that you may not fully understand the choice. Always explain the reasoning behind your decisions.

Not asking questions at the end. Viber interviews typically include time for your questions. Candidates who have nothing to ask signal low interest. Come prepared with questions about the team's current technical challenges or how they handle on-call incidents.