Fileshare

Problem

A greenfield build: a minimal file-sharing service. Clone the starter repo, use your own editor and AI tools, and build under a 60-minute timer.

The spec

A small REST service:

• POST /files — upload (name, bytes, metadata) → returns a file id
• GET /files — list files (id, name, size, created)
• GET /files/:id — download the bytes
• DELETE /files/:id — remove
• Bonus: POST /files/:id/share creates a share link that expires after a TTL, and GET /s/:token honors expiry.

This is a low-level-design-flavored problem: the shape of the system is being evaluated as much as the endpoints.

What interviewers watch

• Do you model the entities (File, ShareLink) before writing any logic?
• Is storage behind an interface you could swap (memory → filesystem → S3)?
• Do you write the API-contract tests first and agree the cases with the interviewer?
• Expiry semantics: is an expired-at-exactly-TTL link served or rejected?

Submission

Export your code and AI chat transcript, note tools and time, and submit for a verdict.

Deliverables

• A REST API: upload, list, download, delete
• Optional expiring share links (TTL)
• Storage behind a repository-style interface (in-memory OK, filesystem better)
• Tests covering the API contract and expiry