Read this once before you touch the keyboard.
We don't hire from CVs. We hire from what you ship. This is a small slice of a real problem we solve every day: turning a raw telemetry stream into something a driver can act on. It's meant to take a strong TypeScript developer about two hours β enough to show us how you think and how you write code, not enough to eat your weekend.
In this pack: this brief, stint.telemetry.json (the data), and
recorder.rs (a piece of the recorder). That's everything.
The data: download stint.telemetry.json here β https://drive.google.com/file/d/1OyuAWU4zNpJocaZUauIZteKxEcoEXg_h/view?usp=sharing
Attached is one stint from a race track β a GT/prototype car, dry. It is the kind of stream our native recorder actually sends: timestamped frames at a not-quite-stable rate, straight off the wire.
We are not telling you which track it is, and we did not annotate it. Real telemetry never arrives labelled. Part of what we're testing is whether you notice what's wrong with it before you compute on top of it. Trust nothing in here until you've looked at it.
You also get a short piece of the recorder itself β in Rust. You don't need to write Rust. You need to be able to read it, because it explains something about the data you'll otherwise get wrong.
Build a small Bun + Hono service in TypeScript that ingests this stream and returns an engineer's read on the stint as JSON. At minimum:
0. Read the recorder. The attached Rust snippet is the code that encodes these frames. One field is not what it looks like in the raw numbers. Work out what, and account for it before you compute anything. Tell us what you found.
1. Clean the stream. Return a defensible view of how many real racing laps are in here and how long each took. You decide what "real" and "clean" mean β and you defend it. We did not mark the junk for you.
2. Read each lap. For every real lap, return a small summary an engineer can act on β lap time, top and average speed, tyre temperatures in real units, and how the throttle and brake were used. You pick the numbers that matter and you justify them.
Deliverable: the Bun + Hono service and its JSON output. This is backend and analysis only β no UI is required or expected.
- Did you treat the data as untrusted and handle what's wrong with it, without us pointing at it?
- Are your numbers defensible β can you tell us why you chose each threshold?
- Does the code read like it belongs in a codebase someone else maintains?
- Did you read the recorder and account for what it told you?
Use any tools you want β AI, docs, whatever you'd use on the job. We do. We care that you understand and can stand behind what you shipped. We will get on a call and walk your code with you. Be able to explain the parts the AI wrote as if they were yours β because if you join, they are.
The floor above is what makes it a pass. What you do past the floor is how we tell a strong engineer from a great one β but don't gold-plate; two focused hours of clean, correct, defensible work beats a sprawling half-finished pile. If, while building this, you see something obvious that the data is begging for and the brief didn't ask for, a sentence noting it is welcome.
Send your code + sample output to weare@racemake.com β Subject: RACEMAKE β Engineer β [Your Name].
If we see the signal, we'll be in touch within 48 hours.
Hi RACEMAKE team,
I completed the Basic challenge and sent the zipped solution + output JSON by email to weare@racemake.com.
A few notes from the implementation:
Clean result:
I will also push the code to GitHub and can share the repository link as a follow-up.
Thanks,
Bimal
+91 96877 69425
bimal.africab@gmail.com
bimal.softwaresolution@gmail.com