I am not the best person to have given hiring advice 10 years ago. I would have told you things that sounded reasonable and were mostly wrong. Things I had read in the same places everyone reads about hiring, or heard from other founders who had read the same places, or absorbed from the startup […]
I am not the best person to have given hiring advice 10 years ago. I would have told you things that sounded reasonable and were mostly wrong. Things I had read in the same places everyone reads about hiring, or heard from other founders who had read the same places, or absorbed from the startup mythology that circulates about what good technical hiring looks like.
I would have told you to look for engineers who are passionate about your mission. I would have told you that culture fit is something you feel in a room. I would have told you that a rigorous hiring process is a sign of respect for the role. All of those things have some truth in them, and all of them led me to spend the first eight months of trying to build an engineering team making expensive, avoidable mistakes.
This is the story of those mistakes, what I learned from them, and what it actually took to go from a product that was held together by two generalist developers and a lot of goodwill, to a functioning engineering team of seven people who were genuinely excited to be there. I am telling it because I have not found many honest versions of this story, and because if you are a founder trying to hire technical talent right now, you probably need the honest version.
When I started hiring technical talent seriously, I treated every engineering role the same way: write a job description, post it on LinkedIn, receive applications, screen, interview, offer. Simple enough in theory. In practice, the results were consistently poor, and I spent months assuming the problem was the market — that good engineers simply were not interested in a company at our stage.
The mistake I was making was treating “engineer” as a single category. I needed a backend developer who could own our API layer. I needed a frontend developer who could work closely with our designer. I needed a data engineer who understood our analytics pipeline. These were three completely different profiles with different motivations, different evaluation criteria, and different channels for finding them. Running them all through the same generic process was like using the same recipe for three completely different dishes and wondering why none of them came out right.
The first thing that changed, when things started to change, was that I stopped thinking about hiring technical talent in general and started thinking about each role specifically. What exactly does this person do? What is their career background likely to look like? Where do they spend time online? What would make this role interesting to them specifically? What would make it not worth their time? Answering those questions for each role separately took more time upfront but cut weeks off every subsequent search.
I believed, and I said out loud in early interviews, that I was looking for engineers who were passionate about what we were building. What I meant by this was reasonable enough — I wanted people who cared about the work, not just about the payslip. What I actually communicated was something else: that compensation and career development were secondary considerations, that the mission should be sufficient motivation, and that anyone primarily focused on the practical terms of the role was not the kind of person I wanted.
This filtered for candidates who were either early in their careers and had not yet learned to advocate for themselves, or who were so keen to join a startup that they would accept below-market terms. Neither of these was what I actually needed. The engineers I needed — senior, experienced, capable of working with significant autonomy — were professionals who cared about interesting work and also cared about fair compensation, good processes, and the quality of the people they would be working with. Treating those considerations as red flags meant I was filtering out exactly the people I should have been trying to attract.
I stopped talking about passion in interviews. I started talking about what made the technical challenge genuinely interesting, what the specific problem was, why it was hard, what tools and approaches we had considered and rejected. I started asking what candidates were looking for rather than assuming the mission would be enough. The quality of the conversations changed almost immediately.
My first hiring process for a senior backend engineer had seven stages. Screening call, take-home technical exercise, technical interview with me, technical interview with our lead developer, a pair programming session, a culture conversation with the founding team, and a final call to discuss the offer. I designed it this way because I was uncertain — uncertain about my ability to assess technical skill accurately, uncertain about whether someone would fit, uncertain about what I was even looking for.
More stages felt like more certainty. More information felt like a safer decision. What it actually was, from the candidate’s perspective, was a month of unpaid time investment in a process that had no guaranteed outcome. Three of the five candidates I ran through it dropped out before stage four. One said so explicitly: he had accepted another offer and apologised for not being able to complete the process.
The process I had built was designed for my psychological comfort, not for the efficient assessment of candidates. Replacing it required admitting that most of those seven stages were generating noise rather than signal, and that the actual information I needed to make a confident decision could be gathered in three focused conversations rather than seven stretched-out ones.
At month four of trying to build the engineering team, I had hired two people. One was working out. One was not. The searches I had open were going nowhere. I was spending forty percent of my time on hiring technical talent and producing very little from it.
A conversation with another founder in our portfolio changed my approach. She had built a technical team of twelve in eight months. I asked her what the difference was. She said: “I treated it like a product problem. I defined the outcome I needed, I studied the people I was trying to reach, I designed a process that worked for them, not just for me, and I measured what was working and changed what was not.”
That framing reoriented everything. A product problem. You start with the user — in this case, the candidate — and work backwards. What does the candidate experience need to feel like for the right person to say yes? What information do you need to make a confident decision, and what is the most efficient way to gather it? What is the bottleneck in the current process, and what happens if you remove it?
Over the next two weeks, I redesigned the process completely. Three stages instead of seven. A job description built around the problem rather than the profile. Active sourcing through niche communities rather than passive job board posting. A technical conversation structured around a real scenario from our codebase rather than an abstract exercise. A verbal offer within twenty-four hours of a final decision.
In the ninety days following the redesign, we hired five engineers. All five are still with the company. All five had strong options elsewhere when they chose us.
Some of what made this possible was the process redesign. Some of it was working with a specialist recruitment partner — Tallenxis — who could source within niche technical communities faster than I could, and who had credibility with candidates that an early-stage founder approaching cold does not automatically have.
Some of it was me getting better at articulating what made the technical challenge genuinely interesting, what the company was really trying to build, and what the experience of working here was actually like rather than what I wished it was like. Honesty turned out to be a better recruiting strategy than enthusiasm.
Some of it was realising that I did not need engineers who were passionate about the mission. I needed engineers who were good at their craft, genuinely interested in the specific technical problems we were solving, and looking for an environment where they would have real ownership and real impact. That is a much more achievable target than passion. And it is a target you can assess for.
Define each role as specifically as you can before you post it. Not a list of technologies — a description of the problem, the constraints, the context, and what success looks like in six months.
Design the process for the candidate you want, not for your own confidence. Three good conversations are better than seven thin ones. And moving faster is not a sign of recklessness — it is a sign that you understand the market.
Be honest in every conversation. About the stage you are at. About the problems you have not solved yet. About the compensation. About what the day-to-day experience is actually like. The engineers you want to hire have excellent instincts for when a founder is performing rather than communicating. Performing loses them. Honesty builds trust.
Get help earlier than you think you need it. The time I spent trying to run every search myself, in a market where I had limited credibility and limited reach, was some of the most expensive time I spent in those eight months. The time I spent working with people who actually knew how to source and place technical talent produced ten times the output in a third of the time.
Hiring technical talent is a skill. Like any skill, it gets better with feedback and practice. But it also gets better faster when you are learning from people who have done it well many times rather than trying to figure it out from first principles while running a company at the same time.