Design intent
I built this system to serve early-stage founders assembling a first product and a first engineering team. That situation has a specific shape. There is no internal recruiting function, no HR, usually no one who has hired engineers at volume before, and a roadmap that cannot wait two quarters for a search to conclude. The founder is frequently also the hiring manager, the product manager, and the person who will onboard whoever we place.
Two constraints follow from that context, and between them they determine nearly every design decision below. I state them first because the rest of the document is unreadable without them. A reader who skips to the pipeline in section 5 will see a process that looks needlessly expensive, and the reason it is worth the expense is entirely in sections 2 and 3.
Constraint one: VamosWatu does not make the hiring decision
The customer always decides. Always.
This sounds like a limitation and functions as the organizing principle of the system. Because we do not choose, we are not running a pipeline that identifies a winner. We are running a pipeline whose deliverable is a choice set: four to six candidates, any one of whom we would be glad to see selected, handed to a founder who will pick one and decline the rest.
I designed it this way deliberately, and it changes what quality means at every upstream stage. A process built to surface the single best candidate can tolerate a wide funnel and one sharp judgment at the end. A process built to deliver a defensible choice set cannot, because every candidate who reaches the founder is one we have already staked our judgment on. If two of the six are filler, the founder finds out in the first ten minutes of the first interview, and the credibility of the other four goes with them.
So the internal bar is not "could this person do the job." It is "would we be comfortable if the founder picked this one over the other five."
The second consequence is that rejection is structural rather than exceptional. We advance four to six people per role and exactly one is hired. Roughly eighty percent of the candidates we vouch for do not get the job, through no failure of vetting. There is no way around this and we have stopped looking for one. What we control is that everyone who reached the final round was genuinely in contention.
Constraint two: the lean team
We are paid per placement, and my standing advice to every customer is to hire fewer people.
The Lean Team position is not a service line we added. It is what I argue for in the first strategic conversation with a founder and keep arguing for afterward: work out the smallest team that can actually deliver the product roadmap, then hire exactly that. Not the number the round permits. Not the number the board expects. The number the work requires.
The commercial conflict is obvious and worth stating plainly rather than leaving a reader to find it. Advising a founder to hire four engineers instead of six costs us two placements and the multi-year revenue attached to them. Nothing in our contracts prevents me from giving the opposite advice. A reader should weigh that when reading everything below.
I hold the position for two reasons.
Selling volume would falsify our own thesis. We tell founders that one engineer with the right mindset and tooling produces what a team of ten used to. If that is true, selling ten of them is incoherent. A talent partner whose advice scales with its invoice is not making an argument, it is running a quota.
And oversold teams do not survive. A founder who hires six when four would do discovers it within a year, cuts back, and remembers who encouraged the overhire. A team sized to the work ships, keeps its people, and returns when the roadmap genuinely requires more. Every customer we have expanded with started small.
This is also why the rest of this document looks the way it does. A placement business optimizing for volume builds a bench, keeps candidates warm, and maximizes throughput per recruiter. We do the opposite: no bench, a fresh search against each requisition, full re-vetting of returning candidates, and a ten stage process that turns 50 to 250 applicants into four to six finalists. That is expensive per hire and only rational if each individual hire matters enormously. Under a lean team, each one does. The rigor described below is downstream of the philosophy described here.
Sourcing model
No bench. Every search begins from a specific customer requisition, which means we are never finding work for a person. We are finding a person for work that already exists and has a defined shape.
We maintain a directory of over one thousand engineers, all in Nairobi, at every stage of engagement: sourced but never contacted, contacted but never interviewed, interviewed, vetted, placed. Before opening a search we check the directory first. This is not a bench in disguise. Nobody in it is waiting on us, nobody is paid to be available, and prior vetting does not carry forward.
Returning candidates are re-vetted from the start. Someone we vetted thoroughly eight months ago goes through the full process again for a new opportunity. Fit is not a property of the candidate. It is a property of the pairing. A different founder, stack, team temperament, and company stage produce a different question, and an answer that was right for the last one carries no information about this one. The cost is real: we redo work, including on people who have already proven themselves. We accept it because the alternative is a stock of pre-approved candidates that quietly becomes the thing we sell instead of the thing the customer needs.
Channels, in order of both volume and quality, which happen to be the same order:
Direct outreach by the talent acquisition team is first on both counts and is the channel the model depends on. It means analyzing the Nairobi market for a specific role and hunting the people who fit it, most of whom are employed, are not looking, and have never heard of us. It is slow, does not scale on its own, and produces the strongest candidates we see.
Warm referrals from engineers we have already placed come second and carry an implicit vetting signal we take seriously, because a placed engineer recommending someone is staking their own standing on it.
Inbound from organic employer branding is third. Real volume, heaviest filtering required.
University partnerships and private engineering academy partnerships are fourth and fifth. These matter more for pipeline development over time than for filling any given requisition today.
Top of funnel runs 50 to 250 candidates depending on the role, with seniority and stack specificity moving the number considerably. We do not optimize it upward. Volume is an input cost, not an achievement.
The pipeline
Ten stages.
Application
The candidate reads the job description, answers a set of supporting questions, and where relevant lists artifacts. Nobody advances without completing it. The supporting questions carry real weight, because a CV describes what someone has been paid to do and the questions get at what they choose to do.
Automated application review
A calibrated agent scans every application against a rule set covering hard skills, soft skills, and stated experience, with both static and dynamic rules. It looks for reasons to qualify and reasons to disqualify, and returns a score.
Human application review
A talent acquisition manager or recruiter reviews the same applications, looking specifically for what the agent got wrong in both directions. This stage exists because I added it after watching what happens without it. See section 7.
AI technical interview
Candidates scoring 90 percent or above across stages 2 and 3 are invited to a technical interview with a calibrated agent. Standard length is 60 minutes. With live coding it runs 75 to 90 minutes.
Human review of the AI interview
The recruiter reviews the full record: recording, transcript, hard skill report, soft skill report, and overall ranking. No candidate advances or is rejected on an agent score alone.
Human culture interview
Candidates scoring 90 percent or above at stage 5 sit for a 30 to 60 minute conversation with the recruiter. The technical question is largely settled by this point. This one is about the pairing.
Choice set selection
The recruiter reviews each culture interview against notes and the placement requirements and selects the four to six candidates who go to the customer. This is the last point at which VamosWatu exercises judgment, and it is the stage the entire system exists to serve.
Customer interview
The customer interviews each finalist for 30 to 60 minutes. Founders probe mostly for working style and culture. Technical founders and CTOs, a large share of our customers, usually probe technical depth as well.
Customer selection
The customer reviews the interviews, asks questions, discusses internally and with the recruiter, and names the hire.
Offer and contract
The recruiter presents the offer and contract with a start date, onboarding process, and timeline.
Threshold note. Where too few candidates clear 90 percent at stages 3 or 5, we extend invitations to those at 80 percent and above. This is the bar bending under supply pressure, which is exactly what a bar is supposed to resist. We treat it as a compromise rather than as a second tier of the standard, and it is the operating decision I am least comfortable with.
Pairing note. Stages 2 and 3 form one unit, as do 4 and 5. In both cases an automated pass is wrapped in a human pass before anything is decided. That pattern is the single most important structural feature of the pipeline.
The 10x standard
The bar
The archetype we hire against is the 10x Person: output, curiosity, and orchestration. Stating a bar is easy. Testing it is where a process either works or does not.
Output
The most straightforward of the three, carried mostly by the technical interview. Ship velocity over years of experience. The signal we watch hardest for is the absence of accountability for one's own code, described in section 7.
Tested via
Technical interview
Curiosity
People expect this to be the hard one to test. In practice it is difficult to fake for an hour and easy to probe. Asking what tools, languages, or frameworks someone has picked up recently requires a genuine answer, because a fabricated one collapses on the second question. The stronger signal runs the other direction. A candidate interviewing at a startup they might join should want to know things about it. No questions, consistently, means no curiosity. That is not decisive alone, and across three interviews it becomes so.
Tested via
Three interviews
Orchestration
The distinction we care about is between an engineer who drives AI and one who is driven by it, and the difficulty is that the artifact can look identical either way. Three things separate them. Slop, as above. Processing: someone who cannot explain their reasoning in conversation almost certainly cannot direct a model either, because the instruction is the reasoning. And a direct test, which is to ask the candidate to write a three to six sentence instruction, live, and watch how they formulate it. It takes two minutes and it is the most efficient signal in the process.
Tested via
Live 2-minute test
Hard disqualifiers. Any sign of fraud. Any indication of taking intellectual property from a previous employer. And running a company on the side. The last needs explaining, since it sounds like penalizing ambition. It is not. We place people into full-time careers on a multi-year horizon, and someone building their own company alongside the work has a second call on their attention that eventually wins. Intrapreneurs, people who build inside the thing they have joined, are exactly who we want. Entrepreneurs are people I like and cannot place.
Automation, checked
Human review as a control on automation
We use AI at two stages: application review and the technical interview. We have run several systems, moved from Micro1 to Homans, and evaluated others alongside them.
One rule emerged and now governs both: AI never advances and never rejects on its own. Every automated stage is followed by a human stage whose explicit job is to find what the automation got wrong.
Stage 3 exists because of a specific discovery. The agent makes mistakes in both directions, and the mistakes are not random. It over-rewards well-structured CVs and under-rewards poorly written ones, which means it is partly measuring document quality rather than engineering ability. In most hiring populations that correlation is weak. In ours it is weaker still, because our strongest candidates arrive through direct outreach rather than applications and have never needed a competitive CV. An unchecked automated top of funnel would systematically remove the exact candidates the sourcing model depends on. That is not a tuning problem. It is a selection bias built into the instrument, and the correction has to be structural.
The technical interview is a live conversation plus live coding with a calibrated agentic interviewer, with a take-home task in occasional special cases. The primary negative signal is AI slop: generated code the candidate cannot account for. It surfaces reliably by asking someone to explain a decision they did not make.
If you are a candidate
Practical expectations, since this document is also for engineers.
You will be assessed four times: by an agent on your application, by a recruiter on the same application, by an agent in a technical interview, and by a recruiter in a culture conversation. Then, if you reach the choice set, by the customer. No automated score alone ends your candidacy, which is the reason stages 3 and 5 exist.
Before your AI interview we will contact you with practical guidance on the format. This is not coaching on content and gives nobody an advantage on substance. It exists because we have watched capable engineers score badly for reasons unrelated to engineering: an unstable connection, a noisy room, multiple screens, tab switching, mumbling, answers that stop three sentences short. Removing avoidable noise from a measurement is part of running the instrument correctly, and I introduced it after seeing good candidates lose to bad audio.
You are one of four to six finalists. Most finalists are not selected, and that is a property of the format rather than a verdict on you. Being in the choice set means we would have been glad to see you chosen.
The hardest part of the process is the wait after your customer interview, and section 9 is honest about why.
Known failure modes
The entrepreneur problem is our most common post-placement failure. Someone passes vetting, starts strong, then picks up a project of their own, and the divided attention shows in the work weeks before anyone names the cause. We screen for it at stage 6 and do not catch all of it, partly because the project sometimes does not exist yet at interview. This is the failure mode we would most like a better instrument for and currently do not have.
Outside offers. Engineers we place become more visible and more valuable, and other people notice. Some of this is ordinary market behavior no process prevents.
Working-relationship mismatch. Sometimes a placement ends because the founder and the engineer do not work well together, with no clear failure on either side. Our stage 6 and stage 7 judgment is aimed squarely at predicting this and it is not solved.
The customer decision stage is the weakest point in the system. Not because the customer decides, which is correct, but because our process ends and the clock does not. Once the choice set goes to the founder, the timeline leaves our hands. Decisions land in a day or stall for weeks. Four to six strong engineers, all of whom cleared a demanding process, wait with nothing definitive we can tell them, because we do not know either. We cannot congratulate anyone and we cannot release anyone. This is where we most often lose good candidates to other opportunities, and it is the part of the experience I am least satisfied with.
What the results look like
We cannot directly measure whether a choice set was good. The counterfactual is unavailable, because we never learn how the other four or five would have performed. The closest proxy is whether a customer comes back.
A founder who was handed four to six candidates, interviewed all of them, picked one, and then returned to run the whole process again is telling us something a satisfaction survey cannot. Hiring is slow and expensive even when someone else does most of the work. Nobody repeats it out of politeness.
Three customers, each of which started with a single hire and expanded:
Organic certification software that replaces the binder of PDFs, spreadsheets, and emails with one Common OSP-aligned platform for farmers, handlers, and certifiers.
Engineers hired
4
AI relationship intelligence that turns the network a founder already has into reach: remember everyone, reach anyone.
Engineers hired
6
Personalized AI broadcasts built around a fantasy player's own team, matchups, and league.
Full-time · Part-time
1 + 1
Disclosure. I am an angel investor in Orbiter and have advised FantasyCaster.
Three unrelated products. Regulatory compliance software where correctness is the product, a consumer network, and an AI media application. Different stacks, different release cadences, different team temperaments, and three genuinely different definitions of a good engineer. This is the practical case for the re-vetting policy in section 4. An engineer right for a certification platform serving hundreds of audited operations is not automatically right for a consumer product shipping weekly, and treating a prior vet as portable would have produced a worse match at least twice across these three accounts.
Three accounts is a small sample and a selected one. Expansion is consistent with the system working. It is not a measurement of it.
Provenance
I did not set out to become a recruiter. I became one in 2018 because I was building companies and could not build them alone. Hiring was the constraint on everything else, so I learned to do it properly.
Everything since has run on that loop. Through the Kyiv years I founded and ran my own company, and the quality of the engineers I could find determined what it was able to do. I took on advisory work helping other organizations hire technical talent, which is how I learned the problem generalizes and that most companies solve it badly. In 2022 I founded nocode rebels, a development agency I rebranded in 2024, which puts me on both sides of this: I am a customer of my own hiring process and I live with the engineers it selects.
I founded VamosWatu in October 2022. Since then I have placed or managed the placement of 60 software engineers across a range of engagement models, first out of Ukraine and then out of Kenya.
That second part matters more than the first. I built this system for the Ukrainian market. The war made that market untenable, and I rebuilt it in Nairobi: new market analysis, new sourcing channels, no referral network to start from, a physical workspace, and a talent pool I had no history in. The design came across intact. The channels had to be built from zero.
That is the strongest claim I can make about any of it. Not that it works, but that it worked twice, in two countries, one of which I had to leave.
I am based in Austin, Texas.
This system has been running for years and had never existed in a single document until this one. Parts of it are old and parts are recent. The sections describing what we changed, and why, are the ones I would point to first, because a hiring process that has not changed is usually one nobody has been checking.
