Hiring our first engineer: the mass-interview process I built as a non-recruiter

Four months of solo engineering was enough. The codebase was solid, the product was live, and the backlog was growing faster than I could ship. We needed a second engineer. The problem: I had never hired anyone. I had no applicant tracking system, no recruiter, no interview playbook, and no idea what a good hiring process looked like from the employer side. So I built one from scratch in a week, ran thirty candidates through it, and made one hire who turned out to be exactly the right person.

Generate a realistic hiring editorial scene with pull request diff, handwritten notes, laptop on a desk, soft overhead lighting, 16:9, no staged interview smiles, no stock-photo office feel.

What felt like a technical post at the time was usually me learning management in disguise. It also builds on what I learned earlier in “Startup engineering culture when you are the only engineer.” I was figuring out, in public, that your first engineering culture is just the pile of defaults you create when nobody else is in the room yet.

Editorial supporting image for the section "The Pipeline I Built" in the article "Hiring our first engineer: the mass-interview process I built as a non-recruiter". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "Hiring our first engineer: the mass-interview process I built as a non-recruiter". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: slate, amber, off-white paper, low-contrast office shadows. Mood: hungry, hands-on, slightly sleep-deprived, battle-tested before the title felt real. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No staged handshake photos, no smiling meeting stock imagery, no motivational poster energy, no text overlays.

The Pipeline I Built

I wanted a process that was rigorous without being disrespectful of candidates’ time. The whole pipeline from application to offer takes a maximum of ten days and requires no more than five hours of the candidate’s time total.

1. Application review: Resume plus a short form asking “what is the most interesting technical problem you have solved in the last year?” This question filters better than any resume line item. I spent about five minutes per application.
2. Take-home exercise: A small coding task that mirrors our actual codebase. Candidates build a simple payment validation endpoint with TypeScript, PostgreSQL, and basic error handling. Time limit: 3 hours. We provide a starter repo with the database schema and test suite already set up.
3. Pair programming session: 60 minutes. We debug a real production bug together on a shared screen. The bug is from our actual codebase (sanitized of customer data) and is representative of what day-to-day work looks like.
4. Culture conversation: 45 minutes. No whiteboard problems. No algorithm puzzles. A conversation about how they handle ambiguity, what they do when they disagree with a technical decision, and what their ideal working environment looks like.

I deliberately excluded algorithm interviews. We are not building search engines. We are building a fintech product where the hard problems are data integrity, API design, and operational reliability. The interview should test the skills the job actually requires.

The Take-Home That Actually Works

Most take-home exercises fail because they are either too trivial to differentiate candidates or too ambitious to complete in a reasonable time. I spent two full days designing ours to thread the needle.

• Scope: Build a single API endpoint that validates a payment request against a set of business rules (amount limits, currency restrictions, duplicate detection). The starter repo includes the database schema, seed data, and a test suite with 8 failing tests.
• Success criteria: Make all 8 tests pass. The tests are the spec. Candidates do not need to guess what we want.
• What I evaluate: Code organization, error handling approach, SQL query quality, and whether they read the existing codebase before writing new code. I do not care about code style or library choices.
• What I explicitly do not evaluate: How fast they finish. Whether they add tests beyond the 8 provided. Whether they use any particular pattern or framework.

Of the 30 candidates we put through the take-home, 22 submitted solutions. Of those, 14 passed all 8 tests. The differentiation was in the code quality of the passing solutions: how they handled edge cases the tests did not cover, how they structured error responses, and whether the SQL queries would perform well at scale.

The Pair Programming Session

The pair programming session is the highest-signal stage. I share my screen showing a real production bug (a reconciliation mismatch caused by a timezone handling error) and we debug it together. I am looking for three things.

• How they investigate: Do they read the error message carefully? Do they form a hypothesis before changing code? Do they check the database state?
• How they communicate: Do they think out loud? Do they ask clarifying questions? Do they explain their reasoning?
• How they handle being stuck: Everyone gets stuck. Do they change strategy? Do they ask for a hint productively? Do they stay calm?

I give light hints if the candidate is going in the right direction and heavier hints if they are stuck for more than ten minutes. The session is collaborative, not adversarial. I want to see what it is like to work with this person, not watch them suffer.

---

What I Learned

Hiring as a non-recruiter taught me four things that I will carry into every future hire.

• The “interesting problem” question on the application form was the single best filter. Candidates who could articulate a real technical challenge clearly were almost always strong in the technical stages.
• Take-home exercises with failing tests work because they remove ambiguity. The candidate knows exactly what success looks like. No one submitted a solution and said “I was not sure what you wanted.”
• Pair programming reveals collaboration skills that take-homes cannot. Two candidates with identical take-home quality had wildly different pair programming sessions. One talked through every thought, one went silent for ten minutes at a time.
• Culture conversations should feel like a real conversation, not an interview. The best signal came from unexpected tangents, not scripted questions.

We made the offer to a candidate who was not the fastest on the take-home but was the best communicator in the pair programming session. Three months in, that decision has proven right. Technical skills can be developed. Communication patterns are much harder to change.

Create an editorial desk scene about engineering hiring judgment: scorecards, code review notes, subtle authority, 1:1, natural shadows, no HR stock-photo look.

That was the pattern of my first months at FinanceOps: I did not have management scar tissue yet, so I earned trust by making technical decisions that stayed boring under pressure. The same bias toward strict defaults still shows up in lifeos and bisen-apps today.

If you are a solo founder hiring your first engineer, invest the time in designing a process that tests real work, not interview performance. The person who aces your algorithm puzzle might not be the person who thrives in the ambiguity of a startup.