AI-Assisted Build: Tic-Tac-Toe Logic Grown Into a Frontend and Backend App

In this round you may use AI coding tools throughout: a chat assistant, in-editor completion or a coding agent. Your task is to build a working two-player Tic-Tac-Toe game and then turn it into a polished application with a frontend and a backend. The interviewer evaluates the result and, just as much, how you work with the AI: whether you understand the code it produces, how you iterate on it, how you track down and fix bugs, and how you demonstrate that the finished application is correct. Narrate your decisions as you go. ### Constraints and Clarifications - Standard rules: a 3 × 3 board, players X and O alternate with X moving first, three of the same mark in a row, column or diagonal wins, and a full board with no winner is a draw. - You choose the language and framework unless the interviewer specifies one. - You own every line that ends up in the application, whoever typed it, and should be able to explain any of it on request. ### Clarifying Questions - Are both players on the same screen, in two different browsers, or is one of them a computer opponent? - Must a game survive a page refresh or a server restart? - What does "polished" mean for this session: visual design, error handling, automated tests, deployment, or some combination? - Which AI tools are available, and are there any limits on what may be pasted into them? ### Part 1 — Core game logic Implement the game rules in a module that does not depend on any user interface: the board, applying a move, rejecting invalid moves, and detecting a win or a draw. Show how you would ask the AI for this code and how you would check what it gives you. ```hint Specify before you generate Decide what applying a move should do in each invalid situation before asking a tool to write it, so you have something to check its output against. ``` #### What This Part Should Cover - Complete rules, including every kind of invalid move and moves after the game has ended - Logic separated from presentation so it can be tested directly - Tests for wins in every direction, draws, and a win on the last available square - How generated code is reviewed and verified rather than accepted as-is ### Part 2 — From script to frontend and backend Turn the logic into an application: a frontend that renders the board and the game status and lets players click to move, and a backend that stores games and enforces the rules. Describe the API, where validation happens, and how the frontend stays in sync with the backend. ```hint Decide who is authoritative Ask which side decides whether a move is legal, and what the frontend should do when the backend rejects a move it had already displayed. ``` #### What This Part Should Cover - A small, clear API for creating games, reading state and making moves - The backend as the source of truth for rules and turn order - Handling of repeated or conflicting requests such as double clicks or two players moving at once - Frontend states: whose turn it is, winner or draw, errors, and a way to start over ### Part 3 — Debugging and verifying with the AI in the loop Something will break while you build this. Describe how you would find and fix a bug in AI-generated code, for example the backend still accepting moves after a win, and how you would verify the finished application before saying it is done. ```hint Reproduce before re-prompting Think about the evidence you would collect before asking the tool for a fix, so you can tell whether its change addresses the cause. ``` #### What This Part Should Cover - Reproducing the bug and locating the cause rather than patching the symptom - Giving the AI precise context and reviewing its fix - A regression test for the bug - An end-to-end verification pass before declaring the application finished ### What a Strong Answer Covers - A correct, tested game first, then growth in small verified steps - Clear understanding and ownership of AI-generated code - Effective use of the tools: scoped requests with context, reviewed diffs, generated tests that are themselves checked - Server-side validation and a clean separation between rules, API and interface - Systematic debugging and concrete verification evidence, communicated while you work ### Follow-up Questions - How would you add a computer opponent that never loses, and how would you check that AI-written logic for it is correct? - How would two players in different browsers see each other's moves immediately? - What changes if the board becomes N × N with K in a row needed to win? - The AI proposes adding a state-management library you have never used. How do you decide whether to accept it?