unacademy Software Engineer Interview: Questions, Experience & Prep (2026)

Unacademy is one of India's largest edtech platforms, helping millions of students prepare for UPSC, JEE, NEET, CAT, and other competitive exams. As of mid-2026, knok's job radar shows 24 open Software Engineer roles at Unacademy, making it an actively hiring destination in Indian edtech. Engineers here build live-class infrastructure, learner recommendation systems, content delivery pipelines, and engagement tools that handle large, concurrent audiences.

What the process looks like: Candidates typically go through an online coding assessment first, followed by one or two technical rounds focused on data structures and algorithms. Mid-level and senior candidates commonly face a system design round as well. A final conversation with a hiring manager or a senior leader covers team fit and past work. Candidates report the full process usually wraps up within two to three weeks once it begins.

Salary ranges for Software Engineers in India (from knok job data):

These are general Software Engineer ranges from knok's market data, not Unacademy-specific figures. For Unacademy-specific compensation, Glassdoor and levels.fyi have user-reported data that may give a closer picture.

Unacademy interviews lean on DSA fundamentals, system design at edtech scale, and past experience with high-traffic or data-heavy systems. Here are the questions candidates report most frequently:

1. Design a live video streaming system that supports a very large number of concurrent viewers for an Unacademy live class. How would you handle sudden traffic spikes during JEE or UPSC exam season?
2. How would you build a course recommendation engine that personalises suggestions for each student based on their learning history and exam goals?
3. Unacademy serves many students in Tier 2 and Tier 3 cities with limited bandwidth. How would you optimise video delivery for low-bandwidth connections?
4. Design a notification system that sends personalised reminders to millions of students about upcoming live classes, without overwhelming them.
5. Write a function to find the Kth largest element in an unsorted array. What is its time complexity, and when would you choose a different approach?
6. How would you design a real-time leaderboard for a test series platform where rankings update as students submit answers?
7. Describe a time you identified and resolved a performance bottleneck in a production system. What did you measure, and what did you change?
8. How would you build a search feature that lets students quickly find educators, topics, and courses across a very large catalogue?
9. Unacademy sees peak traffic during exam prep seasons. How would you ensure platform availability and low latency during those peaks?
10. Walk me through how you would design a database schema for a platform with educators, courses, live classes, and student subscriptions.
11. Tell me about a time you disagreed with a product or engineering decision. How did you handle the situation?
12. How would you monitor a newly deployed feature to catch problems early, before they reach a large number of users?

Q: Describe a time you identified and resolved a performance bottleneck in a production system.

*Situation:* At my previous company, our API serving course listing pages was responding very slowly during peak hours, causing users to abandon the page before it finished loading.

*Task:* I was responsible for diagnosing the slowdown and proposing a fix without taking the service offline.

*Action:* I added request-level tracing to isolate the slowest database queries. I found that a join across three large tables was running without an index on the foreign key used in the filter. I added a composite index, introduced a short-lived cache for the most-requested course combinations, and deployed the change behind a feature flag so I could monitor the impact live.

*Result:* Response time dropped significantly, and error rates on that endpoint fell in a way that was clearly visible in our internal dashboards. I documented the root cause so the team could apply the same approach to similar endpoints.

---

Q: Tell me about a time you disagreed with a product or engineering decision.

*Situation:* Our team was planning to build a custom video player from scratch to support a new interactive quiz feature inside live classes.

*Task:* I felt this was a high-risk path given our timeline, but I needed to make the case without dismissing the product team's reasoning.

*Action:* I put together a short comparison of build-vs-extend options, estimating effort and risk for each. I proposed extending an open-source player with a plugin layer for the quiz overlay instead of starting from scratch. I scheduled a short review with the product lead and engineering manager, walked through the trade-offs, and invited them to challenge my assumptions.

*Result:* The team agreed to try the plugin approach. We shipped the feature ahead of the original timeline, and the player code was simpler to maintain afterward. The product lead noted that the structured comparison made it easy to reach a decision.

---

Q: How would you build a search feature for a large course catalogue?

*Situation:* A product I worked on had grown to a very large catalogue of courses and educators, and the existing database-level text search was returning slow, irrelevant results.

*Task:* I was asked to lead the redesign of the search experience within one quarter.

*Action:* I evaluated a dedicated search engine against a managed search service, then chose the dedicated option for the control it gave us over relevance tuning. I indexed courses with fields for title, educator name, exam category, and language. I added a typo-tolerant analyser for Hindi and English terms, configured boosting so popular and recently updated courses ranked higher, and set up an A/B test to compare click-through rates between the old and new systems.

