User
The actor. Add auth-specific fields as needed (e.g. passwordHash, providerId).
id email (unique) name Take-home assignment
Build a small attendance application: a user logs how they spent each working day of a month. The goal is to evaluate how you design something small but real end-to-end — data model, API, frontend, auth, and deployability.
You don't need to match my codebase. Pick what you're comfortable with. I care about a working, reasoned solution.
01 — Domain
Pseudocode, not a contract — rename, restructure, retype as your stack dictates. What matters is the shape of the relationships and the rules below.
The actor. Add auth-specific fields as needed (e.g. passwordHash, providerId).
id email (unique) name The thing a time entry is logged against — a work category.
id name code type (WORK | VACATION | HOLIDAY) One record per user per month — the container for time entries.
id userId year month A single line: "on this day, I spent X minutes on this assignment".
id attendanceId assignmentId date workedMinutes 02 — Functional requirements
Whatever you pick, the seeded users below must be able to log in out of the box. For magic-link or OAuth, that means a local mail catcher (Mailpit, MailHog) or pre-authorized provider accounts — document it.
HH:MM).
Both server- and client-side validation are expected. Server-side is non-negotiable; client-side is for UX. State your validation rules clearly in the README.
03 — Non-functional
The app must come up empty-but-usable after a single command. Provide a seed that creates at least:
types
Seed credentials may be hard-coded — call it out in the README as a dev artifact.
I should be able to spin it up from a fresh clone in one step. Pick whichever fits your stack:
docker compose up — recommended; this is how I run my own
stuff. Includes the DB, server, web, and
seed step.
pnpm dev,
make up,
./scripts/start.sh — fine if it actually works on a clean machine
with the documented prerequisites.
Whichever path you pick, the README must list:
Monorepo or polyrepo — your call. A monorepo pairs nicely with Docker Compose, but plenty of shapes work.
README.md with: setup steps, seeded credentials, your tech-stack
choices and the
why, a list of what you skipped or would
add with more time.
.env. A
.env.example is expected.
04 — Tech stack
A clean, working Go/Python/Ruby solution is more interesting than a half-finished TS one. I'll evaluate the result, not whether you matched my stack.
05 — Stretch goals
06 — Review
Can I run it from a fresh clone with one command (or open a deployed URL), and exercise the full flow end-to-end on the first try?
Are constraints (uniqueness, FKs) enforced at the DB level where they should be?
Can user A read or modify user B's data by guessing IDs? If yes, you fail this section.
What happens if I submit workedMinutes: -60? 99999? A date outside the month? An empty assignment?
DB down, malformed payloads, dependency timeouts — are errors caught at the right layer, surfaced clearly to the client, and not silently swallowed? Crashing is fine; lying isn't.
If your language has a type system, is it doing work? No `any` / `interface{}` escape hatches at API boundaries, narrow types at the surface, invariants encoded in types where they fit.
Can someone find their way around in 10 minutes? File structure, naming, separation of concerns.
Setup that works, documented trade-offs, an honest "what I'd do next" section.
07 — Deadline & timing
In your submission, include rough timings for the major parts of the work — for example:
I'm not grading by speed. I want the data to calibrate future assignments and to understand where you spent your effort.
08 — Submission
Drop your repo URL below and I'll get a ping. Email is fine too — the address you received this from. Either way, include with your submission:
Good luck.