KadraPractice

Practice real TypeScript CMS engineering on a live headless-CMS codebase

Quillio is a real, running headless CMS with three seeded bugs in its publishing, slug, and draft-visibility logic. You're handed a ticket, open a real GitHub pull request against the actual bug, an AI teammate reviews your diff like a coworker would, and a hidden test suite decides — objectively — whether your fix works.

Real GitHub PRs · Graded by tests, not vibes · Certificate on completion

What you'll actually do

Three real bugs in Quillio's publishing pipeline

This isn't a lesson plan. You clone Quillio, a working headless CMS with posts, publishing, and a public content API. You're handed a ticket describing a real reported bug, you read the relevant code, fix it, and open a pull request. An AI teammate reviews the PR in the thread. A hidden test suite tells you whether it's actually fixed.

CMS-401

Publishing a post never updates its updatedAt, so the feed goes stale

The publish/edit handler writes the new content and status but never touches updatedAt — and the feed sorts by updatedAt descending. Recently published or edited posts stop rising to the top, so the feed looks frozen even as authors keep publishing. Passing requires updatedAt to be set on every publish and edit path, the feed to sort newest-updated first, and untouched posts to keep their original order.

CMS-408

Duplicate slugs collide on the same URL

The create-post path saves whatever slug is supplied without checking for an existing post with the same slug, including a case-insensitive match — so “My-Post” and “my-post” can collide, and whichever post renders last silently shadows the other. Passing requires duplicate slugs to be rejected or auto-suffixed, case-insensitively, without breaking existing unique slugs.

CMS-417

Draft posts leak into the public API

The public list and detail endpoints query posts with no status filter, so drafts — including posts authors never intended to publish — are visible to anonymous readers. Passing requires the public endpoints to exclude drafts entirely, while the authoring endpoint (which is supposed to show an author their own drafts) keeps working exactly as before.

How grading works

An authoritative test suite decides — not a reviewer's opinion

Every Quillio ticket ships with a hidden, authoritative test suite — the same kind of check that gates a PR in a real CI pipeline. That suite, not a human's impression, decides whether your fix passes.

  • The hidden test suite is the pass/fail gate. It runs the same checks a real CI pipeline would run against your PR, and it's what decides whether CMS-401, CMS-408, or CMS-417 is actually fixed.
  • An AI teammate reviews your diff in the PR thread — asks questions, flags issues, requests changes, exactly like a coworker would. That review is real feedback layered on top of the test suite; it isn't the pass/fail gate itself.
  • Time on the ticket is tracked as part of a simulated sprint — standups, the work itself, and a retro at the end — the same rhythm as a real team.
  • Tickets shipped and hours logged both roll into a certificate showing the stack (TypeScript / Node), the tickets you shipped, and hours tracked — with a public, verifiable link for a resume or LinkedIn post.
See exactly how the grading pipeline works →
Who it's for

Who the CMS track is for

Quillio assumes you already know TypeScript and basic backend/API concepts — it's testing whether you can debug and ship inside someone else's codebase, not teaching you the language from zero.

Backend-leaning devs and bootcamp grads whose portfolio is all solo CRUD apps, with no real PR-review experience to point to.

Engineers who've used a CMS as a content editor (Contentful, Sanity, WordPress) but never debugged one from the inside.

Anyone prepping for interviews who wants to say “I fixed a slug-collision bug in a real publishing pipeline” instead of “I built a blog.”

Developers who've never had a real code review and want to feel what an actual “request changes” comment is like before it happens on the job.

Not for: day-one beginners with no TypeScript or backend fundamentals — Quillio tests debugging inside an existing codebase, not language basics.

FAQ

Questions engineers actually ask about the CMS track

Is this just a course with extra steps?

No. There's no video, no lesson, no multiple choice. You get a ticket describing a real bug in a real running CMS, and you fix it by opening a real GitHub pull request. Everything after that — review, grading — happens the way it would on an actual team.

Who's actually reviewing my PR?

An AI teammate reviews the diff in the PR thread the way a coworker would — asking questions, flagging issues, requesting changes. Whether your fix is actually correct is decided separately, by a hidden automated test suite, so the outcome isn't a matter of the reviewer's opinion.

What happens if I fail the test suite?

You get the failing test output — what passed, what didn't — and you keep iterating on the PR until it passes, same as you would against CI on a real team.

Can I put this on my resume or LinkedIn?

Yes. Completed tickets and tracked hours generate a certificate with a public, verifiable link, built for exactly that.

How long does the CMS track take?

It's sized like a sprint's worth of real tickets, not a single afternoon exercise — expect to spend real, trackable hours across CMS-401, CMS-408, and CMS-417, the same way you'd clear a sprint backlog.

Do I need TypeScript/Node experience already?

Yes — this tests and builds your ability to debug and ship inside an existing codebase, not to learn the language for the first time.

What's actually different from LeetCode or a bootcamp capstone?

LeetCode tests algorithm recall in isolation. A bootcamp capstone is usually a solo project nobody reviews. Quillio is someone else's codebase, with a real bug, a real PR, a real reviewer, and a real pass/fail bar — the actual shape of the job.

Stop practicing CRUD tutorials in a vacuum. Fix a real publishing bug, in a real PR, reviewed like a real coworker would.