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

Classplus is an Indian ed-tech company that helps coaching institutes, tutors, and content creators run their entire business from a single app. From live classes and recorded videos to fee collection and student communication, the platform serves educators across Tier 1 and Tier 2 cities. As an iOS Engineer here, you build features that affect how lakhs of students and teachers interact with learning content every day.

As of July 2026, Classplus has 13 open roles on knok jobradar, with iOS Engineering being one of the active tracks. Candidates typically go through 3-4 rounds: an initial screening call, one or two technical rounds covering Swift internals and system design, and a final culture or hiring-manager conversation. The process can take a few weeks, though timelines vary.

Salaries for mid-senior iOS roles at ed-tech companies at this stage are commonly cited in the 18-35 LPA range on Glassdoor and levels.fyi, with figures depending on years of experience and negotiation.

These questions come up repeatedly in Classplus iOS rounds, based on what candidates report. Prepare concrete examples for each.

1. How does ARC (Automatic Reference Counting) work in Swift, and how do you avoid retain cycles?
2. Walk us through how you would architect an offline-first feature for a coaching app used in low-connectivity areas.
3. How would you design a live class streaming module for a mobile app? What components does your solution need?
4. Explain the difference between GCD (Grand Central Dispatch) and Operation queues. When do you reach for one over the other?
5. How do you handle push notifications for reminders, class updates, and assignment deadlines reliably?
6. UIKit vs SwiftUI: which would you pick for a new feature at Classplus and why? What are the trade-offs?
7. Describe how you have debugged a memory leak in a production iOS app. What tools did you use?
8. How would you implement video playback with a download-for-offline option? Walk through the key challenges.
9. Explain how you would handle deep linking and universal links in an app with a complex multi-tab navigation structure.
10. A scrolling feed with mixed content (video thumbnails, text, images) feels janky. How do you diagnose and fix the performance issues?
11. How would you integrate a payment gateway like Razorpay for in-app fee collection? What edge cases worry you most?
12. How do you write unit tests for a ViewModel in an MVVM architecture? Walk through a real example from your work.

Q: How did you debug a memory leak in a production iOS app?

*Situation:* At my previous company, we noticed that our video player screen was not being deallocated after users navigated away, causing memory to creep up over extended sessions.

*Task:* I was asked to find the root cause and fix it before the next release, as users on older iPhones were reporting crashes after long periods of use.

*Action:* I used Instruments (Leaks and Allocations tools) to confirm the object was staying alive. I found a closure inside our player delegate that was capturing 'self' strongly, creating a retain cycle between the ViewController and the AVPlayerLayer wrapper. I replaced the strong capture with '[weak self]' and added 'deinit' log statements to confirm deallocation during QA.

*Result:* Memory growth flattened in testing. Post-release, crash reports related to memory pressure dropped noticeably over the following weeks.

---

Q: How would you architect an offline-first feature for a low-connectivity region?

*Situation:* At a previous role, we had to build a homework submission flow for students in areas where connectivity drops frequently.

*Task:* I needed to design a solution that saved submissions locally when offline and synced them reliably once the network returned.

*Action:* I used Core Data to persist submission drafts locally with a sync-status flag. I wrote a background sync service using a URLSession background configuration so uploads could complete even if the app went to the background. I also added a conflict-resolution layer to handle cases where the server already had a newer version of the same submission.

*Result:* Failed submission complaints dropped significantly in user feedback, and our PM reported that engagement in Tier 2 cities improved in the quarter after launch.

---

Q: Walk me through how you write unit tests for a ViewModel.

*Situation:* Our codebase had minimal test coverage on business logic, and bugs in ViewModel state management were causing intermittent UI issues that were hard to reproduce.

*Task:* I took ownership of adding tests for the most critical ViewModels in our fee-payment flow.

*Action:* I introduced a protocol-based dependency injection pattern so the ViewModel could accept a mock API client. I wrote tests covering the happy path (successful fee payment), error states (network failure, invalid card), and edge cases (double-tap prevention). I used XCTest and a lightweight expectations helper for async calls.

