Skip to content

Instantly share code, notes, and snippets.

@743milan
Last active July 20, 2026 07:15
Show Gist options
  • Select an option

  • Save 743milan/91453ae11cffa9165f92cd7c650dbac5 to your computer and use it in GitHub Desktop.

Select an option

Save 743milan/91453ae11cffa9165f92cd7c650dbac5 to your computer and use it in GitHub Desktop.
🏁 RACEMAKE PRODUCT ENGINEER CHALLENGE β€” BASIC

🏁 RACEMAKE PRODUCT ENGINEER CHALLENGE 🏁

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


The situation

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.


The floor (this is the minimum, not the target)

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.


How we read your submission

  • 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.


Submit

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.

//! Excerpt from the native recorder's telemetry export path.
//!
//! The agent captures the game's shared memory into a `CoreTelemetry` struct and
//! streams a compact per-frame record over the wire. This is the encoder for that
//! record β€” the frames in the attached stint come off this export path.
//!
//! You do not need to build or run this. Read it.
use serde::Serialize;
/// Fixed-point scale factors shared across the recorder's encoders.
mod scales {
/// Temperature in Celsius β€” precision: 0.1 Β°C.
pub const TEMPERATURE: f32 = 10.0;
}
/// Live tyre core temperatures, in degrees Celsius (one probe per corner).
#[derive(Debug, Clone, Copy)]
pub struct TyreTempsC {
pub fl: f32,
pub fr: f32,
pub rl: f32,
pub rr: f32,
}
/// Minimal per-frame telemetry the capture loop hands to the encoder.
#[derive(Debug, Clone, Copy)]
pub struct CoreTelemetry {
pub timestamp_ms: u64, // ms since recording started
pub lap_number: i32,
pub position: f32, // normalized lap position, 0.0..1.0
pub speed_kmh: f32,
pub throttle: f32, // 0.0..1.0
pub brake: f32, // 0.0..1.0
pub steering_deg: f32, // steering angle, degrees (negative = left)
pub gear: i8, // -1 = reverse, 0 = neutral, 1..=8 forward
pub rpm: i32,
}
/// A four-wheel block of tyre temperatures as written to the wire.
#[derive(Debug, Clone, Copy, Serialize)]
pub struct WireTyres {
pub fl: i16,
pub fr: i16,
pub rl: i16,
pub rr: i16,
}
/// One frame as serialized into the stint stream.
#[derive(Debug, Clone, Copy, Serialize)]
pub struct WireFrame {
pub ts: u64,
pub lap: i32,
pub pos: f32,
pub spd: f32,
pub thr: f32,
pub brk: f32,
pub str: f32,
pub gear: i8,
pub rpm: i32,
pub tyres: WireTyres,
}
/// Encode one captured frame into its wire form.
pub fn encode_frame(core: &CoreTelemetry, tyres: &TyreTempsC) -> WireFrame {
WireFrame {
ts: core.timestamp_ms,
lap: core.lap_number,
pos: core.position,
spd: core.speed_kmh,
thr: core.throttle,
brk: core.brake,
str: core.steering_deg,
gear: core.gear,
rpm: core.rpm,
tyres: WireTyres {
fl: (tyres.fl * scales::TEMPERATURE) as i16,
fr: (tyres.fr * scales::TEMPERATURE) as i16,
rl: (tyres.rl * scales::TEMPERATURE) as i16,
rr: (tyres.rr * scales::TEMPERATURE) as i16,
},
}
}
@Bimal-25

Bimal-25 commented Jul 2, 2026

Copy link
Copy Markdown

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:

  • I found the recorder scaling issue: tyre temperatures are fixed-point encoded, so JSON tyre values need to be divided by 10 to get Celsius.
  • I treated the stream as untrusted and excluded one impossible frame: lap 2, ts 136186, speed 3987.6 km/h, rpm 63120.
  • I excluded lap 0 because the recording starts mid-lap around pos 0.4.
  • I excluded lap 3 because the recording ends mid-lap and includes idle/coast tail data.
  • I counted laps 1 and 2 as the real racing laps.
  • I used time-weighted metrics because the sample rate is not perfectly stable.

Clean result:

  • Lap 1: 0:58.397
  • Lap 2: 0:58.201

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment