Fly.io Engineering Hiring Challenges: Work Samples and Written Technical Discussion

Fly.io engineering hiring preparation should begin with the artifact you can defend, not a guessed algorithm list. The company’s current public process centers on at-home work samples followed, for a typical engineering role, by a structured written discussion. Your own invitation controls the exact challenges and applicability.

This guide separates current official information, an archived historical repository, and an original idempotent event exercise. The exercise is not a Fly.io prompt, platform implementation, or solution to a public challenge. Start with Design Under Vague Distributed Requirements to practice turning an incomplete request into a reviewable contract.

What Fly.io currently says about hiring

Current official guidance: Fly.io’s hiring documentation says it uses work-sample challenges rather than a standard résumé-and-interview process. Its detailed process page describes a typical engineering path with usually two or three at-home challenges completed one at a time, followed by a 60–90 minute typed discussion in Slack. It says the structured discussion has no coding, video, or microphone.

The same page says delivery time is not considered when grading challenges, while noting that role availability can change. Do not convert that statement into unlimited practical availability or a promise that every current role uses identical steps. The page itself uses “typical,” and the company says it will explain the challenges for the role.

Fly.io’s current roles page describes backend, UX, security, infrastructure, and platform families with different stacks. A generic work sample cannot prove readiness for all of them. Read the role description and invitation before choosing which evidence to emphasize.

No two independent same-cycle candidate reports were established for this article. Accordingly, it does not claim a hidden scoring rubric, current acceptance rate, or universal challenge content.

Keep archived challenges in historical context

The public fly-hiring/support-engineer-challenge repository is official historical evidence, but GitHub marks it archived on February 15, 2025. Its Rails task and customer-response prompts should not be presented as the current engineering challenge for another role.

An archived repository can still teach a durable lesson: the submission was judged through a small working change plus clear reasoning for developer users. The useful preparation inference is to make your artifact reproducible and your written decisions inspectable. The exact task, expected polish, branch workflow, and timing belong to the current private instructions.

Do not publish or share a private challenge. Do not search for leaked solutions. Use public materials to understand the company’s stated format, then build an unrelated exercise that trains the same general communication skills.

Build a small reproducible work sample

The original exercise in this article processes event increments by region. Each event has a unique ID, a key, and a delta. Delivery may repeat, so applying the same ID twice must not double-count it. The implementation keeps a set of seen IDs and per-key totals.

def apply(state, event):
    if event["id"] in state["seen"]:
        return state
    next_state = {
        "seen": state["seen"] | {event["id"]},
        "counts": dict(state["counts"]),
    }
    key = event["key"]
    next_state["counts"][key] = next_state["counts"].get(key, 0) + event["delta"]
    return next_state

The input trace is e1: iad +1, e2: iad +2, repeated e1, and e3: ord +4. The final totals are iad=3 and ord=4, with three unique event IDs. Six local checks passed, including duplicate suppression and explicit refusal to claim a real delivery guarantee.

This is a pure in-memory model. It does not establish durable storage, concurrent atomicity, queue acknowledgment, partition ordering, retention, crash recovery, or exactly-once delivery. Those limits are central to the written defense.

Package evidence another engineer can reproduce

A reviewer should be able to run the work without reconstructing your environment. Include the runtime version, one setup command, one test command, the expected short output, and where the main decision lives. Use dummy data and no credentials.

Keep the repository small enough to inspect. Separate implementation, tests, and a concise README. Record assumptions before design notes: event IDs are stable; a duplicate has identical content; negative deltas are allowed or rejected by contract; state is single-process for this version.

Then state what you actually verified. “Six deterministic checks passed locally” is useful. “The system is reliable” is not supported. Include one failure you tested and one important failure you deferred.

Submission element	Evidence	Honest limit
Run instructions	Clean command and expected output	One local runtime
Duplicate behavior	Replayed e1 leaves totals unchanged	No concurrent writers
State transition	Input state is not mutated on accepted event	Memory only
Design note	Stable event ID is the idempotency key	Producer identity not validated
Follow-up	Atomic conditional write	Not implemented

Explain the production gap precisely

If two workers read unseen e1 concurrently, both can compute an updated total before either records the ID. The in-memory set is not an atomic database boundary. A production design needs a transaction or conditional write that records the idempotency key and aggregate change together.

That creates follow-up questions: how long are IDs retained, what happens when the same ID arrives with different content, how are hot keys partitioned, and can aggregates be rebuilt from an immutable log? Choose one based on the stated product requirement rather than listing every distributed-system pattern.

