upGrad-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Long-form cohort education is a program-management problem. A learner joins a cohort with a start date, moves through modules with prerequisites, submits assignments against deadlines that can be extended, is graded against a rubric, and pays in instalments that gate continued access. Machine coding rounds in the style of upGrad take their scenarios from that administrative machinery.
It is a domain of dates and eligibility rather than concurrency, and that changes what is graded: deadline arithmetic that survives extensions and time zones, prerequisite evaluation, and instalment schedules where a missed payment has defined consequences. This page covers the format, the evaluation lens, and Gronex repositories with the same mechanics.
What a upGrad-style machine coding round looks like
A representative build is a cohort progression service: enrol a learner into a cohort, unlock modules when prerequisites are met, accept assignment submissions before a deadline with a late-submission penalty, apply extensions, and compute a final grade from weighted components. Some variants focus on the fee side — an instalment plan with due dates, partial payments, and an access rule when an instalment is overdue.
Deadline handling carries most of the weight. A deadline is not a timestamp on the assignment; it is per-learner, because extensions are individual. The correct model is a base deadline on the assignment plus an effective deadline resolved per learner, and the late penalty computed from the effective one. Candidates who mutate the assignment deadline to grant an extension change it for the whole cohort, which is the bug the round is designed to surface.
Grading is a weighted aggregation with rules about missing components, resubmission, and the best-of-N case. The reviewer tests a learner who never submitted one component and a learner who resubmitted after the deadline. The fee variant tests a payment covering part of an instalment and an overdue instalment that must restrict access without destroying enrolment — and both variants end with an extension request that checks whether your rules were data.
How you’re evaluated
Per-learner effective deadlines
Extensions applied to the learner, not the assignment, with the effective deadline resolved at evaluation time.
Prerequisite unlocking
Module availability derived from completion state and prerequisites, computed rather than stored as flags.
Weighted grading rules
Component weights, missing-submission handling, late penalties, and resubmission policy applied exactly as stated.
Instalment consequences
Due dates, partial payments, and an overdue rule that restricts access without corrupting the enrolment record.
Common mistakes that fail this round
- Granting an extension by editing the assignment deadline, which silently extends it for the entire cohort.
- Storing module-unlocked flags that drift when a prior completion is revoked.
- Ignoring the missing-submission case, so a learner with one blank component gets a misleadingly high grade.
- Computing weighted grades in floats and reporting a percentage that does not match the components.
- Treating an overdue instalment as cancellation, destroying the enrolment instead of restricting it.
Quick tips for the room
- Resolve an effective deadline per learner; never mutate the assignment’s.
- Derive module unlocking from completions, not from stored flags.
- Keep weights and penalties in data so the follow-up is a config change.
- Use a date library for due-date arithmetic, never day counts.
How to prepare
Separate the assignment deadline from the learner-specific effective deadline immediately, then compute unlocking and grades as functions of stored submissions and payments rather than flags. Write the penalty and weighting rules as data. This domain rewards deriving state more than almost any other machine coding domain.
The repositories below match the mechanics: the course enrolment problem is progression with prerequisites, the exam grading engine is weighted scoring and attempt state, the task dependency problem is prerequisite graphs with cycle detection, the billing engine is instalments with due dates and dunning, and the free validation problem covers the input rules an admin API needs.
Practice problems in the upGrad-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
Progression with prerequisites, capacity rules, and idempotent completion tracking.
Open the challenge →Attempt & Grading Engine
Attempt state, scoring rules with penalties, and deterministic result publication.
Open the challenge →Task Dependency Manager
Prerequisite graphs with cycle detection and deterministic ordering — module unlocking in abstract.
Open the challenge →Billing & Instalment Engine
Due dates, partial payments, proration, and dunning states — the fee side of a cohort program.
Open the challenge →API Debugging: Validation & Errors
Reject invalid admin input at the edge with a consistent error envelope. Free to try.
Open the challenge →FAQ
Were these problems asked at upGrad?
No. They are Gronex originals in the style of cohort-education rounds — the kind of problem asked in rounds like upGrad’s. Gronex is not affiliated with upGrad.
Why is the extension case such a reliable trap?
Because the obvious implementation — update the deadline — is wrong in a way that passes every happy-path test. Only a second learner reveals it, and that is exactly the test the reviewer writes.
Is concurrency part of this round?
Rarely the focus. The graded skills are date arithmetic, derived state, and rule-as-data, which is a different muscle from the inventory and payments rounds — and worth practising separately.
Should I build grading or fees if both appear?
Pick the one the statement leads with and build it fully; a complete half beats two partial halves. Then describe the other in the discussion, which is usually where the interviewer wanted the conversation anyway.
Related
Gronex is not affiliated with, endorsed by, or sponsored by upGrad. 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 upGrad.