Example job post · Fictional company
Backend engineer
Cedar Tools
What we read
Cedar Tools is a fictional logistics software company created for interview practice. Our example product helps regional delivery operators coordinate parcel handovers between depots, drivers and partner carriers. This is not a real vacancy. We seek a backend engineer who enjoys making event-driven systems dependable when scanners lose connectivity and different partners report the same event in different ways. Our platform uses Go services, PostgreSQL for operational records and Kafka for parcel events. HTTP APIs support depot applications and carrier integrations. Services run in containers, with OpenTelemetry traces and structured metrics used during incident investigations. A small engineering team works with operations staff to understand how late arrivals, damaged labels and route changes affect the people using the system. You will design idempotent ingestion endpoints for repeated scanner uploads, handle out-of-order delivery events without corrupting parcel history, and build replay-safe consumers for partner feeds. Responsibilities also include backfilling missing events, improving slow queries on depot dashboards, and planning PostgreSQL schema migrations that do not interrupt dispatch. We release in small steps and document rollback plans before changing shared message formats. We require experience building a production backend in Go or a comparable language, a working understanding of SQL transactions and indexes, and clear reasoning about retries and failure boundaries. You should be comfortable diagnosing queue lag using traces and metrics, explaining consistency trade-offs to operations colleagues, and writing tests that simulate duplicate messages and partial outages. We do not expect a particular cloud certification. Nice-to-haves include logistics domain knowledge, Kafka consumer-group experience and familiarity with geospatial queries. In your first quarter, you would reduce manual investigation of parcels with missing handover scans and establish a measurable baseline for ingestion delay. You would join a supported incident rota after onboarding, pair on unfamiliar incidents, and contribute blameless follow-up notes that turn recurring operational problems into bounded engineering work.Example questions
Pre-written examples. No AI is called in the demo.
- How would you design an ingestion endpoint to handle repeated uploads from scanners that may have been offline?
From the post: You will design idempotent ingestion endpoints for repeated scanner uploads
- How would you preserve an accurate parcel history when delivery events arrive out of order?
From the post: handle out-of-order delivery events without corrupting parcel history
- What design choices would help a Kafka consumer safely replay partner-feed events?
From the post: build replay-safe consumers for partner feeds
- Describe how you would investigate and backfill parcel events that appear to be missing.
From the post: Responsibilities also include backfilling missing events
- How would you approach improving a slow depot dashboard query, and what would you examine in PostgreSQL?
From the post: improving slow queries on depot dashboards
- How would you plan a PostgreSQL schema migration so dispatch can continue without interruption?
From the post: planning PostgreSQL schema migrations that do not interrupt dispatch
- If queue lag rises during an incident, how would you use observability data to diagnose the cause?
From the post: diagnosing queue lag using traces and metrics
- How would you establish a measurable baseline for ingestion delay and decide whether it is improving?
From the post: establish a measurable baseline for ingestion delay