For a first durable version, store each unique event with a uniqueness constraint and update the derived total in the same transaction. On conflict, compare a content hash; identical replay is safe, while mismatched content is quarantined. Explain the storage cost and cleanup policy.

Do not claim “exactly once” without defining the boundary. The consumer may achieve an idempotent state transition even though the message is delivered more than once. External side effects such as emails require their own idempotency contract.

Prepare for the written technical discussion

Fly.io’s official page describes a typed structured discussion intended to understand thinking and collaboration. Prepare to answer from the artifact: assumption, observation, decision, trade-off, and verification.

A weak answer says, “I used a set because duplicates are common.” A reviewable answer says, “The contract permits repeated delivery with stable IDs. Replaying e1 changed no total in the local trace. The set makes that behavior explicit, but it is process-local; a durable version needs an atomic uniqueness boundary.”

When asked why you did not build the durable version, connect scope to evidence. The local model isolates the idempotency rule without requiring infrastructure. Then outline the smallest next experiment: two workers racing on the same ID against a transactional store, with one accepted transition and one conflict.

Use short paragraphs in a typed conversation. Answer the question first, then give the evidence and limitation. Ask a clarifying question when the requirement changes the design, such as whether per-region order matters or totals may temporarily lag.

Ask questions that change the design

Fly.io publishes separate guidance encouraging candidates to ask concrete questions. For this exercise, useful questions include: Are IDs globally unique? Can duplicate payloads differ? Is per-key ordering required? Must totals survive region loss? What is the acceptable recovery point?

Each answer should alter an implementation or test. If IDs are only unique per producer, the key becomes (producer,id). If mismatched duplicates indicate corruption, silently ignoring them is wrong. If ordering matters, duplicate suppression alone is insufficient.

Avoid questions whose only purpose is to display vocabulary. State the uncertainty, explain why it matters, and offer a default if the reviewer wants you to proceed.

Review the work before submission

Run from a clean checkout or disposable directory. Confirm documented commands, remove debug output, inspect the diff, and ensure no token, private prompt, or environment file is committed. Read every written claim against the evidence.

Keep incomplete work visible. A short “Known limits” section should name concurrency, persistence, and side effects for this exercise. Do not hide them in a future-work list that suggests they are trivial.

During the written discussion, be ready to revise. If new information invalidates an assumption, say so and update the design. Clear correction is stronger than defending the first answer after its premise changed.

Rehearse a written follow-up sequence

Imagine the reviewer asks, “What happens if the process crashes after incrementing the total but before recording the event ID?” Answer directly: in the in-memory model the whole process disappears, so that sequence is outside its guarantee. In a naïve database split across two writes, replay could increment twice. The durable design must commit the unique event record and aggregate transition atomically, or derive the aggregate from an immutable accepted-event log.

The reviewer then asks, “Would you keep every event ID forever?” State the trade-off. Permanent retention makes duplicate detection simple but grows storage without bound. Expiring IDs saves space but permits a very late replay. Choose retention from the producer’s maximum retry window and audit requirements, and explain how cleanup avoids racing with active deliveries.

Next: “Can you process regions in parallel?” If totals are independent by region, partitioning by key permits concurrency. A single hot region can still concentrate load. If event order changes the result—for example, a set operation rather than a commutative increment—partition order and sequence gaps become part of the contract. The current addition example does not prove ordered processing.

Finally: “How would you know it is failing?” Propose signals connected to user impact: accepted events, duplicate rate, mismatched duplicate payloads, processing latency, retry age, dead-letter count, and aggregate reconciliation differences. Avoid inventing universal thresholds. Establish a baseline and alert on a threshold tied to freshness or correctness requirements.

This sequence demonstrates a useful pattern for typed discussion. Begin with the exact limit of submitted code, reason from a concrete failure window, choose one repair, and describe the test or metric that would prove it. The answer remains readable because each paragraph resolves one question.

Compare two valid designs

An event table plus derived aggregate favors auditability and rebuilds. It stores more detail and may require asynchronous materialization. A transactional aggregate with a deduplication table can produce immediate reads but couples retention and update logic. Neither is always superior.

State the expected read pattern, recovery requirement, and volume before choosing. For a bounded sample, implement one and document the other. If you switch approaches during review, explain which new requirement caused the switch. This shows flexibility grounded in evidence rather than a preference for a familiar database pattern.

Sources and Further Reading

• Fly.io: Our Hiring Process — current official work-sample and structured-discussion description.
• Fly.io: Join Our Team — current official overview.
• Fly.io: Our Roles — role-family context.
• Fly.io: How To Ask Us Questions — official guidance on useful questions.
• Archived Fly.io Support Engineer challenge — historical repository archived February 15, 2025; not treated as a current prompt.