Sample evaluation · Fictional candidate
See what’s behind the hiring decision.
One fictional case: the work, the checks, and the next question.
Evidence report
Fictional sample01 · Candidate work
Inspect it. Then test it.
Compare the AI proposal with the candidate’s revision, then run the same checks on both.
Executable sample
Compare the two approaches
AI proposal
key = event.id
store[key] = deliveryAn event-only key can merge unrelated deliveries from different tenants.
Candidate revision
key = JSON.stringify([tenantId, event.id])
store[key] = deliveryA structured tenant-and-event key separates records. It does not solve receiver-side replay on its own.
Run both versions against the same checks.
These checks exercise an in-memory delivery ledger, not a running webhook service. They do not establish authorization, concurrency safety, or exactly-once delivery.
Not tested here: receiver acknowledgement, concurrency behavior, or security authorization. These results are not a hiring score.
02 · Interviewer judgment
Passing checks are not the hiring decision.
The local ledger can pass while a receiver still processes a delivery twice. The next question comes from that gap, not a generic interview script.
Interviewer review
Production scorecard component · fictional example ratings
Interviewer AI scorecard
Evidence is insufficient before human validation. The small fixture supports ledger deduplication and tenant isolation; receiver duplicate processing and behavior under load remain unverified.
Which fixture check failed before the key change, and why does it pass now?
The destination times out after accepting the event. What happens next?
Example ratings, not a real hiring recommendation. The scorecard is decision support; a human interviewer must evaluate the missing evidence.
03 · Work trail
Follow the change, not just the final answer.
Authored example sequence, not a recording of a real session.
Proposal
An event-only key can merge unrelated deliveries from different tenants.
Revision
A structured tenant-and-event key separates records. It does not solve receiver-side replay on its own.
Next probe
Local checks support the key change. Receiver-side replay and concurrency still need direct verification.
04 · Candidate closeout
Useful feedback. A clear privacy boundary.
Scores, rankings, hiring outcomes, integrity signals, and reviewer notes stay private to the hiring team. This is the production candidate-preview component, filled with fictional, score-free coaching.
Human approval is required before real feedback is shared. Nothing is sent from this sample.
Candidate feedback
Fictional feedback example: what the work demonstrated and a useful next step.
You changed the delivery key after comparing same-ID events from two tenants.
A unique local record does not establish what a remote receiver did after a timeout.
Try next: Write a receiver-accepts-but-acknowledgement-is-lost test and explain a safe retry protocol.
Simulate acceptance followed by a timeout. Compare retry behavior with and without a receiver idempotency key.
Why it helps: It separates a passing local check from a delivery guarantee.
This is an authored demonstration, not a real candidate result. No real candidate data was analyzed.
- Fictional decision sketch
- The bounded delivery-ledger example
- Identity, personality, emotion, or accent
- Production reliability or authorization
- Unobserved candidate skills
What did this evidence establish, and what should you test next?
On signal
See what this would look like for your role.
Bring an open role. Walk through the task, report, and follow-up with us.