Notes to Self: Hiring Playbook
Hiring Playbook (Notes to Self)
When a seat is empty, things start breaking. Deadlines slip. Code reviews pile up and morale dips. Rushing the wrong hire is worse than leaving the seat open. It slows the team and burns trust, so here is an outcome-driven reminder to myself.
It stems from six years of growing teams, making painful mistakes, and subsequently cleaning up those mistakes. I wrote this to stop myself from repeating those mistakes and to stay focused on what really matters.
Step 1: Remember Why I'm Hiring
Before anything else, write down what is broken right now. What work is slipping? Who is underwater? What outcomes are blocked?
Then, write 3 to 5 outcomes for this role.
- What do they need to deliver in the first 6 to 12 months?
- What will I look at in a year and say, "Yes, this was the right hire"?
This is the "duh" step, cliché. If you skip it or don't give it its due respect, regret it later.
Note to self: Hiring fast "just to fill a spot" is not a reason; every role must have a stated purpose, no matter how fast you have to hire.
Step 2: Picture Their Actual Week
Yes, defining day-to-day sounds basic.
But this is where I have burned myself the most when hiring in a rush.
List what they actually do each week/day: code, debug, plan, respond to incidents, and review.
In recruiting pipeline reviews and in-house hiring strategy meetings, I have had the most success in asking/answering from the new hire's perspective,
"When I wake up in the morning and turn on my laptop, what do I actually do, and what impact am I having?"
Write rough percentages: 40 percent build, 30 percent fix, 20 percent plan, 10 percent ops.
Determine whether they are a builder focused on developing new systems, a fixer concentrating on stability, or a blend of both.
Call out if I expect them to improve existing systems, not just ship tickets.
Step 3: Map the Complexity
Everyone says hire for autonomy, we want a "self-starter" or "product engineer". That is lazy advice unless I define what autonomy means here.
Write down how much ambiguity lives in this job.
What calls should they make without my approval?
Do they need to think in terms of systems or architecture, cost management, uptime, reliability, customer impact, or execute tasks?
This prevents me from hiring someone who would struggle in in ambiguity or over-engineer simple work.
Step 4: Identify the Humans They Work With
Yes, collaboration is obvious. Cross-functional alignment is a buzzword.
List every group they work with: PM, design, infra, data, CS.
Decide if async writing is a must-have, or if they need to make technical stuff less technical often, or if they will be in the weeds of software design 99% of the time.
Determine whether code review and peer feedback are part of their job responsibilities. Yes, it is possible to have engineers who don't need to review code!
Step 5: System Design Expectations
A general recommendation is to conduct a system design interview, regardless of the level; it is the right bar for passing at each level that matters more than the exercise.
Decide whether they design systems or implement them.
List what constraints matter most: cost, performance, uptime, etc..
Decide how often they need to think about edge cases or failures
Please refrain from selecting a random system design prompt from ChatGPT. Use a real problem we have actually faced, make for a smoother and more human interview experience...and your senior engineers who are conducting do not have to waste time "brushing up" on some esoteric... "build Facebook" with a #2 pencil and a Turing machine...
Step 6: QA and Ops Reality Check
Feels obvious, but are they responsible for testing their own work?
What level of coverage is good enough? Are they expected to handle incidents, be on call, or debug production?
If I don't write this down, I'll end up with someone being surprised to find out they own reliability.
Step 7: Growth vs Ready Made
Watch the words... "has potential", or "can grow in our system"
Only do that if I actually have time to coach and write down where I can hire for that potential and growth..
Be honest about bandwidth to mentor and onboard.
If we do not have capacity, we are setting them up for frustration.
Step 8: Make It Executable
Feed these notes into an LLM.
Generate a scorecard, structured interviews, and rubrics.
Review and adjust for reality.
Final Reminder to Self
If I cannot answer these questions clearly, I am not ready to hire, and this is sixty minutes of thinking that saves weeks of thrash and frustration later.