t.
Headless CMS · Senior Frontend Engineer
The Agile Monkeys · Frontend

You don't take a test. You take over a project.

Build the admin panel for a small headless CMS, the kind behind Contentful, Sanity or Strapi. People define their own content schemas, then manage entries through them.

Begin
What you'll build

The admin experience.

Front-end is the whole point. Use any stack you like. Keep the backend thin, just enough to store and serve the data.

A

Schema builder.

Let people create and edit content schemas. A schema is a content type, like Car, Person, Article or Product, made of named, typed fields. Support at least text, number, boolean, date, and references to another schema. A reference field lets them pick an entry from the schema it points to.

Example schema:

Car {
brand  text
year   number
owner  reference → Person
}
B

Dynamic entry editor.

Create, view, edit and delete entries for any schema. The form isn't hand-written per type, it's generated from the schema definition, and it updates when the schema changes. People should be able to browse a schema's entries and jump between referenced entries.

Car · new entry
brandTesla
year2024
ownerAda Lovelace
C

Real-time updates.

What one client changes, the others see right away. Create or edit a schema, add or delete an entry, and every open client reflects it without a page refresh. If a schema change hits an entry someone has open, handle it gracefully. Any approach works: WebSockets, SSE, polling, Supabase, Firebase.

Client A adds entry “Tesla”
Client B ↳ it appears live, no refresh
D

Schema evolution.

The open-ended part, and the one we care most about. When a field is renamed, deleted, retyped, made required, or a reference changes target, entries may already exist. Show how you communicate the risk, surface the affected entries, preview before applying, and let people fix data that no longer fits — including when the schema shifts mid-edit. You don't need every case, just a clear direction.

The hard case
year changes from text → number
…but entries already hold values like “vintage” and “n/a”.
E

Read API.

A simple read API on top of the content. Nothing production-grade, just proof the admin panel is managing real content another app could consume.

GET /api/content/car → all cars
GET /api/content/car/:id → one car
How it works

Please, use AI. We do too. Just own every line you send us.

If the work's strong, we pair. We go through your code together and talk through a few real situations. No whiteboard puzzles, no trick questions.

When you're done

Send us the repo.

Push your code to a repo and send us the link at hiring@theagilemonkeys.com. Make sure it includes four things:

01

A working application.

It should run and do what you set out to build. A small slice that actually works beats a broad one that doesn't.

02

A README.

Clear instructions to install and run it locally. We should be able to get it going without asking you.

03

Walk us through it.

An async presentation of how you approached the challenge: your architecture, data model, how real-time and schema changes work, the trade-offs you weighed, and what you'd improve next. Any format you like, a Loom, a video, a deck, a doc. Keep it tight: under ten minutes if it's a video, under fifteen slides if it's a deck.

04

Your AI session.

The record of how you worked with AI, whatever your tools produce: a chat export, a prompts log, screenshots. We want to see how you used it, not whether you did. Own every line you send us.