📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The paid trial task is the single most honest way to judge a developer when you cannot read their code yourself, and this piece lays out exactly how to run one. It uses Linear's real process (a short scoped project, then a clear yes-or-no call) so you have a concrete template instead of vague advice. Treat it as a starting point you adapt to your own product, not a rigid script.
From
Failory
by Nicolas Cerdeira
~10 min read
- A short paid trial on a real, scoped task tells you more than any number of interviews, because you watch how someone actually ships and takes feedback.
- Pay a fair rate for the trial: you are testing them and they are testing you, and paying keeps good people willing to do it.
- Decide with a clear bar (strong yes or no). Anything lukewarm is a no, which protects you from a hire you cannot technically evaluate later.
Open
newsletter.failory.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
When referrals are not available, you have to manufacture signal yourself, and this is the canonical piece on doing that through cold outreach on GitHub, LinkedIn, and Hacker News. Taggar is blunt that cold outreach is slow (plan for months) and only works when every message is genuinely personalized to what that person built. Read it as honest expectation-setting, not a promise of a quick hire.
From
Y Combinator
by Harj Taggar
~15 min read
- Look at public work (GitHub contributions, shipped projects) to judge people you have never met, since that is real evidence a resume is not.
- Cold outreach can work but is a grind: expect it to take months, and never send a generic message.
- Reference the specific work that made you reach out. That single detail is what separates a reply from being ignored when you have no shared connection.
Open
ycombinator.com →