The Outlier coding sample rejects roughly 28% of applicants on first attempt. Most rejections are not for lack of coding skill — they're for missing something the prompt explicitly asked for. Here's what the sample actually tests, what trips people up, and a one-hour prep routine that closes the gap.
What the coding sample actually is
You'll get a take-home link valid for 7 days. Inside, you have a 60-minute timer and a small program with 2–4 deliberate bugs, plus a refactor task. The language is whichever you listed as primary on your profile. Most samples are in Python, JavaScript, Java, or Go; niche-language samples (Rust, C++) are reserved for contractors who specifically applied for those tracks.
The sample is graded on three axes: bugs found, refactor quality, and adherence to constraints stated in the prompt. The first two are coding ability. The third is reading ability, and that's where most candidates lose.
The single biggest reason for failed samples
Missing a stated constraint. Every sample has 1–3 constraints embedded in the prompt: "Limit changes to auth.py." "Don't introduce new dependencies." "Maintain the existing public API." "Return JSON, not a Python dict."
Read the prompt twice before writing any code. Then read it a third time after you finish, before submitting. Two minutes spent re-reading prevents an automatic fail.
The 60-minute structure that works
- Minute 0–5: Read everything. The prompt, the code, all comments. Underline every constraint. Write them on a sticky note.
- Minute 5–10: Run the code first. Most samples ship with a test suite. Run it. The failures are clues to where the bugs live.
- Minute 10–35: Find and fix bugs. Aim to have all bugs fixed by minute 35. Don't refactor yet.
- Minute 35–50: Refactor. Now restructure code as the prompt asks. Stay focused — don't refactor things they didn't ask about.
- Minute 50–58: Re-read the prompt. Check every constraint against your final code. Run the tests one more time.
- Minute 58–60: Submit.
Bugs Outlier likes to plant
Patterns we've seen across 60+ contractors who shared their samples:
- Off-by-one in loop bounds. The most common bug. Look at every
range()and slice carefully. - Mutable default arguments (Python). A function with a
def f(x, items=[])signature where the bug is thatitemspersists across calls. - Type coercion that swallows errors. A function that should raise on bad input but instead silently returns
Noneor empty. - Race conditions in async code. Two awaitables that should run sequentially are launched in parallel.
- Sneaky null-handling. An optional that's not actually checked before dereferencing.
If you've coded for 2+ years in your primary language, none of these are unfamiliar. You just have to slow down enough to spot them.
Refactor task: what good looks like
Refactoring is graded on three sub-criteria: correctness preserved, readability improved, and changes localized to what the prompt asked for. Most candidates over-reach — they see a function they don't like and rewrite it even though the prompt didn't ask. Don't. The reviewer reads the prompt; if your changes go beyond it, that's a flag.
Strong refactors are boring. Extract a helper. Rename a confusing variable. Replace a manual loop with a clean comprehension. Don't redesign the architecture.
Common reasons for rejection
- Missed a constraint. ~40% of rejections in our data.
- Found bugs but introduced new ones. ~25%.
- Refactor went too far. ~15%.
- Didn't run the tests before submitting. ~10%.
- Solid code but no comments / no reasoning. ~10%. Outlier wants to see your thinking, not just your output.
The prep routine that helps
The night before:
- Open a clean editor in your primary language. Time yourself reading 200 lines of someone else's code in 5 minutes. If you can't accurately summarize what it does, slow down.
- Solve 2–3 LeetCode "easy" problems. Goal: build muscle memory for finding subtle bugs in small functions, not for solving algorithm puzzles.
- Re-read the official Python or JS style guide if you haven't recently. Reviewers notice.
- Sleep 8 hours. Tired pattern recognition fails on bug-spotting.
If you fail
Outlier reapplies after 90 days. Use those 90 days to ship a small open-source contribution in your target language — that's the highest-leverage signal you can send your second time. See the full Outlier approval timeline for what to expect on round two.
Bottom line
The Outlier coding sample rewards careful reading over fast typing. Read the prompt three times. Find bugs first, refactor second. Don't reach beyond what's asked. Run the tests before submitting. Most contractors who follow that script pass on the first try.