Technical Assignment — Backend Engineer (3-5
years)
Timeline: 48 hours from receipt.
Deliverable: A working local system + a README explaining your design choices and trade-
offs.
The Problem
Build a small system that processes freight bills (carrier invoices) for a logistics operations
team. For each incoming freight bill, the system needs to:
1. Match the freight bill to the correct Carrier Contract, Shipment, and Bill of Lading (BOL)
2. Check whether the billed weight, charges, and route align with the contracted rates and
the delivery records
3. Produce a decision (auto-approve / flag for review / dispute) along with a confidence
score and evidence of what was matched
4. Pause for human ops review when confidence is low, and resume processing once a
reviewer submits their decision
This mirrors a real logistics ops workflow. The data has deliberate ambiguity — some lanes
have multiple overlapping contracts, some freight bills reference no shipment ID, some
weights don’t match the BOL. Your job is to handle that ambiguity thoughtfully.
What We Provide
A seed_data.json file (attached) with:
5 carriers
8 carrier contracts (some with overlapping date ranges for the same lane)
7 shipments
5 bills of lading
10 freight bills covering different scenarios (clean matches, ambiguous matches, edge
cases)
That’s it. Everything else — schema design, infrastructure setup, LLM integration, API
contracts — is up to you.
What You Build
1. A Backend API (FastAPI)
At minimum:
POST /freight-bills — ingest a freight bill (from the seed data). Triggers the agent.
GET /freight-bills/{id} — retrieve a freight bill’s current state, decision, and
evidence chain.
GET /review-queue — list freight bills currently waiting for human review.
POST /review/{id} — submit a reviewer decision (approve / dispute / modify) to
resume the agent.
2. Data Layer
Relational database (Postgres preferred) for freight bills, decisions, audit trail, and any
state the agent needs to persist.
Graph database or equivalent for modeling relationships between Carrier, Contract,
Lane, Shipment, BOL, and Freight Bill. Neo4j is a plus. NetworkX (in-memory graph), a
Postgres edge table, or any other approach that demonstrates graph thinking is
acceptable. Use what you’re comfortable with.
3. The Agent (LangGraph)
A stateful agent that:
Takes a freight bill and traverses the graph to find candidate Contracts, Shipments, and
BOLs
Validates charges, weights, and dates using deterministic rules (not the LLM)
Uses an LLM where it makes sense — e.g., normalizing carrier names, generating
explanations, handling messy unstructured fields
Computes a confidence score based on how cleanly the freight bill matches
Auto-decides when confidence is high
Uses interrupt() to pause when confidence is low, waits for reviewer input via the
review endpoint, then resumes
4. A README
Include:
How to run it locally (we should be able to docker-compose up or follow a few
commands and have it working)
Your schema design and why you chose it
Your graph model and why you chose this DB for it
How confidence is computed — what inputs feed into the score
How human-in-the-loop is implemented (the interrupt/resume pattern)
What you’d do differently with more time
Any trade-offs you made deliberately
Bonus Points
These are not required. But if you finish the core loop with time to spare, any of these will
stand out:
Deploy it on GCP — Cloud Run for the API, Cloud SQL for Postgres. A link we can hit.
Even a partial deployment is a signal.
GCP Secret Manager for API keys instead of .env files.
Tests — not exhaustive coverage, but at least one test for the agent’s core decision
logic.
Observability — structured logging of agent decisions, or a simple dashboard endpoint
showing agent performance metrics.
Ground Rules
Free-tier LLM APIs are fine. OpenAI free tier, Claude free tier, Gemini, or local models
— use whatever you have access to.
Use AI coding assistants freely. Claude, Copilot, Cursor, whatever you use normally.
We care about the design, the architecture choices, and how you think — not whether
you typed every line yourself.
Local is fine. You don’t need to deploy anywhere (GCP deployment is bonus, not
required).
Quality over completeness. We’d rather see 70% of the scope working well than 100%
working poorly.
How We Evaluate
We read the README first, then the code. We care about:
How you designed the schema and why
How cleanly the agent handles the ambiguous cases in the data
Whether human-in-the-loop is a real pattern or a workaround
Whether your code reads like production code
Your ability to explain trade-offs in plain language
We do not care about:
Fancy frontends
Perfect test coverage
Getting every single freight bill in the seed data correctly classified
Code you didn’t write (AI-assisted is fine, as long as you understand what’s there and
can defend your choices)
Submission
GitHub repo link (public or private with access shared)
README visible at the root
If you deploy to GCP, include the URL
One paragraph in your email explaining what you completed, what you deferred, and
why
Questions? Email us. We’d rather clarify than have you guess wrong.
Good luck.