All Playbooks
Hiringintermediate

Hiring Your First Engineer

Your first engineering hire shapes the next two years of the company more than almost any product decision. Most founders rush this and pay for it for a long time. This playbook is the hiring loop I recommend: scope the role honestly, source where engineers actually live, design a realistic interview, check references hard, and onboard with a real plan rather than a vague mandate.

90 min7 steps
7

Steps

3

Tools

5

Outcomes

intermediate

Difficulty

Technologies used

ProcessInterviewingOnboarding

The methodology

The phases, in order

Each phase below is something I actually run in a project. The descriptions are how I think about the work, not abstract definitions.

01

Phase

Phase 1 of 7

Define the Role Honestly

First engineers always wear many hats. I write down what the next 12 months actually need: ship a v1, set up infra, talk to customers, do design work. If the honest job description scares you, that is useful information. The job ad should reflect reality, not the aspirational version of the role that does not exist yet.
02

Phase

Phase 2 of 7

Source Where Engineers Live

Senior engineers do not live on job boards. I source through referrals, open-source contributors, conference speakers, and niche communities. Cold outreach works when it is specific and shows that I actually read their work. Generic LinkedIn messages are noise, and good candidates filter them out.
03

Phase

Phase 3 of 7

Design a Realistic Interview Loop

I skip leetcode entirely for senior hires. The loop is: a short intro call, a paid take-home that mirrors the actual work, a technical conversation about the take-home, and a culture-and-judgment conversation. Total candidate time under 8 hours, paid where appropriate. Anything longer signals that I do not respect their time.
04

Phase

Phase 4 of 7

Interview for Judgment, Not Skills

First hires need judgment more than skills. I ask about ambiguous situations from their past, about a time they pushed back on a decision, about a time they were wrong. Specificity in their answers is the signal. See the hiring engineers insight for the full theory.
05

Phase

Phase 5 of 7

Reference Check Hard

Two reference calls of 30 minutes each tell me more than three interview rounds. I ask referees what they wish they had known about the candidate before working together, and what role the candidate is best and worst suited for. Honest references are gold and rare.
06

Phase

Phase 6 of 7

Write a 30-60-90 Plan

Before the offer goes out I write a 30-60-90 day plan: what they will ship, who they will meet, what they will own. Day one starts with a working laptop, accounts created, and a real first task that ships in week one. Pair them with the monitoring and security playbooks for context.
07

Phase

Phase 7 of 7

Run a Two-week Check-in

Two weeks in I run a structured check-in: what is working, what is broken, what they need. The first month is an extended interview from both sides. If something is wrong, fixing it in week three is much cheaper than fixing it in month three. Most founders skip this and regret it.

Results

What You'll Achieve

Expected outcomes from implementing this playbook

A first hire who lasts past 12 months
A clear scoping document and 30-60-90 plan
Faster onboarding with a working day-one
A better candidate experience that pays off in referrals
Want help with a tech founder's workflow? Get in touch.

Use this playbook

Want me to run this with you?

The playbook is the public version. The private version is me running it for your team against a real deadline. If you have a project on the line, that is usually the faster path.

Start a projectJust ask a question

Next up

Architecture · 60 min

Refactoring Without Freezing the Roadmap

Every codebase accumulates debt. The mistake is treating that as a binary choice between shipping features and paying it down. This playbook is how I keep both moving in parallel: map the pain honestly, avoid the rewrite trap, lock current behavior with tests, ship the refactor behind feature flags, keep PRs small, and measure outcomes so the team knows the work is paying off.

Previous

Choosing a Database in 2026

Next

Refactoring Without Freezing the Roadmap