KadraPractice

Practice real realtime chat engineering on a live WebSocket codebase

Pulse is a real, running realtime chat app with three seeded bugs in its message-ordering, unread-count, and reconnect 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 Pulse's messaging layer

This isn't a lesson plan. You clone Pulse, a working realtime chat app with channels, a WebSocket message layer, and reconnect handling. 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.

RT-601

Messages render out of order under rapid sends

Messages are appended to the UI in the order their network responses arrive, not in server-authoritative order — so under rapid sends, a later message can resolve first and jump ahead, and optimistic local echoes never reconcile to their eventual server position. Passing requires messages to display in server-authoritative order regardless of response timing, with optimistic echoes reconciling cleanly and no duplicates appearing once they do.

RT-607

Unread count keeps incrementing on a channel you're already viewing

The unread counter bumps on every incoming message, including the channel the user currently has open and focused — the reset logic only fires on the initial channel-switch, not while a message arrives during an active session. Passing requires a focused channel's unread count to stay at zero while background channels still increment normally, verified against the hidden suite's focus-state matrix.

RT-613

Messages sent during a disconnect are silently lost on reconnect

The socket client resumes after a drop by just resubscribing to live events — there's no backfill of anything sent while it was disconnected, so messages from the outage window vanish with no gap indicator. Passing requires the client to backfill from a last-seen cursor with no gaps and no duplicates, and message ordering to hold across the reconnect boundary.

How grading works

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

Every Pulse 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 RT-601, RT-607, or RT-613 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, realtime), 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 realtime track is for

Pulse assumes you already know TypeScript and basic async/event-driven concepts — it's testing whether you can debug concurrency and ordering bugs inside someone else's codebase, not teaching you the language from zero.

Backend and full-stack devs whose portfolio has never included a real concurrency or ordering bug, only CRUD.

Engineers who've used WebSockets or Socket.io in a tutorial but never had to debug message-ordering or reconnect logic under load.

Anyone prepping for interviews who wants to say “I fixed a reconnect data-loss bug” instead of “I built a chat app clone.”

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 async-programming fundamentals — Pulse tests debugging inside an existing realtime codebase, not language basics.

FAQ

Questions engineers actually ask about the realtime 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 chat app, 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 realtime 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 RT-601, RT-607, and RT-613, the same way you'd clear a sprint backlog.

Do I need WebSocket/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. Pulse 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 building chat-app tutorials that never break. Fix a real reconnect bug, in a real PR, reviewed like a real coworker would.