Shiritori

The brief

The take-home assessment for my role at Nyntax was to build a two-player Shiritori game in three hours, following its written requirements for the rules, scoring and timing. The whole session was screen-recorded, and AI tools were not allowed.

Starting from zero

I had never heard of Shiritori. So the first step wasn't code. I looked up what it is: a Japanese word-chain game where each word has to start with the last letter of the one before it. Then I found a version online and played it until the rules made sense to me.

Next I read the documentation for the Free Dictionary API, which the assessment suggested, so I knew what a valid word and a "not found" looked like before I built anything on top of them.

Then I built the game a piece at a time, going back to the online version whenever I wasn't sure how something should behave: what happens when time runs out, how scoring feels, when the turn passes. Having that reference open the whole time kept me from guessing at the rules.

How the game plays

• Two players take turns on the same screen, each with their own card.
• A word must start with the last letter of the previous word, be at least four letters long, and not have been used before.
• Every word is checked against a real dictionary before it counts.
• Each turn has a 15-second timer. A valid word scores the seconds left on the clock, so fast answers score more.
• Running out of time costs points. After ten more seconds the turn passes automatically, with a −2 penalty.
• The first player past 100 points wins.

How it works

One list as the source of truth. The whole game state is a single list of played words, each tagged with its player and score. Everything else is derived from it: each player's history, their running score, and the letter the next word has to start with. That kept the two player cards in sync without any shared mutable state between them, and made "Reset game" a one-line change.

Validation in layers. The cheap checks run first, as the player types: the starting letter, the minimum length and repeated words. Only a word that passes those goes to the Free Dictionary API. A 404 means it isn't a real word, and the player sees why straight away.

Timers that drive the turn. The active player's card runs the countdown. It focuses that player's input when the turn starts, locks the other player's input, and passes the turn on a timeout. The clock turns red when a player runs past zero, so the penalty is visible before it happens.

Decisions under a three-hour limit

• Same screen instead of online play. Networked multiplayer would have needed a server, rooms and syncing, which wouldn't fit in three hours along with the game rules. Playing on one screen let me spend the time on the rules, validation and scoring, which is where the game is.
• A public dictionary API instead of a bundled word list. No dataset to ship, and it covers real English vocabulary.
• Plain React state. The game is small enough that a single list of words in one component was simpler and easier to verify than adding a state library.

Taking it online

In the follow-up interview I was asked what I'd use to make the game multiplayer online. My answer: WebSockets for the real-time moves, a database like Firebase to keep games and scores, and authentication to tell the players apart and track each one. In more detail:

• WebSockets for live play. Each game is a room that two players join with a link or code, and every move is pushed to both of them instantly.
• A database for game state. The room's word list, scores and turn live in the database (Firebase, for example), so a game survives a refresh and a dropped player can rejoin where they left off.
• Auth for players. Signing in gives each player an identity, so the game knows whose turn it is, who scored what, and can keep a history per player.
• The server owns the rules. Today the browser checks words and runs the clock. Online, the server would do both, so neither player can cheat by editing the page. The game is already one list of played words, so the server keeps that list and broadcasts each new word, and the clients keep deriving everything else from it.

What I'd do next

• Sturdier rules: compare words case-insensitively, and handle the dictionary API being slow or down without blocking a turn.
• A drift-free timer: derive the remaining time from a start timestamp instead of counting interval ticks.
• Accessibility: announce whose turn it is and the errors to screen readers.