Velo Blog

Tag: interviews

  • A take-home task that respects candidates

    A take-home task that respects candidates

    What we ask

    Our take-home is capped at two hours. We say two hours, we mean two hours, and we check on it. If a candidate spends four, we treat that as our fault for scoping poorly, not theirs for being slow.

    The prompt is a real problem we hit last March: a Linear webhook was dropping payloads under load, and our on-call channel in Slack filled with duplicate alerts. We strip the business context, sanitize the payload shape, and hand candidates a repo with the failing test already written.

    What we pay

    Two hours of senior engineering time is not free. We pay 200 pounds per completed submission, regardless of outcome. Finance flagged it as unusual the first time; now it runs through the same expense flow as contractor invoices.

    A short list of what the pay covers:

    • The two hours of coding.
    • The 20 minute walkthrough call afterward.
    • Any follow up questions we send over email.

    The rubric lives on GitHub

    Our scoring rubric sits in a public repo, versioned like code. Candidates read it before they start. We grade on four axes: correctness of the fix, quality of the test coverage, clarity of the pull request description, and whether the candidate flagged the ambiguities we planted.

    If you cannot show a candidate how you will grade them, you do not have a rubric. You have a mood.

    We do not hide the trick either. There is a race condition in the retry logic that most candidates miss. That is fine. Missing it is not disqualifying; pretending it does not exist in the walkthrough call is.

    Why bother

    The hiring market tells engineers their time is worth nothing until an offer lands. We think that assumption poisons the relationship before day one. When someone joins us on a Tuesday, they have already seen how we write tickets, how we scope work, and how we handle disagreement. Nothing about the first week is a surprise.

    Two candidates last quarter turned down our offer. Both cited compensation. Neither cited the interview. We will take that trade.

  • How we run the same customer interview every quarter

    How we run the same customer interview every quarter

    Every quarter, on the second Wednesday of the last month, we sit down with three Velo customers and ask them the same eight questions we asked last quarter. Same script. Same order. Roughly the same time of day. The value is not in any one conversation. The value shows up when we diff the transcripts.

    The script we do not change

    The temptation to tweak questions is strong, and we resist it. Once you edit a question, you cannot compare answers across quarters. Our fixed eight, in order:

    • Walk us through the last thing you did in Velo this morning.
    • What did you almost use Velo for, and then use something else?
    • Which tab do you open first when you log in?
    • Who else at your company touches Velo, and how?
    • What have you built around Velo that we did not ship?
    • When was the last time Velo surprised you, good or bad?
    • If we shut down tomorrow, what would you replace us with?
    • What are you doing on the days you do not open Velo?

    Three users, chosen from a rotating pool of twelve power accounts. One customer we keep constant across the year for a longitudinal read. Two rotate.

    The diff is the deliverable

    We record with Grain, get transcripts back within the hour, and drop them into a Notion database with one row per user per quarter. On Friday we run a working session with product, design, and one engineer. The rule for that session: no talking about individual quotes until we have compared the same question across quarters.

    What we look for in the diff:

    1. Words that appear this quarter and did not appear last quarter. Q1 nobody said “audit.” In Q2, all three did.
    2. The “almost used Velo for” answer shifting toward one workflow. Two quarters in a row of the same near-miss becomes a Linear ticket in the next planning cycle.
    3. Tab-first answers drifting away from the tab we consider the home screen. That happened to Reports in Q3 last year and pushed the nav redesign.
    4. Homegrown scripts built around us. Every quarter someone shows us a Google Sheet stitched to our API. That sheet is the roadmap.

    The interview does not tell us what to build. The diff between interviews does.

    What we do with it

    By the following Monday, the working session produces a one page memo in Notion with three sections: patterns that hardened, patterns that softened, and one thing we were wrong about. That memo goes to the whole company in Slack, and the three tickets it generates land in the top of the next sprint. That is the whole loop. Eight questions, three users, one diff, one memo, three tickets.