unacademy Data Analyst Interview: Questions, Experience & Prep (2026)

Unacademy is one of India's largest edtech platforms, and its Data Analyst team sits at the heart of product, growth, and learning decisions. As of mid-2026, Unacademy has 24 open Data Analyst roles, making it one of the more active hirers in the edtech space right now.

Candidates report a process that typically runs 3-4 rounds: a screening call with HR, a take-home or live SQL assignment, a technical panel discussion, and a final business or hiring-manager round. Round names and order can vary, so treat this as a general shape rather than a fixed sequence.

The role is deeply cross-functional. Analysts here support product managers, marketing teams, and content teams, so interviews test both technical depth and the ability to translate numbers into plain business language that non-technical stakeholders can act on.

SQL and data manipulation

1. Write a query to find the top 5 instructors by total watch-time in the last 30 days.
2. How would you identify students who are at risk of churning before their subscription expires?
3. Given a sessions table and a users table, write a query to calculate the 7-day retention rate.
4. How do you handle duplicate records in a raw event log before analysis?

Product and business sense

1. Unacademy runs live classes and recorded content. How would you measure which format drives better learning outcomes?
2. If daily active users dropped sharply week-on-week, how would you investigate the cause?
3. How would you design a dashboard to track the health of a new course launch?
4. What metric would you use to decide whether to expand a subject category to a new regional language?

Statistics and experimentation

1. An A/B test shows a new onboarding flow improves Day-1 completion and the p-value is below 0.05. Would you ship it? What else would you check?
2. What is the difference between correlation and causation? Give an example from the edtech context.
3. How would you set up an experiment to test whether push notifications improve weekly study hours?

Behavioural

1. Tell me about a time your analysis changed a decision the team had already made.

Q: Tell me about a time your analysis changed a decision the team had already made.

*Situation:* My team had decided to double the frequency of promotional emails to inactive users, expecting it to reactivate a meaningful share of the base.

*Task:* I was asked to build a report tracking the campaign's first two weeks, but I noticed something unexpected in the data early on.

*Action:* I segmented the inactive users by how long they had been inactive. Users who had been inactive for over three months were unsubscribing at a much higher rate than those inactive for one to two months. I put together a short memo showing the unsubscribe trend and the projected net list loss if we continued at full frequency, and shared it with the marketing lead before the next send.

*Result:* The team paused the campaign for long-inactive users and ran a lighter 'win-back' sequence instead. Unsubscribes dropped noticeably in that segment, and the team now segments by inactivity window before any bulk send.

---

Q: If daily active users dropped sharply week-on-week, how would you investigate the cause?

*Situation:* This is a common scenario in edtech, where usage is tied to academic calendars, exam seasons, and app updates.

*Task:* The goal is to isolate whether the drop is a data issue, a product issue, or an external factor, quickly enough to act.

*Action:* I would start by checking data pipeline health to rule out a logging failure. Then I would break down the metric by platform (Android, iOS, web), by user cohort (new vs. returning), and by geography. I would also check whether any app update or feature change shipped that week, and look at external factors like a national holiday or an exam schedule shift.

*Result:* This structured breakdown typically narrows the cause to one or two hypotheses within a few hours, which is fast enough to brief stakeholders before they escalate.

---

Q: How would you design a dashboard to track the health of a new course launch?

*Situation:* At a previous role, we launched a new subject vertical and had no standard way to track whether it was gaining traction.

*Task:* I was asked to define the metrics and build a live dashboard the product and content teams could use in the first two months.

*Action:* I identified three layers of metrics: acquisition (enrollments, cost per enrollment if paid), engagement (average watch-time per enrolled user, completion rate by lesson), and outcome (assessment scores, repeat-visit rate). I built the dashboard in a BI tool and set up weekly automated summaries so stakeholders did not need to log in daily.

*Result:* The content team used the lesson-level completion data to re-sequence two early lessons that had high drop-off. Completion rates for those lessons improved noticeably in the following two weeks.

