Porter-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Intra-city goods movement adds constraints that passenger mobility does not have: the vehicle class must fit the load, a trip can have several stops in a required order, labour can be requested separately, and waiting time at each stop is billable. Machine coding rounds in the style of Porter use that extra structure, which makes them richer than a plain matching problem.
The result is a round where allocation is filtered by capability before it is ranked by distance, and where the trip itself is a small ordered workflow rather than a single pickup and drop. This page covers the reported format, what evaluators weight, and Gronex repositories that train the same allocation-and-workflow mechanics.
What a Porter-style machine coding round looks like
A typical build is a booking-and-allocation service: accept a booking with a vehicle class, a pickup, and one or more drops; find eligible partners whose vehicle class satisfies the requirement and who are available; allocate one; then progress the trip stop by stop with arrival, loading, and departure events. Fare rules usually include a base for the class, distance, per-stop charges, and waiting charges beyond a free allowance.
Eligibility before ranking is the structural point. A three-wheeler cannot take a two-tonne load, so the candidate set is a filter applied first, and the round checks that an upgrade rule — a larger vehicle may serve a smaller requirement, but not the reverse — is implemented as a stated policy rather than an accident of comparison. Getting this wrong produces allocations that are technically nearest and operationally impossible.
Multi-stop trips make the state machine two-dimensional: the trip has a status and each stop has one, and the trip can only advance when the current stop is complete. Reviewers probe skipping a stop, reordering stops after the trip has started, and cancelling at stop two of three — where billing has to account for work already done. Waiting charges then require an injected clock, since they are a duration measured between two events.
How you’re evaluated
Capability filtering
Vehicle-class eligibility applied before ranking, with the upgrade policy explicit and one-directional.
Ordered stop progression
Stops completed in sequence with no skipping, and a trip status derived from stop states rather than set independently.
Mid-trip cancellation billing
Cancelling at stop two bills the work done under the stated rule and releases the partner exactly once.
Duration-based charges
Waiting time computed from recorded arrival and departure events against an injected clock, with the free allowance applied per stop.
Common mistakes that fail this round
- Ranking all partners by distance and then discovering the nearest one cannot carry the load.
- Implementing vehicle upgrades symmetrically, so a small vehicle is allocated to a large requirement.
- Keeping one status on the trip and none on the stops, which makes skip-detection impossible.
- Measuring waiting time with wall-clock calls inside the charge calculation, so no test can pin it.
- Cancelling mid-trip by resetting the trip, losing the record of the stop that was already served.
Quick tips for the room
- Filter by capability first, rank second, claim third.
- Give every stop its own status; derive the trip status from them.
- Record arrival and departure events; compute charges from the records.
- Decide the mid-trip cancellation billing rule before you write cancel().
How to prepare
Model the trip as an ordered list of stops with their own statuses and derive the trip status from them; that single decision answers most of the probing. Then implement eligibility as a filter with a documented upgrade rule, and make waiting charges a function of recorded event times. Practise the cancel-at-stop-two case explicitly — it is the question that separates prepared candidates.
The repositories below cover each axis: the driver-matching problem is selection and release, the assignment-race problem is contention on a scarce vehicle, the task dependency problem is ordered progression with prerequisites, the SLA problem is duration measurement with an injected clock, and the free seat-reservation problem is the claim-and-release pattern in its simplest testable form.
Practice problems in the Porter-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.
Partner Matching & Allocation
Candidate selection with deterministic tie-breaks, assignment, and release on cancellation.
Open the challenge →Assignment Race Resolution
Two bookings race the only eligible vehicle: exactly one wins, with ordered locking and no deadlock.
Open the challenge →Task Dependency Manager
Ordered progression with prerequisites, cycle detection, and deterministic sequencing — the multi-stop muscle.
Open the challenge →SLA & Duration Tracking
Durations and deadlines measured against an injected clock — the waiting-charge mechanic, testably.
Open the challenge →Seat Reservation System
Claim-and-release as a state machine: reserve, cancel, list availability deterministically. Free to try.
Open the challenge →FAQ
Are these real Porter interview questions?
No. They are Gronex originals in the style of intra-city logistics rounds — the kind of problem asked in rounds like Porter’s. Gronex is not affiliated with Porter.
How much of this is just the ride-matching problem?
The allocator is similar, but two things change the design: eligibility filtering by vehicle class before ranking, and trips with ordered stops. Both add state the passenger version does not have, and both are where the probing happens.
Do I need real distance or map data?
No. A supplied distance function or coordinate pairs are the norm. Inventing routing accuracy is wasted time; spend it on the stop progression and the cancellation billing rule.
What is the most commonly missed edge case?
Cancellation after partial service. Candidates handle cancel-before-start and cancel-after-completion, then have no answer for a trip cancelled between stops — which is the one the reviewer asks about.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Porter. 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 Porter.