Random Team Picker

Sequential block assignment (first M names → team A, next M → team B, etc.) gives the same minimum-imbalance team sizes as round-robin, but it leaks input-order information into team membership. If the roster is sorted alphabetically, team A gets everyone whose name starts with A-D and team B gets E-H — friends sitting next to each other on the roster end up on the same team. Round-robin (index modulo team-count after a Fisher-Yates shuffle) decorrelates the output from the input order: every permutation of the roster is equally likely, so the input order has zero influence on team membership. This is the canonical fair-partition approach used in sports drafts where draft order matters (snake drafts add a reverse pass for further fairness).

The naive alternative is to give each name a random number and sort by that number. This works in theory but has two practical issues: (1) JavaScript's `Array.prototype.sort()` is not guaranteed to be a perfect-shuffle sort in all browsers — it uses TimSort (V8, since Chrome 70 in October 2018) which compares pairs and can be biased by tie-breaking when two random keys collide; (2) the per-element random key needs 32+ bits to avoid collisions, multiplying the entropy budget. Fisher-Yates (Knuth Algorithm P, the in-place adaptation by Durstenfeld CACM 1964 of the original Fisher & Yates 1938 pencil-and-paper version) generates an exact uniform permutation in O(n) time and O(1) extra space per swap — no sort, no tie-breaking, no entropy waste. This tool's `shuffle()` in `src/lib/random.ts` is the textbook Durstenfeld implementation backed by `crypto.getRandomValues()`.

Team sizes always differ by at most 1, regardless of roster size or team count. The round-robin assignment (index modulo numTeams) guarantees this: a roster of 11 split into 4 teams comes out 3-3-3-2, never 5-2-2-2 or any other lopsided arrangement. The smaller teams are always the last ones in the index order (team D in the 11-into-4 example), but since the names were already shuffled before assignment, which exact team ends up with the extra absence is random. For sports leagues this is usually fine; for chore rotation where the smallest team has a clear advantage you might want to rotate which team gets the smaller size across sessions.

This tool does equal-or-near-equal partitioning only. For role-based splits you can run it twice: first split into role tiers (say, captains vs players) by sorting the roster manually, then call the picker on each tier separately. Alternatively for very small team counts you can split manually after seeing the first result. The tool's UI sticks to 2-10 equal-or-near-equal teams because that is the dominant use case (PE class, hackathon squad assignment, classroom group projects, sports drafts) and adds enough complexity already; explicit unequal partitioning is rare enough that adding a UI for it would clutter the page for the 95 % of users who just want fair even teams.

Yes — clicking "Pick teams" again re-shuffles. Each click runs a fresh Fisher-Yates pass over the same roster, producing an independent permutation. Mathematically there is no memory of the previous split: in expectation a second click changes a non-trivial fraction of team assignments (about 1 − 1/numTeams per name on average). If you want to avoid a specific pairing showing up at all across re-rolls ("these two should never be on the same team"), the cleanest solution is to remove one of them, run the picker, then add them to the opposite team manually — explicit constraints are usually faster to express by editing the roster than by adding UI for them.