For SQL questions: Restate the business question in plain English before writing code. Mention edge cases you are handling, such as nulls, duplicates, or timezone differences. If you are unsure of exact syntax, say so and describe your logic in words first.

For metric-drop or investigation questions: Use a top-down drill-down structure. Start with data integrity, then segment by platform, user type, and geography, then check for product or external changes. Interviewers want to see that you do not jump to conclusions.

For experiment and A/B test questions: Cover four things: the hypothesis, the randomisation unit, the primary metric and guardrail metrics, and the minimum sample size or run time. Mentioning guardrail metrics (things you do not want to accidentally harm) signals maturity.

For behavioural questions: Use the STAR format (Situation, Task, Action, Result) and keep Situation and Task brief. Spend most of your time on Action (what you specifically did) and Result (what changed because of it). Quantify results where you honestly can.

For product-sense questions: Anchor your answer to the user and the business goal before suggesting metrics. Unacademy interviewers typically value answers that show awareness of the edtech user journey: acquisition, activation, engagement, and retention.

Candidates who have spoken with Unacademy interviewers typically report that the panel is looking for a few things above all.

SQL fluency in practice, not just theory. Questions are often set in an edtech context, so practising on tables that resemble sessions, enrollments, instructors, and content is more useful than generic practice problems.

Business language. Unacademy analysts present findings to non-technical stakeholders regularly. Interviewers want to see that you can move from a query result to a clear recommendation, not just describe what the numbers say.

Intellectual honesty. If a result is ambiguous, say so. If you do not know something, say so and explain how you would find out. Interviewers at product-led companies tend to flag candidates who over-claim or ignore confounding factors.

Ownership mindset. Edtech companies move fast. Candidates who frame past work as 'I ran this analysis' tend to score lower than those who say 'I noticed this problem, ran the analysis, and followed up until the team acted on it.'

Week 1: SQL and Python fundamentals

Practise window functions, CTEs, and aggregations on edtech-style datasets. Write queries against tables like user_sessions, course_enrollments, and instructor_content. If you use Python, practise pandas groupby, merge, and pivot operations on similar data shapes.

Week 2: Product and metrics thinking

Pick three Unacademy features (live classes, test series, daily goals) and define the north-star metric and two supporting metrics for each. Practise the metric-drop drill: pick a metric, drop it sharply, and narrate your investigation out loud.

Week 3: Statistics and experimentation

Review the logic behind p-values, confidence intervals, and statistical power without getting lost in formulas. Focus on when NOT to trust an A/B test result: novelty effects, network effects, and underpowered tests.

Week 4: Mock interviews and behavioural prep

Prepare 4-5 STAR stories from your actual work. At least one should cover a time you pushed back on a decision with data. At least one should cover a time your analysis was wrong and what you did about it. Practise presenting a mock dashboard or analysis to someone non-technical.

Salary context for reference, from knok job radar data:

Use these as a benchmark when evaluating or negotiating an offer.

Jumping to SQL before understanding the question. Interviewers report that candidates often start typing a query before confirming what the business question actually is. Pause and restate the problem in your own words first.

Ignoring data quality issues. In a live SQL round, not mentioning nulls, duplicates, or late-arriving events signals inexperience with real-world data.

Giving metrics without a decision link. Saying 'I would track DAU' is not enough. Say what you would do differently if DAU went up versus down.

Over-claiming results. Fabricating or inflating numbers in STAR answers is a common trap. Interviewers who probe the details will notice inconsistencies. Use approximate language such as 'roughly doubled' or 'reduced by around a third' if you do not remember exact figures.

Not asking clarifying questions. For open-ended product or experimentation questions, candidates who ask one or two good clarifying questions before answering tend to land stronger answers and signal senior-level thinking.

Treating every drop as a product problem. In edtech, many metric movements are driven by the academic calendar. A good analyst checks for seasonal patterns before escalating to the product team.