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

Viber, part of the Rakuten Group, is a global messaging and VoIP platform used by a large international user base. As an iOS Engineer at Viber, you work on a high-traffic consumer app where real-time communication, low latency, and smooth performance are core product requirements. The role typically covers Swift and Objective-C development, APNS and PushKit integration, media handling for calls and chats, and maintaining a codebase that serves users across many iOS versions.

Viber's hiring process typically includes a recruiter screen, one or two technical rounds covering coding and system design, and a final conversation with the engineering team. Candidates report that interviewers focus on real-world messaging app problems rather than purely algorithmic puzzles, so your past product experience matters as much as textbook knowledge.

As of July 2026, knok's jobradar tracked 70 iOS Engineer openings across India, with Delhi leading at 21 roles and Bangalore at 6. Viber had 36 open positions across functions at that snapshot. The company does not publicly list salary bands for this role. Check Glassdoor and levels.fyi for current iOS Engineer compensation at messaging-focused companies to set your expectations before negotiating.

These questions come up frequently in Viber iOS Engineer interviews, based on what candidates typically report for consumer messaging apps at this level:

1. Walk us through the architecture of the most complex iOS feature you have built.
2. How do you handle real-time data (WebSockets or APNS push) in an iOS app without draining the battery?
3. Viber serves a very large concurrent user base. How do you write Swift code that stays performant under memory pressure?
4. How would you design an end-to-end encrypted messaging feature on iOS from scratch?
5. Describe your approach to unit testing and UI testing in a large, multi-developer Swift codebase.
6. Tell us about a time you debugged a hard crash in production. What tools and steps did you use?
7. How do you manage backward compatibility when you need to support older iOS versions alongside new API features?
8. Viber's codebase includes legacy Objective-C alongside modern Swift. How do you handle that interoperability in practice?
9. How would you optimise image and video loading in a chat feed with thousands of messages?
10. Walk us through your code review approach. What do you specifically look for beyond obvious bugs?
11. How do you handle offline mode and local data persistence in a messaging app?
12. Tell us about a technical disagreement with a teammate and how you resolved it.

Q: How do you handle real-time data in an iOS app without draining the battery?

*Situation:* At my previous company, we built a live activity feed that received updates every few seconds. Within the first week of launch, users reported that the app drained their battery very quickly.

*Task:* I was asked to investigate and reduce battery impact without removing the live-update feature.

*Action:* I profiled the app with Instruments and found we were holding a permanent WebSocket connection even when the app was backgrounded. I switched to a hybrid approach: APNS silent push notifications to wake the app only when there was actual new data, with a WebSocket that opened only when the user was actively viewing the feed. I also batched local UI updates using a debounce timer so we were not re-rendering on every single incoming message.

*Result:* Battery drain dropped noticeably in internal testing. App Store reviews mentioning battery improved in the following release cycle, and we did not lose any of the real-time feel for active users.

---

Q: Describe a time you debugged a hard crash in production.

*Situation:* Shortly after a release, we saw a spike in crash reports in Firebase Crashlytics. The crash was happening on a background thread accessing a shared cache, and it was not reproducible in our staging environment.

*Task:* I owned the investigation and had to ship a fix without reverting the entire release.

*Action:* I used the Crashlytics stack traces to narrow the crash to a race condition in our image cache. I enabled Thread Sanitizer on the debug build and reproduced it within an hour. The fix was wrapping the cache reads and writes in a serial dispatch queue rather than accessing the shared object from multiple threads.

*Result:* The crash rate dropped to near zero in the hotfix release that went out the next day. I also added a unit test specifically for concurrent cache access so the pattern would not regress.

---

Q: Tell us about a technical disagreement with a teammate and how you resolved it.

*Situation:* During a sprint, a colleague proposed using a third-party library for local database management. I felt our use case was simple enough that the library added unnecessary complexity and a larger binary size.

*Task:* We needed to reach a decision quickly because both approaches affected the feature timeline.

*Action:* I put together a short comparison covering build time impact, binary size difference, the API surface we actually needed, and the long-term maintenance risk of an external dependency. I shared it in our team channel and proposed a short call to go through it together rather than debating in comments.

*Result:* The team agreed to go with the lightweight native approach. The process also became a template for how we evaluated third-party dependencies going forward.