*Result:* Click-through on search results improved meaningfully according to our internal analytics, and search latency stayed within our target at the load levels we tested. The team continued to iterate on the relevance model after I handed it off.

Use STAR for every behavioural question. STAR stands for Situation, Task, Action, Result. Start with just enough context (one or two sentences), spend most of your answer on the specific actions you personally took, and close with a concrete result. Weak STAR answers say what the team did. Strong ones say what you decided, built, or changed.

For DSA questions, think aloud before you code. State your brute-force approach first, then reason toward a better solution. Interviewers at Unacademy want to see how you think, not just whether you know the answer. Confirm constraints (input size, edge cases, expected output format) before writing a single line of code.

For system design questions, use a structured flow. Clarify requirements and scale first, then define the core entities and data model, sketch the high-level components, and finally drill into the parts the interviewer finds most interesting. At Unacademy, interviewers commonly push on concurrency, caching, and traffic spike handling because the platform faces real seasonal peaks.

For technical opinion questions (build vs buy, SQL vs NoSQL, monolith vs microservices), lead with trade-offs rather than a single answer. Show that your recommendation depends on context: team size, data volume, expected scale, and time constraints.

Unacademy engineers have shared, in public forums and interview feedback threads, a few consistent themes about what interviewers look for.

Strong DSA fundamentals. Arrays, strings, trees, graphs, dynamic programming, and sorting are all fair game. You do not need to know exotic algorithms, but you should be fluent in the patterns that appear in standard interview preparation resources.

System design thinking for scale. Unacademy's products serve large, concurrent audiences. Interviewers want to see that you naturally think about caching, load distribution, database indexing, and graceful degradation. Edtech-specific scenarios (live class delivery, exam leaderboards, personalisation) appear often.

Ownership and initiative. Candidates who can point to specific problems they diagnosed and fixed, features they drove end-to-end, or decisions they made and defended tend to stand out. Like most product companies, Unacademy values engineers who move independently once they understand the goal.

Communication clarity. Whether explaining a system design or walking through code, interviewers want to follow your reasoning without effort. Thinking aloud, asking clarifying questions, and structuring your answers before diving in all signal communication maturity.

Mission alignment. Unacademy's products serve students, many from under-resourced backgrounds, preparing for life-changing exams. Candidates who connect their engineering choices to user impact (latency for a student on a slow connection, reliability during a high-stakes exam) tend to resonate with interviewers here.

Week 1: DSA foundation. Work through arrays, strings, linked lists, stacks, queues, and binary search. Solve at least two problems a day on a coding practice platform. Focus on understanding patterns, not memorising solutions.

Week 2: Trees, graphs, and dynamic programming. These are the categories Unacademy interviews test most, based on candidate reports. Practice BFS, DFS, shortest path problems, and common DP patterns like knapsack and longest common subsequence.

Week 3: System design. Study how to design systems like a video streaming platform, a notification service, a search engine, and a real-time leaderboard. Practice drawing diagrams and explaining them out loud. Read about how large edtech and streaming companies handle scale.

Week 4: Behavioural prep and mock interviews. Write out five to seven STAR stories covering ownership, disagreement, performance improvement, and cross-functional collaboration. Do at least two timed mock interviews with a peer or a practice platform. Review your code for edge cases and practise thinking aloud clearly.

Ongoing: Keep an eye on Unacademy's engineering blog and any public talks from their engineers to understand the problems the team is actively working on. This gives you natural material for the 'why Unacademy' conversation in your final round.

knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so you can spend your prep time on the interview itself rather than the job hunt.

Jumping straight into code. Many candidates start writing before clarifying the problem. Take two to three minutes to confirm the input format, edge cases, and expected output. Interviewers commonly note that solutions ignoring edge cases cost candidates even when the core logic is right.

Giving vague STAR answers. Saying 'we improved performance' without a specific action or result tells the interviewer nothing. Be precise about what you personally did and what changed as a result.

Designing systems without asking about context. Candidates who propose solutions without asking about scale, traffic patterns, or constraints miss the point of system design. At Unacademy, the edtech context (live classes, exam seasons, low-bandwidth users) matters. Ask before you design.

Ignoring the product context. Unacademy has a clear social mission. Candidates who talk only about technical elegance without connecting to student experience can come across as misaligned with the company's values. Show that you care about the user on the other side of the system.

Not testing your own code. After writing a solution, walk through it with a sample input and check boundary conditions. Candidates who catch their own bugs before the interviewer do better than those who wait to be corrected.

Treating 'any questions for us?' as optional. This part of the interview is also an evaluation. Ask about the team's current engineering challenges, how they handle on-call responsibilities, or how the team measures the impact of new features.