Unacademy-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Live online education is a scheduling product with an access-control product wrapped around it. Classes happen at fixed times in batches with capacity, educators cannot be in two live sessions at once, and whether a learner may join depends on an active subscription that covers this goal, this batch, and this date. Machine coding rounds in the style of Unacademy draw on both halves.
The entitlement half is what makes the round distinctive. Access is not a boolean on the user; it is the result of evaluating a subscription’s plan, validity window, and scope against the resource being requested — and that evaluation is exactly what interviewers probe with expired, upgraded, and refunded subscriptions. This page covers the format, the evaluation criteria, and Gronex repositories with the same mechanics.
What a Unacademy-style machine coding round looks like
The usual build is an enrolment-and-scheduling slice: create batches with an educator, a schedule, and a capacity; enrol learners subject to capacity and entitlement; prevent educator double-booking; and expose an upcoming-classes view per learner. Attendance tracking and a waitlist are the common extensions, and the statement typically defines the entitlement rules explicitly enough to test them.
Educator double-booking is the scheduling invariant. Two batches whose sessions overlap cannot share an educator, which is an interval-overlap check across a recurring schedule rather than a single appointment — the subtlety being that a weekly pattern must be expanded far enough to detect the clash. Candidates who check only the next occurrence pass the demo and fail the probe.
Entitlement evaluation is graded as a policy object. Given a learner, a resource, and a time, does an active subscription cover it — considering plan scope, validity, and any cancellation that ends access at period end rather than immediately? Rounds in this style ask for the refund case specifically, because it distinguishes an entitlement computed from subscription state from a flag that someone has to remember to unset.
How you’re evaluated
Recurring-schedule clash detection
Overlap checked across expanded occurrences so an educator is never booked into two simultaneous sessions.
Entitlement as evaluation
Access derived from subscription scope, validity, and cancellation semantics at request time — never a stored boolean.
Capacity and waitlist
Atomic enrolment against batch capacity, with a deterministic waitlist that promotes in order when a seat frees.
Idempotent attendance
Join events recorded once per learner per session, with duration derived from recorded events rather than accumulated blindly.
Common mistakes that fail this round
- Checking only the next session for educator clashes, missing a conflict three weeks out in a recurring batch.
- Storing an access flag on the user, which drifts the moment a subscription expires or is refunded.
- Enrolling with a read-then-increment against capacity, over-filling a batch under concurrent enrolment.
- Promoting waitlisted learners in map iteration order rather than join order.
- Counting attendance on every received join event, so a reconnect inflates the learner’s minutes.
Quick tips for the room
- Compute entitlement at request time; never cache it on the user.
- Expand recurring schedules before checking any clash.
- Make enrolment an atomic claim with an ordered waitlist.
- Derive attendance minutes from join and leave events, deduplicated.
How to prepare
Write the entitlement evaluator first as a pure function of (learner, resource, instant), and test the expired, cancelled-at-period-end, and refunded cases. Then build batch capacity as an atomic claim with an ordered waitlist, and expand recurring schedules before checking educator clashes. Those three cover the rubric.
The repositories below map the pieces: the course enrolment problem is the enrolment and progress core, the shared-calendar problem is clash detection under contention, the feature-flag problem is rule-based entitlement targeting, the billing engine covers subscription state including cancellation semantics, and the free seat-reservation problem is capacity claiming with a release path.
Practice problems in the Unacademy-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Course Enrollment & Progress Tracker
The enrolment core: capacity, prerequisites, progress tracking, and idempotent completion events.
Open the challenge →Shared Calendar Slot Booking
Clash detection under contention: overlapping sessions, per-resource availability, no double-booking.
Open the challenge →Rule-Based Targeting & Rollouts
Entitlement-style evaluation: ordered rules, cohort targeting, and deterministic bucketing.
Open the challenge →Billing & Proration Engine
Subscription state that entitlement depends on: upgrades, proration, cancellation, and dunning.
Open the challenge →Seat Reservation System
Capacity claiming with release: reserve, cancel, list availability deterministically. Free to try.
Open the challenge →FAQ
Were these problems asked at Unacademy?
No. They are Gronex originals in the style of live-learning platform rounds — the kind of problem asked in rounds like Unacademy’s. Gronex is not affiliated with Unacademy.
Why is entitlement better computed than stored?
Because subscriptions change without anyone touching the learner record — they expire, get refunded, or end at period close. A stored flag is a cache with no invalidation story, which is why reviewers ask about the refund case.
How far should I expand a recurring schedule?
Far enough to cover the clash you are checking, with the horizon as an explicit parameter. Saying that out loud — and noting that unbounded expansion is a memory problem — is the answer the question is looking for.
Is the waitlist usually required?
It is a frequent extension. Keeping enrolments in join order makes the promotion rule trivial, so it costs almost nothing to be ready for it.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Unacademy. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Unacademy.