*Result:* We caught two regression bugs during the next sprint that would have reached production. The pattern was adopted by the rest of the team for new ViewModels going forward.

For iOS technical questions, start with the 'why' before the 'how'. Interviewers want to see that you understand the problem, not just the API. For example, when asked about GCD vs Operation queues, first explain what problem concurrency solves, then describe the trade-offs.

For system design questions, use a simple structure: clarify requirements, define components, explain data flow, then discuss failure modes. For a live-class feature, walk through signalling (how clients connect), media delivery (HLS vs WebRTC), state management on the client, and what happens when the connection drops.

For behavioural questions, use STAR: Situation (one sentence of context), Task (what you specifically needed to do), Action (your concrete steps, not 'we'), Result (measurable or observable outcome). Keep Situation and Task short. Spend most of your time on Action and Result.

For trade-off questions (UIKit vs SwiftUI, MVVM vs MVC), give a direct answer first, then explain the context that would change your choice. Saying 'it depends' without a follow-up reads as evasive.

Classplus builds a product that needs to work across a wide range of devices, from flagship iPhones to older models used by students in smaller cities. Interviewers look for engineers who think about real-world constraints, not just ideal conditions.

Product empathy matters here. Candidates who connect their technical choices to user impact, for example saying 'I chose this approach because it reduces load time for users on 4G', consistently stand out based on what candidates report.

Depth over breadth. You do not need to know every Apple framework, but you should know your core areas (memory, concurrency, networking, UI performance) thoroughly. Expect follow-up questions that go two or three levels deep.

Ownership mindset. Classplus is a fast-moving startup. Interviewers tend to favour candidates who describe taking initiative: finding the bug no one else was looking at, proposing the architectural change, shipping the fix without being asked.

Communication. You will be asked to explain your thinking out loud, especially in design rounds. Practice talking through trade-offs step by step rather than jumping straight to a solution.

Week 1: Swift and iOS fundamentals
Revisit ARC, retain cycles, value vs reference types, and Swift concurrency (async/await, actors). Write small test programs to confirm your mental models. Review URLSession, Codable, and Core Data basics.

Week 2: Architecture and system design
Practice designing mobile features end-to-end: a video player, an offline sync system, a payment flow. For each, write out components, data flow, and failure modes on paper before checking any reference. Study MVVM and clean architecture patterns as they apply to iOS.

Week 3: Classplus-specific prep
Download and use the Classplus app as a student and as a tutor. Note the features you would be most excited to build or improve. Think about the technical challenges behind each screen. Prepare two or three stories from your past work that map to Classplus's domain (ed-tech, content delivery, payments, live features).

Week 4: Mock interviews and gaps
Do at least two mock technical interviews with a friend or on a practice platform. Record yourself answering behavioural questions and review for filler words and clarity. Fix any weak areas you discover.

As of July 2026, knok jobradar shows 70 iOS Engineer openings across India (Delhi leads with 21). If you want broader exposure while targeting Classplus, knok checks 150+ job sites nightly, applies to matching roles, and messages HR on your behalf.

Skipping the 'why'. Many candidates describe what they did without explaining why they made that choice. Interviewers at Classplus want to see reasoning, not just familiarity with APIs.

Saying 'we' instead of 'I' in STAR answers. When you say 'we fixed the memory leak', the interviewer cannot tell what you personally contributed. Always describe your specific role and actions.

Not knowing the Classplus product. Candidates who have never opened the app struggle to connect their technical skills to real problems. Spend time with the product before your rounds.

Over-engineering design answers. Jumping to a distributed architecture for a feature that will serve a small initial user base can seem out of touch with startup constraints. Start simple, then scale your design when the interviewer pushes you.

Leaving bugs unspoken. If you spot a flaw in your own solution while explaining it, say so. Interviewers value self-awareness. Silently hoping they do not notice rarely works.

Freezing on unknown questions. If you do not know something, say what you do know and reason from there. 'I have not used that API directly, but based on how URLSession handles background tasks, I would expect...' shows a stronger engineering mind than a blank pause.