Practo-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Healthcare scheduling is slot booking with a set of rules nobody else has: doctors run token queues as well as fixed appointments, clinics deliberately overbook against expected no-shows, a consultation can be rescheduled by the provider rather than the patient, and every record access is subject to who is allowed to see it. Machine coding rounds in the style of Practo lean on those specifics.
That last point makes the round unusual: authorisation is rarely optional here. A patient’s history, prescriptions, and reports are exactly the kind of data an interviewer will try to read from the wrong account. This page covers the commonly reported format, the evaluation criteria, and Gronex repositories with the same scheduling and access-control mechanics.
What a Practo-style machine coding round looks like
A common statement is an appointment service: define a doctor’s schedule as sessions per clinic with a slot duration or a token count, expose bookable capacity, book and cancel, and handle provider-initiated rescheduling that must move or notify every affected patient. Statements often add a policy such as allowing N per cent overbooking per session, or a walk-in token that interleaves with booked appointments.
Token queues are the mechanic that distinguishes this from a generic calendar. A session with twenty tokens is not twenty timed slots — it is an ordered queue with an estimated time per patient, so the interesting operations are issuing the next token, inserting an emergency case at the front under a stated rule, and recomputing estimates when the doctor runs late. Candidates who force it into fixed slots cannot express any of that.
Provider-initiated rescheduling is the second surface, and it is a fan-out with correctness requirements: a cancelled session must move every appointment in it, in a defined order, into the next available capacity or into a cancelled state with a reason, and it must be idempotent because this is exactly the operation that gets retried. Access control then closes the round: every read of a patient record must be scoped to the patient, their treating doctor, or an explicitly authorised staff role.
How you’re evaluated
Session and token modelling
Sessions with either timed slots or ordered tokens, capacity derived from the session, and estimates recomputed when the queue slips.
Overbooking as policy
A stated overbooking allowance applied at the session level, with a clear boundary and a defensible rejection past it.
Idempotent bulk reschedule
Cancelling a session moves or cancels every appointment once, in a deterministic order, and re-running the operation changes nothing.
Record access control
Every record read authorised against the requester’s relationship to the patient, enforced in the domain layer rather than assumed.
Common mistakes that fail this round
- Forcing token queues into fixed time slots, which makes emergency insertion and slipping estimates inexpressible.
- Treating the overbooking allowance as a soft suggestion with no enforced boundary.
- Bulk rescheduling in undefined order, so re-running it produces a different assignment.
- Letting any authenticated user fetch a record by id — the exact leak the reviewer probes first.
- Cancelling appointments without a reason, leaving no way to tell a provider cancellation from a patient one.
Quick tips for the room
- Make the session the unit of capacity, not the individual slot.
- Support tokens as an ordered queue with recomputable estimates.
- Make bulk reschedule deterministic and safe to run twice.
- Authorise every record read in the domain layer, and demo a denial.
How to prepare
Model the session as the unit of capacity and support both slot-based and token-based sessions behind one interface. Then implement bulk reschedule as a deterministic, idempotent operation. Finally, put an authorisation check at the entry of every record read and demonstrate it failing for the wrong caller — in this domain, showing the denial is worth as much as showing the happy path.
The repositories below cover the pieces: the shared-calendar problem is slot booking under contention, the hotel-booking problem is the interval predicate, the SLA problem is duration and deadline handling with an injected clock, the authorisation-leak problem is the record-access drill, and the free validation problem covers the request-level rules a clinical API needs.
Practice problems in the Practo-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.
Shared Calendar Slot Booking
Appointment booking under contention: overlap rules, per-provider availability, no double-booking.
Open the challenge →Hotel Room Booking System
The half-open interval predicate done once and correctly, plus cancellations that truly free capacity.
Open the challenge →SLA & Deadline Tracking
Clock-driven deadlines and breach evaluation with an injected clock — the slipping-queue mechanic.
Open the challenge →API Debugging: Authorization Leak
Fix an IDOR so no account can read another patient’s records — the healthcare-round reflex.
Open the challenge →API Debugging: Validation & Errors
Reject malformed clinical input at the edge with a consistent error envelope. Free to try.
Open the challenge →FAQ
Were these problems asked at Practo?
No. They are Gronex originals in the style of healthcare scheduling rounds — the kind of problem asked in rounds like Practo’s. Gronex is not affiliated with Practo.
Why are token queues worth modelling?
Because most Indian outpatient practice runs on them, and they behave differently from timed slots: capacity is a count, order matters, and estimates move when the doctor runs late. A design that supports both is a strong differentiator.
Is authorisation really graded in a machine coding round?
In this domain it usually is, because the data is sensitive and the check is cheap to demand. Enforcing the relationship between requester and patient inside the service layer, and demonstrating a denial, is the expected behaviour.
How should I handle overbooking?
As an explicit policy on the session with a hard boundary — for example capacity plus ten per cent, rounded down, rejecting anything beyond. The mistake is leaving it vague; the round wants a number and a rejection.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Practo. 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 Practo.