These independent assignments use synthetic data. Try them first, then check edge cases and open the hint. Time is an estimate; allow additional time for project tests and documentation.
Choose your practice · Interview mistakes
Scroll the table horizontally →
| Assignment | Stage | Estimate |
|---|---|---|
| A café shift CLI | Python basics | 180 min |
| A workshop job scheduler | Python engineering | 360 min |
| An ingredient procurement API | HTTP and APIs | 420 min |
| Equipment intake and repair | Web framework | 600 min |
| Versioned equipment manuals | Web framework | 720 min |
| Class bookings with reminders | Async and background jobs | 900 min |
A café shift CLI
Build a console app that manages orders for one café shift. Menu entries contain a dish code, an integer minor-unit price and allergens. Commands add items, change quantity, remove an item, print a receipt and close an order. Closed orders cannot be edited; empty orders cannot be closed. Persist active-order state in JSON across runs. Supply menu data and shift identity through a local file; no external API or database is required at this stage.
Check your result
- Demonstrate create → edit → restart → close → reject further editing.
- Unknown dish codes, negative quantities and malformed JSON produce clear errors without losing the last valid state.
- README includes commands and reproducible input data.
Hint — after your attempt
Start by separating input commands from order-changing functions.
Extension: Add undo for the last edit before closing and test state restoration.
A workshop job scheduler
Model a workshop: jobs have durations, required skills and dependencies; staff have skill sets. At discrete time steps, assign a ready job to an available qualified employee after all dependencies finish. Break ties by job id, then staff id. An employee remains occupied until the job ends. Keep the model independent of the console and use a separate schedule renderer. Dependency cycles or jobs without qualified staff must produce clear errors instead of infinite loops. Durations are positive integer step counts; an employee must have every skill required by a job.
Check your result
- No job runs twice and no employee performs overlapping jobs.
- Jobs start only after their dependencies finish.
- Identical input produces identical schedules; test deadlocks and empty input.
Hint — after your attempt
Separate job readiness, employee selection and time advancement.
Extension: Compare the greedy schedule with an alternative by makespan; do not claim optimality without proof.
An ingredient procurement API
A restaurant stores recipes and ingredient pack sizes. Implement an HTTP catalog API and a procurement calculation for a requested number of portions. Return required grams, whole-pack count and cooking leftovers for each ingredient. For example, 7 portions of 120 g with 500 g packs require 2 packs and leave 160 g. Use integer grams and minor currency units; store the catalog in a local SQL database. Define request contracts, error responses and input bounds. Stock-history tracking and inventory deduction are outside this project. Portions are integers from 0 to 10,000; zero yields zero procurement. Recipe quantities and pack sizes are positive.
Check your result
- Test exactly one pack, crossing a pack boundary and zero portions.
- Invalid values and missing recipes do not become HTTP 200.
- A clean run creates the schema and a sample recipe; HTTP tests cover calculations and errors.
Hint — after your attempt
Implement calculation as a pure function before adding HTTP and storage.
Extension: Add another pack size and explain when minimum pack count differs from minimum cost.
Equipment intake and repair
A repair service tracks new → diagnosed → approved → repairing → ready → delivered. Cancellation is allowed before repairing. Repair can begin only after the owner approves the price; delivery requires recorded payment. Every command supplies the expected request version; reject stale versions. Store transitions in the same SQL database. Provide an API and a simple list/detail screen or documented HTTP scenarios, migrations and rule tests. Test domain logic separately from the framework.
Check your result
- Do not bypass approval, deliver unpaid equipment or edit a delivered request.
- Two commands using the same version cannot lose history: only one succeeds.
- State changes and history writes are atomic; test rollback.
Hint — after your attempt
Write a transition table before implementing endpoints.
Extension: Add partial payment and price reapproval with new tests.
Versioned equipment manuals
Store equipment manuals as immutable revisions, with one revision marked current. Users see only their team’s equipment; editors upload and readers download. Metadata lives in PostgreSQL; content lives in filesystem or S3-compatible storage. Renaming the displayed file must not change its storage key. Validate size and permitted type; revoke access when a user leaves a team. Equal names in different teams do not conflict. Arbitrary folder trees and public links are outside this assignment.
Check your result
- Test reader, editor, another team and a former member.
- A failed file write cannot leave an accessible ready revision without content.
- Previous revisions remain downloadable; tests use temporary storage.
Hint — after your attempt
Separate display name, revision identity and physical storage key.
Extension: Clean up orphaned files after failures without deleting published revisions.
Class bookings with reminders
Build a workshop-class booking service with capacity tracking and reminders. Run API and worker as separate processes. PostgreSQL stores bookings, jobs and outgoing events; a broker or queue may redeliver work. An external schedule provider can be slow or fail: use a replaceable fake provider in tests. Do not send a reminder if cancellation was committed before sending began. The test sender accepts an idempotency key and returns the same result on retries. Start with one database and two processes; justify any additional services. Docker Compose starts the environment and CI runs checks.
Check your result
- Retrying a request or job cannot create another booking or duplicate the business effect.
- Worker restart preserves jobs; a provider timeout cannot block the API indefinitely.
- Test cancellation before send, a race for the last seat and a crash after execution before acknowledgement.
Hint — after your attempt
Define transaction and retry boundaries; state idempotency requirements for a real external sender.
Extension: Add measurable queue-delay, retry and provider-error metrics.