So you want to add something to the pot — lovely! This page is what makes a good challenge, what's in scope, and how we decide difficulty.
A quick, honest note: this is a first draft. It's meant to grow as we learn what works. If something here feels wrong, too strict, or too vague, say so — shaping these rules is one of the most useful things you can do here.
The best challenges are small, self-contained, and teach one idea. A solver should be able to read it, understand exactly what's being asked, and have a satisfying "aha" within half an hour.
Aim for:
- One clear task. A single function to write, with a name and arguments you specify. Not a mini-project.
- Unambiguous. Two people reading it should agree on what a correct answer looks like. Spell out edge cases if they matter.
- A worked example. Show a call and its expected result. This is often clearer than any amount of prose.
- Solvable more than one way. The nicest challenges invite different approaches — base R vs. tidyverse, a loop vs. a vectorised trick — so people learn from each other's solutions in the thread.
- Kind, not tricky. We're here to teach and encourage, not to catch people out. Skip "gotchas" that punish a reasonable reading.
Challenges are about writing R — logic, data manipulation, string handling, functions, a bit of algorithmic thinking.
You may use base R or any of these packages:
dplyr, tidyr, purrr, stringr, forcats, tibble, readr, ggplot2, lubridate (plus base, stats, utils)
Keeping to a small, common toolkit means challenges run anywhere and nobody needs to install something obscure to play.
- No file, network, or system access — no reading files, downloading data, hitting APIs, or shelling out. A challenge must be fully self-contained.
- Nothing non-deterministic — no
Sys.time(), no unseededsample()/runif(). If randomness is part of the puzzle,set.seed()inside the solution so the answer is stable. - No packages outside the list above (for now — suggest additions in an issue if there's a good case).
- No huge or external datasets — if data is needed, it should be tiny and defined inline.
- Nothing exclusionary — no content that assumes a narrow background or makes people feel unwelcome. This is a beginner-friendly, global community.
Difficulty is about who can comfortably attempt it, not how long it takes. When in doubt, rate it down — an easy win is more encouraging than a wall.
One idea, basic syntax. Someone who's done an intro R workshop can have a go.
- Vectors,
if/for, subsetting, simple arithmetic, a one-argument function. - Example shapes: FizzBuzz, reverse a string, sum the even numbers, count the vowels, check for a palindrome.
Combine a few ideas. A regular R user who writes their own functions.
- Data wrangling (dplyr/tidyr), a function with a couple of arguments, working with lists or data frames, moderate logic.
- Example shapes: group-and-summarise with a twist, a small text parser, a
running average, tidy a slightly messy table, implement
table()by hand.
Non-trivial logic or genuinely R-idiomatic cleverness. Experienced R users.
- Recursion, functional programming (
Reduce,purrr), edge cases that bite, performance, or a neat vectorised answer to something that looks loopy. - Example shapes: memoised recursion, roll-your-own
group_by, a tiny expression evaluator, a vectorised sliding-window, a puzzle with sharp corner cases.
Every challenge ships with tests — R expressions that each return TRUE
when a solution is correct (e.g. identical(fibonacci(10), 55)). These let us
run the reference solution and confirm it actually works before anything goes
out.
If you submit without tests, that's okay — a reviewer will add them. But including a couple yourself makes review faster and your challenge stronger.
Open the challenge form and fill it in: title, difficulty, the task, an example, your reference solution, and (ideally) a test or two.
Your submission lands as a status: proposed issue. A reviewer will:
- check it's in scope, clear, and fair,
- confirm the difficulty against the rubric above,
- run the solution against its tests,
- then either approve it (it joins the queue for a future week) or leave a comment with suggestions.
Approved challenges are posted to the community Slack, oldest first — the reference solution stays here in the issue and is never given away in the post.
Thank you for brewing with us. 🧹