Early in my building journey I treated hiring as something to do once the product was working. Then the product started working and I realised I had no idea how to bring on my first engineer without s
Markdown supported · ⌘↵ to post
Writing the job around three problems the hire will own in the first six months is much better than a laundry list of technologies. It also makes the paid trial task easier to design, because you already know what "useful" looks like.
We see a similar pattern when founders bring in outside help instead of a full-time hire. The first engagement works best when it is one clearly bounded problem at a fixed price, with acceptance criteria and accounts owned by the company from day one. You learn how the person communicates and delivers, and the cost of finding out is capped.
Did the short paid task end up becoming your main filter, or do you still run a traditional interview alongside it?
StackShortlist
Proof Over Promises.
Writing the job around the three problems the hire will own in six months is a much better filter than a list of every technology you might touch. A small paid task also tells you how someone works inside your real codebase, which puzzles never show. Planning the first two weeks before they join is the step most founders skip, and it's often what decides whether the hire speeds things up or slows them down.