For system design and architecture questions, walk your answer through four layers: data storage (what you persist locally and why), networking (how data flows between device and server), the UI layer (how you structure ViewModels or Presenters), and error plus offline handling. Candidates report that Viber interviewers want to hear you think about user experience at each layer, not just the technical plumbing.

For behavioural questions, use the STAR structure: Situation (brief context), Task (what you were responsible for), Action (what you specifically did, not 'we'), Result (measurable or observable outcome). Keep Situation and Task short. Spend most of your time on Action and Result, since that is where your actual judgement shows.

For debugging questions, show a systematic process: reproduce the bug, isolate the module, use profiling tools (Instruments, Thread Sanitizer, Address Sanitizer), form a hypothesis, test it, and fix with a regression test. Naming specific Apple developer tools signals hands-on production experience.

For 'how do you approach X' questions (testing, code review, dependency management), lead with your principle, give a concrete example from past work, and close with what you would do differently or better next time. This shows both technical judgement and a growth mindset, which are two things candidates report Viber values highly.

Viber iOS Engineers work on an app where a bug or a slow frame rate affects real conversations for real people at scale. Interviewers are typically looking for a few specific signals:

Deep Swift knowledge, not just syntax. Can you explain memory management (ARC, weak and unowned references) without prompting? Do you understand Swift concurrency (async/await, actors) and when to use it versus GCD? Candidates report that surface-level answers here get probed hard.

Consumer app instincts. Have you thought about battery, bandwidth, and launch time as first-class constraints, not afterthoughts? Candidates who only mention feature delivery without mentioning performance tend to get pushed back in technical rounds.

Real-time and networking experience. Viber is fundamentally a communication product. Experience with WebSockets, APNS, or VoIP on iOS (CallKit, PushKit) is a strong differentiator. If you have it, bring it up early rather than waiting to be asked.

Collaborative and ownership-oriented mindset. Candidates report that Viber values engineers who own problems end to end, including monitoring after release and communicating proactively when something goes wrong.

Comfort with a mixed codebase. Being calm and practical about legacy Objective-C rather than dismissive of it signals maturity and real production experience.

Week 1: Core Swift and iOS internals
Revise memory management, Swift concurrency (async/await and actors), and UIKit versus SwiftUI tradeoffs. Practice explaining ARC and retain cycles out loud, not just on paper. Review how APNS, PushKit, and background modes work together on iOS, since these are central to what Viber ships.

Week 2: Real-time and networking
Build or revisit a small project that uses WebSockets (URLSessionWebSocketTask) and APNS. Understand how to handle reconnections, message queuing when offline, and the difference between foreground and background fetch strategies. This directly mirrors Viber's core product and will show up in your technical rounds.

Week 3: System design practice
Practice designing a simplified messaging app: local storage with Core Data or SQLite, a message sync protocol, media upload and caching, and end-to-end encryption concepts. You do not need to know every cryptography detail, but you should be able to explain the key exchange flow at a high level.

Week 4: Behavioural and mock interviews
Prepare 5-6 STAR stories covering: a hard bug you fixed, a performance problem you solved, a disagreement you navigated, a project you owned end to end, and a time you had to learn something quickly. Do at least one timed mock interview with a peer so you are not doing it for the first time in front of Viber.

While you prepare, knok checks 150+ job sites nightly, applies to iOS Engineer openings that match your resume, and messages HR for you, so your applications keep moving even during heavy prep weeks.

Skipping the 'why' in design answers. Saying 'I would use Core Data' without explaining why you chose it over SQLite or Realm tells the interviewer nothing about your judgement. Always give a reason tied to the specific constraints of the problem.

Being dismissive of legacy code. If you say 'I would just rewrite it all in Swift,' you signal that you have not worked in a real production environment. Show that you can work pragmatically with Objective-C while gradually migrating, because that is the actual job.

Treating battery and performance as optional. For a messaging app, these are core product requirements. Not mentioning them when designing a feature or debugging a problem is a noticeable gap that candidates report hurts their scores.

Giving vague STAR answers. 'We improved performance' is not a result. Aim for observable outcomes: crash rate dropped, the feature shipped on time, the team adopted the pattern. If you do not have hard numbers, describe what changed qualitatively and be specific about the before and after.

Not asking questions at the end. Candidates who ask nothing signal low interest. Prepare two or three genuine questions about the team's current technical challenges, their release process, or how they handle on-call for a live consumer app.