Hiring your first engineer

A pre-seed startup reached out because they were stuck. They’d been trying to hire their first engineer for three months with zero luck. The founder, a non-technical CEO with a strong product vision, had posted a generic “Full Stack Engineer” job description on LinkedIn, gotten 200 applications, and felt completely lost.

Here’s how we turned it around.

The problem

When I sat down with the founder, three things became clear immediately:

1. The job description was a wishlist, not a role. It asked for 5+ years in React, Node.js, Python, AWS, Kubernetes, and “experience scaling to millions of users.” For a pre-seed startup paying below-market? That description had never been filled.
2. The interview was a vibe check. The founder would chat with candidates for an hour and try to “get a feel” for whether they were smart. No structure, no rubric, no signal extraction.
3. They had no idea what “good” looked like. The founder had never managed engineers. They didn’t know what to look for in a code review, a system design conversation, or even a take-home test.

The result was a funnel that looked impressive on paper (200 applicants) but produced zero hires. The candidates who seemed good declined because the process took too long. The ones who were desperate weren’t the ones they wanted.

The fix

I worked with the founder over two weeks to rebuild everything from scratch.

Step 1: Define the role by work, not by technologies

Instead of asking “what tech stack do we need,” we asked “what will this person actually do in months 1, 2, 3, and 6?”

The answer surprised both of us. The first six months were:

• Ship the MVP frontend (React, yes)
• Set up the CI/CD pipeline and monitoring
• Make pragmatic decisions about infrastructure (they didn’t need Kubernetes)
• Work directly with the founder to iterate on product features

This changed the profile from “senior full-stack engineer with DevOps experience” to “solid frontend engineer who can own the full delivery pipeline and isn’t afraid of ambiguity.”

Step 2: Design a process that produces signal

We built a four-stage process:

1. Screening call (15 min) — I did this personally. Pure signal check: can they communicate clearly, do they have agency, are they excited about the problem space?
2. Take-home task (2-3 hours) — A simplified version of a real feature they’d build in the first month. Not a LeetCode problem, not a toy project. Real code they could be proud of.
3. Technical interview (45 min) — I joined this one. We walked through their take-home together: How did they think about the problem? What would they do differently? Could they take feedback and iterate live?
4. Culture fit with founder (30 min) — By this point, the founder only needed to answer one question: “Do I want to work with this person every day?”

Step 3: Close fast

The whole process took one week from application to offer. Speed was a feature. Good candidates have options — a slow process loses them.

The result

The first candidate who went through the new process accepted. They joined two weeks after we started the search.

Here’s what happened in the next 18 months:

• They shipped the MVP in 3 months
• They grew into a team lead as the company scaled to 8 engineers
• The founder promoted them to Head of Engineering
• Churn rate for the team? Zero. Every engineer they later hired went through the same process.

The candidate is still there, leading a team of their own. The founder told me recently: “That hiring process was the best investment we ever made. We didn’t just hire an engineer — we found our first culture carrier.”

What I learned

The biggest mistake early-stage founders make is treating hiring like a transaction instead of a design problem. They optimize for “getting someone in the door” instead of “finding the right fit.”

A structured process doesn’t slow you down. It speeds you up — because you stop wasting time on wrong candidates and start saying yes to the right one with confidence.