You've just joined parcelLab as the Engineering Manager of the returns team. We run the customer-facing returns portals for a lot of brands you have heard of. Customers look up their order, see which items are eligible for return, and submit a request.
The portal is live, but it's rough around the edges: the previous engineer left before finishing some critical backend work, tests are failing, and a few things are broken. Your team is small and busy, and it's your first Monday.
This challenge has three parts. They're designed to be done in order, but manage your own time — that's rather the point.
Time limit: 4 hours total. If you hit the limit, stop and submit what you have. We'd much rather see well-reasoned partial work than a rushed complete solution. Suggested split: Part 1 ≈ 90 min · Part 2 ≈ 60 min · Part 3 ≈ 45 min · write-ups ≈ 15 min.
Please do not fork or publish this repository. Work locally and submit as a private repo share or a zip file.
AI tools are welcome throughout. If you use them, keep a brief log in AI_LOG.md — we're curious how you use them, not whether you do.
Stack: Python 3.13+, Django, DRF, pytest, ruff, mypy (strict). PyYAML is available.
uv sync
pytest # you'll see some failures — that's intentional
python manage.py runserverOpen http://localhost:8000/returns/ and try order RMA-1001 with email alex@example.com or zip 10115.
portal/
data/orders_raw.json # raw order payloads from upstream
services/mapper.py # maps raw payload → domain model (incomplete)
services/eligibility.py # return eligibility evaluator (stubbed on main)
templates/returns/* # Django + HTMX UI
tests/* # pytest suite (some tests intentionally failing)
- Jordan — senior engineer, 6 years at parcelLab. Deep domain knowledge. Started their four-week sabbatical on Friday and is unreachable.
- Priya — senior engineer, joined 8 months ago. Strong on backend and infra, currently splitting time 50/50 with the carrier-integrations team.
- Tomasz — mid-level engineer, 1.5 years in. Reliable, eager to grow, hasn't led anything solo yet.
Below is the team's current backlog. Pick one item and implement it yourself — choose the one where you personally being the author adds the most value right now. In DECISIONS.md, explain the pick: why this one, why not the others, and who on the team you'd give the rest to.
Note: BR-002 is already claimed — Jordan pushed an implementation before leaving (see Part 2). Don't pick it.
Upstream sends rich payloads, but the mapper was left unfinished — item-level flags never got wired up. The eligibility engine needs these to make decisions.
Missing fields on each article: is_digital, is_final_sale, category.
Look at orders_raw.json and the test fixtures to understand the different payload shapes you need to handle.
Several tests are failing. Some depend on BR-001 and BR-002, others may have their own issues. Make the suite green and add tests that give you confidence.
Product just told us: electronics should be 14 days, apparel gets 30, and so on. Add per-category window config and make the evaluator respect it, falling back to the order-level default.
A security researcher has contacted us claiming they found a vulnerability that allows unauthorized access to customer order data (see Part 3 for their email). We'd rather find it ourselves. Audit the codebase, identify the issue, write a test that demonstrates the exploit, and fix it.
Support keeps asking: can customers filter the articles list to only see what's actually returnable? Add a "Show returnable only" toggle using HTMX — no full page reload.
The "Continue" button on the articles page is dead — the rest of the flow was apparently deleted before the last push. Build the missing pieces: article selection → confirmation → success.
Before leaving for sabbatical, Jordan pushed branch feature/BR-002-eligibility-engine — the return eligibility engine (BR-002) — with the note:
"Eligibility engine done, all eligibility tests green. Built it config-driven so enterprise customers can get custom rules without code changes. Fine to merge without me. — J"
The PR is also open on GitHub if you prefer reviewing there: https://github.com/parcellab-dev-bot/em-challenge/pulls
Review it as you actually would. Write your review in REVIEW.md:
- Your findings, in whatever structure you'd really use — but make clear what blocks the merge and what doesn't.
- Your merge decision: merge / merge with follow-ups / request changes — and, since Jordan is unreachable for four weeks, what happens to the branch now.
- Write it to Jordan (they'll read it when they're back) — tone matters. Jordan is very good, and this codebase is more theirs than yours.
git diff em-challenge...feature/BR-002-eligibility-engine # the full change
git log em-challenge..feature/BR-002-eligibility-engine # Jordan's commitsOptional: if you'd rather review inline the way you normally would, push both branches to your own repo, open the PR there, and leave your comments on the diff.
REVIEW.md(or a link to your PR) is all we need either way.
It's 9:00 on your first Monday. In your inbox:
From: mailer@relay-anon.net — Subject: Vulnerability in your returns portal
I have identified a vulnerability in your returns portal that allows access to any customer's order data — names, home addresses, emails, purchase history. Works today, on production. I am giving you the chance to fix this before it becomes public. My fee for the full technical details is €15,000. You have two weeks. Payment instructions follow on confirmation.
From: Marta (VP Sales) — Subject: NordThreads demo — 2 weeks!!
Team — huge news, NordThreads (potentially our biggest returns customer ever) agreed to a live demo in two weeks. They specifically want to see a customer completing a return end-to-end in the portal. I told them no problem 🙂 Can you confirm we're good?
You have Priya (50%), Tomasz (100%), and yourself. Jordan is unreachable. Write PLAN.md containing:
- The plan for the next two weeks — what gets done, in what order, by whom (including you), what explicitly doesn't get done, and the risks you're accepting. A page at most.
- Your reply to Marta — she is non-technical, and she already made a promise. Decide what she needs to know, including whether and how you mention the security report.
You don't need to reply to the researcher, but if you have a view on how the company should handle it, we'd like to read it (2–3 sentences is fine).
- Your Part 1 implementation — working, type-safe code, small readable commits
REVIEW.md— your review of Jordan's PRPLAN.md— the two-week plan and the reply to MartaDECISIONS.md— what you picked, what you delegated or skipped, and whyAI_LOG.md— if you used AI tools, plus one short answer: what would your review bar be for AI-generated code on your team?
© parcelLab — May your returns always be smooth.