Build a Wordle Guess Checker with Green, Yellow and Red Letter Feedback

Build a small version of the classic Wordle word game as a browser component. A fixed secret word is checked against what the user types, and each typed letter is shown with a color that tells the user how that letter relates to the secret word: - **Green**: the letter is in the secret word at this exact position. - **Yellow**: the letter is in the secret word, but at a different position. - **Red**: the letter does not appear in the secret word. The user can enter at most five letters. The task supplies the word `SPEND` for testing; treat it as the secret word. Styling is not required beyond making the three states distinguishable, so the time should go into correct feedback and a working input flow. ### Constraints and Clarifications - Time limit: 45 minutes in an online coding environment, including testing. - Secret word for testing: `SPEND` (five distinct uppercase letters). - Input: letters only, at most five of them. - Visual styling is not graded; the three color states are. ### Clarifying Questions - Is a particular front-end framework required, or is plain JavaScript acceptable? - Should the colors appear as the user types, or only after the guess is submitted? - Must a guess contain exactly five letters before it can be checked, or can a shorter guess be scored? - Does a guess have to be a real dictionary word? - Should the component keep earlier guesses on screen, and is there a limit on the number of attempts? ### Part 1 — Letter feedback logic Write the logic that, given the secret word and a guess, returns one status (green, yellow or red) for each guessed letter. For example, against `SPEND` the guess `SNEAK` produces green, yellow, green, red, red. ```hint Keep it testable Make the scoring a pure function of the secret and the guess, independent of any UI state, so you can check it against SPEND before wiring up the page. ``` #### Clarifying Questions for this Part - `SPEND` has no repeated letters, but a guess can (for example `SPEED`). When a guess contains more copies of a letter than the secret word does, which copies should be green or yellow and which should be red? - Should matching ignore case? #### What This Part Should Cover - Correct position-sensitive (green) versus position-insensitive (yellow) classification. - A deliberate, explained rule for repeated letters in the guess. - Behavior for guesses shorter than five letters, if they are allowed. ### Part 2 — Input and rendering Build the interface: a way for the user to type a guess that is capped at five letters, and a row of letter tiles colored with the statuses from Part 1. ```hint Guard the input in one place Decide where letters are normalized and capped so that typing, pasting and deleting all pass through the same rule. ``` #### What This Part Should Cover - Input restrictions: letters only, maximum length, case normalization, including pasted text. - A clear state model: what is stored (current guess, submitted guesses) versus what is derived (statuses, solved state). - Rendering that maps each status to a distinguishable color, plus a submit flow (button or Enter key). ### What a Strong Answer Covers - Separation between the scoring logic and the view code, with quick checks against `SPEND`. - Correct three-state feedback, including repeated letters in the guess. - A finished, working flow within 45 minutes rather than a polished but incomplete one. - Awareness that color alone is not accessible, and a cheap way to add text labels. ### Follow-up Questions - How would you extend the component to multiple attempts with a win or lose state? - How would you add an on-screen keyboard that shows the best-known status of every letter across all guesses, and how do you merge statuses coming from different guesses? - How would you make the feedback usable for a color-blind user or a screen-reader user? - Which test cases would you write for the scoring function and for the component, and why those?