The Questions You Should Ask a Backend Contractor Before You Sign Anything

Most contractor evaluations focus on technical skills.

The questions that actually predict a good engagement are about something else entirely.

What the technical screen doesn't tell you

Most founders spend the majority of a contractor evaluation assessing technical ability. Algorithm questions, system design scenarios, code reviews of past work. These are worth doing. Technical depth matters, and someone who can't reason about distributed systems or write clean, testable code will struggle regardless of how well they communicate.

But technical depth alone doesn't predict whether a contractor will work well on an async remote engagement. The dimension that determines whether an engagement goes smoothly — whether deliverables arrive in a reviewable state, whether blocked questions get resolved without adding days to the timeline, whether scope discipline holds up throughout — is working style, not technical skill.

The questions worth asking before you sign anything are mostly about working style.

How do you handle a spec that has gaps?

This is the single most diagnostic question in a contractor evaluation.

Every spec has gaps. The question isn't whether the contractor will encounter ambiguity — they will — but what they do when they encounter it.

Listen for evidence of two things: judgment and communication. A contractor who handles spec gaps well makes a reasonable decision based on the context the spec did provide, documents what they decided and why, and surfaces the gap in their next update so the client can confirm or redirect. They don't stop working. They don't make large decisions silently. They move forward with a documented assumption and communicate it.

A contractor who handles spec gaps poorly either stalls — waiting for direction that adds a timezone gap's worth of delay to the project — or expands scope based on their own preferences without documenting that they did so. Both patterns are expensive in an async engagement.

Follow up by asking for a concrete example. Generic answers about "communicating clearly" are less informative than a specific story about a time the spec was unclear and what they actually did.

Can you walk me through how you communicate progress during an engagement?

The answer to this question reveals more about how a contractor actually works than most direct questions about communication style.

What you're looking for: a contractor who provides written updates at meaningful milestones — what was built, what decisions were made, what's next, what's blocked. Updates that give you useful information without requiring follow-up to interpret. A communication rhythm that keeps you informed without requiring synchronous check-ins.

What raises flags: contractors who describe communication primarily in terms of meetings or calls, who expect daily standups, or who see communication as something that happens when there's a problem rather than as part of the normal work product. These patterns don't fit async remote engagements well.

Ask specifically about timezone differences. How have they worked with clients across significant timezone gaps? What adjustments did they make? A contractor who has done this successfully will have specific things to say about how they handle it. A contractor who hasn't will often give a theoretical answer about being flexible and available, which is a different thing.

What does your handoff documentation typically look like at the end of a project?

Most contractor evaluations don't ask this. It's one of the most useful questions you can ask.

A contractor who produces good handoff documentation leaves the client with something beyond the code itself: a written description of what was built, the decisions that were made and why, what's in scope and what isn't, and context for whoever touches the code next. This documentation is what allows the work to persist without the contractor — which is the entire point of a time-limited engagement.

Contractors who think about handoff documentation are usually contractors who think about the client's experience beyond the deliverable. That orientation correlates with other things that make engagements go well: clear communication, scope discipline, appropriate documentation within the code itself.

Ask if they have examples. A contractor who regularly produces good handoff documentation will be able to describe it concretely or share a sanitized version. A contractor who hasn't thought about it will give a vague answer about "documenting the work."

Tell me about a project that didn't go well. What happened?

This question is useful in any hiring context. For contractor evaluation, it's particularly revealing because the failure modes in contracting engagements are specific and worth understanding.

What you're listening for: a contractor who takes ownership of what was within their control, can articulate what the root cause was, and describes what they'd do differently. An honest answer about a scope misunderstanding, a spec that was ambiguous in ways they didn't catch early enough, or a communication breakdown that could have been avoided.

What raises flags: contractors who assign all blame to the client, who can't identify anything they'd do differently, or who describe the project as a success that the client simply didn't appreciate. These answers suggest a contractor who won't surface problems early enough in your engagement either.

How do you scope your work to avoid running over on time or budget?

Scope discipline is one of the most consequential working style qualities in a contractor, and it's one that's difficult to assess from a portfolio or technical screen.

A contractor with good scope discipline understands what's in the spec and builds that — not more, not less. When they notice something adjacent to the spec that seems like it should be addressed, they flag it and ask rather than making the decision unilaterally. When the spec doesn't anticipate a specific edge case, they handle it reasonably and document their approach rather than expanding to solve the general version of the problem.

Ask for a specific example of a time they had to make a judgment call about scope — something that was adjacent to but not explicitly in the spec. How did they handle it? What did they tell the client?

What do you need from a client to do your best work?

This is a question most contractors aren't asked, and the answers are often illuminating.

A contractor who understands what they need to be effective — a clear spec, access to specific parts of the codebase, a predictable review cadence, a designated person to answer questions — is a contractor who's thought carefully about what makes engagements work. Their answer will tell you something about whether your team is currently set up to provide what they need.

A contractor who says "just clear communication" or gives a vague answer is either less experienced with what distinguishes good engagements from difficult ones, or isn't in the habit of thinking about client-side requirements. Both are worth knowing before you sign.

The work sample that confirms everything

After these questions, a small paid work sample is the most reliable confirmation of fit.

Give the contractor a real, bounded task — a representative piece of the actual engagement, or something close to it. Write the spec the same way you'd write it for the real project. Observe how they engage: what questions they ask and how, how they communicate during the work, what the deliverable looks like, and how they document what they built.

The work sample puts the actual working conditions in place rather than simulating them. The quality of the output under those conditions is better evidence of engagement fit than any amount of interviewing.

Where this leads

Finding a contractor who answers these questions well is the first half of making an async engagement work. Having the infrastructure on your side to engage them effectively is the second.

The form at /contact covers that side of the equation — asking about how your team defines work, documents systems, and structures handoffs, and whether the conditions are in place for a backend contracting engagement to go well from day one.