I started off by describing two big picture approaches: peer-to-server-to-peer and peer-to-peer (which would still require a server in the middle simply to set up games between two players). After a minute I decided on the peer-to-server-to-peer approach as the changing network address and availability would make peer-to-peer potentially very problematic. I then utilized the whole white board to draw out potential screens on a smart phone client (this overall architecture would be platform agnostic; i.e. good for iPhone or Android or whatever) The first screen of the application might be a registration screen (the fields would be username, email address, password, confirm password) with two buttons, one for "register" and the other for "login". The second screen would be the login screen (username or e-mail and password) plus a login and register button to flip back to the register view. These two views can be (and actually should have been) flipped, in that the much more seen & utilized login screen would be first. The second screen would be a "Possible Games?" screen. There'd be a table with available players (touching one would start up a game) and also an "I'm available!" button (which simply makes this player available in the "available players" table on other devices). The third screen would be the actual Tic-Tac-Toe grid, along with a "_____'s turn" label (my turn or the other player's turn?). Lastly, a "You Win!" and "You Lose!" screen and possibly a score to make things fun (i.e. higher score for faster solutions or less turns?). Next up, I described to my interviewer the possible web service API's for each screen. Screens 1.1 & 1.2 (the registration and login screens) would have a LoginUser or RegisterUser API. In my implementation I would have done HTTP Posts with JSON data going up and down. Screen 2 would have had at least three API's: potentialGames (to list the values in the "AvailablePlayer" table; possibly being polled or refreshed every X seconds), ImAvailable (to make myself available as a player) and StartGame (which would contain an unique ID of the player we want to play with, along with who we are… our player ID, and if we want to be X or O). This would fire off push notifications to the receiving (other) player which would bring up an alert and/or push his/her screen from Screen 2 ("Possible Games") to Screen 3 ("The Grid"). Each move would fire a push notification to the opposing player, which would bring up an alert ("there's a move in the game!") or add an X or O silently if the game is already in the foreground. The server would keep track of analyzing the game board, although the client could do some sanity checks as well. There would have to be at least three tables for the server in the middle. The first table would be for all registered users (username, e-mail address, hashed password, player/session ID which only gets filled in while the player is available or an active game is going on). The second table would be for Players-Who-Want-To-Play (containing their player or session ID's… in my implementation player ID and session ID are the same thing and interchangeable). The last table would be the "Games Being Played" table, which would contain the two player ID's and the overall grid. One thing I don't recall detailing to my interviewer was how the last table would be modified or added to with each game move, so he might have dinged me on this lack of detail.