Bloom

The problem

Every candidate now uses AI, so every candidate's output looks about the same. The thing that separates a strong engineer from a weak one has moved: it is no longer whether they can produce the artefact, it is whether they direct the model well, check what it hands back, and throw away the parts that are wrong. None of that is visible in the finished deliverable.

The obvious response, "give them a task and let them use AI", does not work either. Models are non-deterministic, so the same task run twice gives different output and no defensible way to say one person did better than another. Take-home projects have the opposite problem: they take days, cost senior time to grade, and can be handed to a friend.

What I built

Bloom is a timeboxed work simulation with deterministic scoring. A candidate gets a realistic task with a fixed brief and a fixed dataset, works on it for 15 to 90 minutes with AI, and submits. The score is computed by a pure function over the submission, not by a model judging it.

The candidate can work three ways: in a hosted chat, through an agent, or in their own AI tool routed through a gateway. The mode changes the environment, not the scoring.

The trick that makes it work

Every task is authored so that the model's natural failure modes fire. Dirty rows in the data. A contradiction between two source documents. A specification detail the obvious prompt drops. A number the model will confidently make up.

That gives the whole thing a testable property, and the property is what the build is gated on:

• A naive run has to fail. Handing the brief straight to a model has to score under 40 out of 100 on every task, checked per calibration model in CI. On the three shipped tasks the models score 13, 26 and 24 with Gemini 3.5 Flash, and 18, 23 and 14 with Gemini 3.1 Pro.
• Informed work has to pass. The same tasks, solved by someone who caught the traps, have to clear 85 out of 100.
• The score has to be reproducible. Re-running the scorer over a stored session has to produce a byte-identical report. That is a determinism check in the test suite, not a promise.

If a new task cannot satisfy all three, it does not ship. Calibration is a gate, not a guideline.

What the report says

The output is not one number. It separates the outcome (did the deliverable come out right), the catches (which planted failures they noticed and fixed), and behaviour pulled from the full session transcript: how they prompted, how much they verified, where they accepted output unchecked. The transcript is the evidence, so every claim in the report can be traced back to a moment in the session.

Where it stands

The automated gates pass. What is still open is the part that no test can answer: whether real candidates of mixed seniority spread across a wide enough score range, and whether recruiters would actually run this instead of a take-home. Those need humans, and they are the next milestone rather than a finished result.