KadraPractice

Practice realtime engineering on a working WebSocket chat app

Pulse is a working chat app with channels, a WebSocket message layer and reconnect handling. Messages arrive out of order, unread counts climb on the channel you're reading, and messages sent during a disconnect disappear. You fix each bug and open a GitHub pull request. An AI teammate reviews it, and a hidden Vitest suite decides whether it passes.

Real GitHub PRs · Graded by Vitest · Free during beta

What you'll actually do

Three bugs in Pulse's messaging layer

Realtime bugs depend on timing, which makes them hard to spot in a tutorial and common in production. Each ticket is a bug report with acceptance criteria, in a codebase you didn't write.

RT-601

Messages render out of order under rapid sends

Messages are shown in the order their network responses arrive, so a later message can jump ahead and optimistic echoes never settle into place. To pass, messages have to follow the server's order whatever the timing, echoes have to land in their confirmed position, and nothing can appear twice.

RT-607

Unread count climbs on the channel you're viewing

The counter goes up on every incoming message, including in the channel you have open. To pass, a focused channel stays at zero, and background channels still count up as messages arrive.

RT-613

Messages sent during a disconnect are lost

After a drop, the client just resubscribes to live events and never fetches what it missed. To pass, it has to backfill from the last message it saw, with no gaps or duplicates, and keep the order right across the reconnect.

How grading works

Vitest decides whether the fix works

Each Pulse ticket has a hidden test file that's added to your branch at grading time. The result appears on your pull request as a check.

  • The hidden tests run with Vitest against your branch in a clean sandbox. They feed the client messages out of arrival order and simulate a dropped connection, so a fix that assumes messages arrive in order won't pass.
  • An AI teammate reviews the diff in the PR thread and can request changes. That review is feedback; the tests decide pass or fail.
  • If a check fails, the test output is on the PR. Push another commit and it runs again.
  • Shipped tickets and tracked hours go on a certificate with a public link for your résumé or LinkedIn.
See exactly how the grading pipeline works →
Who it's for

Who the realtime track is for

Pulse assumes you know TypeScript and async code. It tests whether you can fix ordering and reconnect bugs in an app you didn't write.

Backend and full-stack devs who have only ever worked on request and response CRUD.

People who have used WebSockets or Socket.io in a tutorial and never had to debug them.

Anyone preparing for interviews who would rather talk about a reconnect data-loss bug than a chat app clone.

Juniors who want to see what a "request changes" review feels like before it happens at work.

Not for: people new to TypeScript or async programming. Pulse is about debugging an existing realtime app, so learn those first.

FAQ

Questions about the realtime track

What do I need installed?

Node.js 24 and npm if you work locally. Every Pulse repo also opens in GitHub Codespaces.

Who reviews my pull request?

An AI teammate reviews the diff in the PR thread and can ask for changes. Whether the fix is correct is decided by the hidden test suite.

How do the tests check for ordering bugs?

They hand the client messages out of arrival order, and simulate a reconnect where the server reports what was missed. With the bugs in place, the order or the counts come out wrong.

What happens if the tests fail?

The failing test output is on the pull request. Push a new commit and the check runs again.

Can I put it on my résumé?

Yes. Finishing the sprint gives you a certificate with the stack, the tickets you shipped and your tracked hours, behind a public link.

Does it cost anything?

It's free during the beta.

Take RT-613 and stop losing messages on reconnect.