Joining Keelfolk's roster starts with the same test every engineer takes
An engineer joins Keelfolk's roster after a technical scenario built from a production incident, and stays on it for client work afterward.
The task comes from something that already happened somewhere: a service degrading under load, a deploy that took a platform down for twenty minutes, a scaling call made against a hard deadline. The person joining Keelfolk walks an engineer through what they would check first and what they would leave for later. The engineer asking the questions has already dealt with a version of the same problem, so a polished answer tends to break by the second or third follow-up.
How someone reasons with an incomplete picture carries more weight than the final answer. Incidents rarely arrive with clean data. Checking the logs first, then paging someone if that fails to narrow things down, says more to an interviewer than a textbook system-design answer.
Who conducts the interview?
An engineer working the same discipline handles it. That person already carries client work of their own.
32%
The technical stage tests trade-off reasoning, and it's the reason Keelfolk's roster stays narrow. Syntax and memorized documentation carry little weight in it. A candidate can describe a clean architecture on paper and still lose the thread when asked to justify a trade-off against a real constraint — a budget limit, a zero-downtime requirement.
Timelines
Standard roles usually reaches a client inside 1 to 2 weeks of the request. Terraform or Kubernetes takes longer, up to a month, since Keelfolk keeps fewer engineers on that part of the roster and holds off on putting someone forward just to close the role.