Drone Dispatch API Task
Elmenus interview question (Egypt) · stage: Take-home Task · domain: System Design and SQL · role: Backend Engineer · difficulty: Medium · asked 4 times, last in April 2024
What they ask
The backend take-home that candidates received from late 2023 into 2024 is a dispatch controller for a fleet of delivery drones that carry medications. The brief:
A drone has a serial number (up to 100 characters), a model (Lightweight, Middleweight, Cruiserweight, Heavyweight), a weight limit (500 g max), a battery percentage and a state (IDLE, LOADING, LOADED, DELIVERING, DELIVERED, RETURNING). A medication has a name (letters, numbers, hyphen and underscore only), a weight, a code (upper case letters, numbers and underscore only) and an image.
Build a REST service that lets a client:
- register a drone;
- load a drone with medication items;
- check the items loaded on a given drone;
- list the drones available for loading;
- check a drone's battery level.
Rules: never load a drone beyond its weight limit; a drone with battery under 25 percent cannot enter LOADING; a periodic task checks every drone's battery and writes an audit log of the readings. JSON in and out, no UI, a fleet of 10 drones preloaded, a database that runs locally (in-memory or a container), and a README with build, run and test steps. Unit tests are optional but advised, and the brief says plainly that they will read your commit history.
Most candidates used Java 17 with Spring Boot and MySQL or H2; one used Node with TypeScript. Swagger or a Postman collection is common.
Where it sits in the loop, per a backend candidate from the same period: an HR call, a one-hour technical interview, then this task with a week to deliver, then a final interview, then the offer, about two weeks end to end.
What they look for
- Validation that matches the spec exactly (the regexes on name and code, the 500 g cap, the 25 percent rule) with clear 4xx responses when it fails.
- A state machine enforced in the service layer, not in the controller.
- The periodic battery check done with the framework scheduler and an audit table, not a log line.
- Loading as one transaction: either all items fit and the state moves, or nothing changes.
- Small, well-named commits that show how you worked, since they ask for it.