Writing async engineering specs that remote teams actually follow

Witarist Hire — Wed, 13 May 2026 17:29:01 +0000

One of the biggest friction points in distributed engineering teams isn't technical — it's the spec. Here's the format that reduced our back-and-forth significantly.

The problem with most specs

Most engineering specs are either too vague ("build a notification system") or too prescriptive ("use Redis pub/sub with these exact keys"). Neither works well.

The first requires endless clarification before starting. The second removes the engineering judgment that makes a senior developer worth hiring.

The 6-section format

1. Context (2–4 sentences)

Why does this need to exist? What breaks without it?

Example: "Our billing webhook handler processes all events synchronously. When Stripe sends a burst, the endpoint times out and Stripe retries, causing duplicate processing. This caused 3 support tickets this week."

2. Success criteria

Observable behaviors, not implementation steps.

- Stripe webhooks return 200 within 200ms
- Duplicate events are idempotent (same event ID = no side effect)
- Failures are retried with backoff (3 attempts: 5min / 15min / 60min)
- Failed events after retries are stored for manual review

3. Constraints

What can't change? What's the technology boundary?

4. Open questions

What decisions is the engineer expected to make?

Example: "Queue implementation is your call — evaluate BullMQ vs Inngest and document the tradeoff in the PR."

5. Out of scope

What explicitly doesn't need to be solved here.

6. Dependencies / resources

Links to relevant code, docs, or people to consult.

Why "open questions" is the most important section

When you skip it, engineers either make decisions silently (you find out at review) or block waiting for approval. Writing "here are the decisions I'm delegating to you" gives senior engineers the autonomy they want while keeping you in the loop on design surface.

Anti-patterns

The spec-by-wireframe — a Figma screenshot with no written context. Engineers can't build from UI designs alone.

The spec with a hidden solution — "We need a caching layer" when you actually mean "add Redis here." If you've decided, just say so.

The spec that changes mid-implementation — if requirements change, write an addendum. Don't edit the original. Engineers need to track what changed.

What sections do you include that I haven't mentioned? Comments welcome.

How I structured a technical assessment for hiring remote developers (and what actually worked)

Witarist Hire — Wed, 13 May 2026 17:28:13 +0000

Running a 3-person startup means every engineering hire is high-stakes. Here's the assessment framework we landed on after several failed attempts.

What didn't work

Live coding in a video call — candidates froze up, output didn't reflect their actual ability. Senior devs especially hated being watched.

Full take-home projects (3–5 hours) — good candidates dropped out because their time is valuable and they had options.

Just asking about past projects in an interview — too easy to embellish, no signal on actual implementation thinking.

What worked: a focused 90-minute async task

The format we converged on:

A real, scoped problem from our actual codebase context (not a LeetCode puzzle)
90-minute time limit, explicitly communicated upfront
Asynchronous — they pick a 2-hour window, we review async
Evaluated on reasoning, not perfection

We send a single file: a TypeScript module with a bug, a missing feature, and some intentionally messy code. The task:

Fix the bug (tests are provided, they should pass)
Add the missing feature (spec is included)
Optionally: clean up anything that bothers you

What we evaluate

Bug fix correctness: Do they actually read the failing test?
Feature implementation: Do they handle edge cases?
Code style choices: Consistent, readable, no over-engineering
Optional cleanup: Shows initiative and code taste
Time management: Did they scope appropriately in 90 min?

What we explicitly don't evaluate

Whether they used the same patterns we use (we want their instincts)
Speed (90 minutes is enough to see real work, not a rush)
Perfect syntax (they can Google things)

The follow-up conversation

After the assessment, we do a 30-minute async written Q&A (not a call). We ask:

"Walk me through your fix for the bug"
"What would you change if you had another hour?"
"What bothered you most about the original code?"

The written format gives introverted engineers a chance to shine and reveals how well they communicate technical decisions in text — which matters enormously for async remote teams.

Results

We've used this format across ~40 hires. Key observations:

Drop-off rate is much lower than take-homes (candidates respect the 90-min scope)
Strong signal on seniority without a 5-round process
Candidates who do well here almost always perform well in the role

Happy to share the actual task template if there's interest — drop a comment.

DEV Community: Witarist Hire