Kevin, in his own words
Two minutes, recorded for this search. He is the acting CTO and only engineer on a live US product, and he explains what it does without reaching for jargon.
Where Kevin is strong
Six dimensions we scored every candidate on. The dashed outline is what we judged this particular role to need. Everything further down the page is the evidence behind these positions.
He has no travel industry background, which is the low point on the right. For this role that mattered less than the two lines at the top, and for a different role it might matter more.
What the exercise actually tested
Every candidate got the same challenge, built for this client and this role and never used before. A genuine 26 line supplier rate pack, a real operational quotation, and a supplier email correcting some of the prices. Produce costings a system could bill against. Seven problems were hidden in the documents on purpose, and the answer key was written before any submission was opened.
Then we changed the inputs without telling him
Grading a submission tells you what somebody built. Breaking it tells you what they built it out of. After his work was graded we made five changes to the source documents that he was never warned about, and ran his pipeline again on each one.
- Trip dates moved a year forwardRefused to reuse the expired prices and raised every affected line.
- A booked service deletedIt disappeared from the total. Nothing was billed for it silently.
- A service added with no matching priceFlagged, left unpriced, and kept out of the total.
- A room renamed so the price no longer matchedKept on the quotation, left unpriced, and raised for review.
- Two figures corrupted inside his own outputHis integrity checker caught both.
Five out of five. This is the part of our process that separates people, and it is only possible because we clone the repository and run it. One candidate in this search had safeguards that looked right on the page and failed the moment the code was actually executed.
#1 The technical challengeHighest-scoring submission · five finalists Read moreSee less
The short version. Fifteen of sixteen figures correct, and the sixteenth is a deliberate refusal he can defend. It survived every test we threw at it, and he tells you himself where his own answer key was wrong.
What it got right
- Fifteen of sixteen figures correct, including both deliberate traps: the supplier email that quietly replaces two hotel rates, and the tour priced per vehicle when it reads as though it is priced per person.
- The sixteenth figure is a deliberate refusal. The rate pack carries no matching rate for a Johannesburg meet and greet. He declined to borrow the Cape Town price, refused to quote the line, and raised it as blocking. That reading is arguably stricter than our answer key.
- All seven hidden problems were caught, plus six more he found on his own, split into seven that stop a quotation being sent and fourteen that only need confirming.
- Every figure carries a quote from the source document. We checked all twenty-six by hand against the original PDFs. All twenty-six matched word for word, so anyone can search the source and find the line.
- His output says when a quotation is not ready. It emits a plain not-sendable flag with the reason attached. Nobody else built anything like it.
- He catches the chronology trap automatically. The rate pack was compiled two days after the email that overrides it, so ordinary date order points the wrong way. His system spots the contradiction and says so in the review note. It does not quietly pick one.
- He works out quantities from the price. The quotation prints a conservation levy twice for a party of five. His system notices that the printed count disagrees with what the rate implies and flags it, with no rule about levies anywhere in the code. The same logic would catch the equivalent error from a supplier nobody has seen before.
- The model is never allowed to produce a number. It transcribes documents into typed records and proposes which rate belongs to which service. Every quantity, calculation, confidence level and total is plain TypeScript. That is the single most important architectural decision in a system like this and he made it unprompted.
What to weigh
- No formal test suite. The integrity checker is strong and we verified it works, and it is still one safety layer where the very best submissions have two.
- Twenty-one review items is a lot for a non-technical reviewer to work through in one sitting.
- Prices with no stated expiry date are never checked for expiry.
- He spent roughly three hours against a two hour brief, and says so on camera.
On the walkthrough
Six minutes against a five minute ask, the closest of anyone. Twice he volunteers something against himself: that his own hand-written answer key was wrong and the AI corrected him, and that early on the model kept returning tidy output that was quietly missing most of the services, which he fixed by forcing it to commit to a count before listing and refusing partial results.
Background and fit
Technical ability is part of the decision. We also looked at Kevin’s experience, working style and fit for this particular role. Here is what we found and what we would explore further.
Stack
TypeScript, end to end. He wrote the exercise in TypeScript on Bun with the Vercel AI SDK, and said plainly it was because the client product is TypeScript end to end. No framework bloat: no LangChain, no database, no UI layer he did not need.
Industry
No travel. His domain is US bail bond lending, which is regulated, document-heavy, and ends in money moving. Different words, same shape of problem.
Early stage
Sixteen years, currently a team of one. He is the acting CTO and only engineer on a live multi-tenant US product. There is nothing about a small, unfinished codebase that would surprise him.
Leadership
Owns technical direction alone. He sets the architecture and answers for it. He is not currently leading other engineers, so a role that needs him to manage a team is a different conversation.
Judgement under constraint
Asked where a human sits in the chain, he said his system scores and stops, because acting on some of those grounds would be illegal. He got to approve-before-money-moves through a real constraint, which is a harder place to arrive at it from than a design preference.
Working alone
The honest risk. Years as a sole engineer means years without code review. He compensates with self-checking habits, and it is the thing to probe on a call.
9 Background and fit in full9/10 · he has built this shape of system before, commercially Read moreSee less
The short version. He has built the same shape of system before, in an industry where a wrong figure gets noticed, and he runs it single-handed today.
What he has built
He is the engineer behind a product used by bail bond agencies in Utah, working as its acting CTO. Someone calls, an AI answers, takes the details, looks up the case, scores the application and produces the paperwork. A person approves it, and only then is a payment link sent.
Why that maps onto a costing problem
There are around sixteen thousand of those agencies in the US and each one has its own forms. His system reads a document it has never seen, works out what each field is for, and places the case information into it. That is the same shape as reading a supplier rate sheet you did not design. The one thing it stopped short of was pulling a price out of one, which is exactly what the exercise settled.
How he checks himself
For the exercise he wrote an answer key by hand from the source documents first, then had his own program grade itself against it. When the two disagreed on a line he investigated, found that his key was wrong, and changed the key. That is the habit you want in whoever owns the numbers, and it is not a habit you can claim in an interview.
What we checked
- His CV and his LinkedIn were read against each other and against the job description. The sixteen years, the current role and the level of ownership are consistent across both records.
- His challenge repository was cloned, installed and run on our own machine.
- All twenty-six figures in his output were checked by hand against the original supplier PDFs.
- Five changes were made to his inputs without warning, and the pipeline was run again on each.
- He turned the exercise around the same night it was sent, and he is still available with no notice period.
The short version
What stood out
- The most accurate of the five submissions. Every figure correct but one, and he declined to price that one on purpose because the rate pack carries no matching rate for it.
- Every number traces back to a line in a source document, word for word, so a non-technical reviewer can check any figure without asking an engineer.
- His system says when a quotation is not ready to send, in plain words, with the reason attached.
- It held up when we changed the inputs without warning, on all five tests.
- He tells you where he was wrong. On camera he volunteers that his own answer key was wrong and the AI corrected him.
- Already writes the client stack. TypeScript end to end, by choice and for a stated reason.
What to weigh
- No formal test suite. He built an integrity checker instead. It caught both of the figures we deliberately corrupted in his output, so it works, and it is still one safety layer where the strongest submissions have two.
- Twenty-one review items is more than a non-technical reviewer will comfortably work through in one sitting, even sorted into blocking and confirm.
- Prices with no stated expiry date are never checked for expiry. Narrow, and worth raising on a call.
- No travel industry experience. He would be learning the vocabulary on the job.
- He has worked without code review for years. Years as a sole engineer means years with nobody checking his work, and he reads from prepared notes on camera.
Hire Kevin, or someone vetted like this
Interested in working with Kevin? Contact him directly. For this featured profile, LeanTeams charges no recruitment fee to you or to Kevin if you hire him directly. If you are hiring for a different role, tell us what the work requires and we will discuss the search, assessment and fees with you.