This is a Python 2.7 based project; once the Local Setup Instructions have been complete the API will be available at: http://127.0.0.1:5000

The following instructions assume you are using a OSX machine and have Homebrew, Python and Virtualenv installed. Additionally it's recommended that you use PyCharm for development, because it's awesome.

From the project directory run:

virtualenv venv
source venv/bin/activate
pip install -r requirements.txt

# Install Postgresql via Brew
brew doctor
brew update
brew install postgresql
# Startup Postgresql
brew services start postgresql
# Create required databases
createdb `whoami`	# Must be run first to initialize Postgresql
createdb 9dt
createdb 9dt_test
# Create DB Tables defined in code
python database.py

From the project directory run:

python app.py

From the project directory run:

nosetests

Drop Token takes place on a 4x4 grid. A token is dropped along a column and said token goes to the lowest unoccupied row of the board. A player wins when they have 4 tokens next to each other either along a row, in a column, or on a diagonal. If the board is filled, and nobody has won then the game is a draw. Each player takes a turn, starting with player 1, until the game reaches either win or draw. If a player tries to put a token in a column that is already full, that results in an error state, and the player must play again until the play a valid move.

• Each game is between k = 2 individuals, basic board size is 4x4 (number of columns x number of rows)
• A player can quit a game at every moment while the game is still in progress. The game will continue as long as there are 2 or more active players and the game is not done. In case only a single player is left, that player is considered the winner.
• The backend should validate that a move move is valid (it's the player's turn, column is not already full)
• The backend should identify a winning state.
• Multiple games may be running at the same time.

• Output

 { "games" : ["gameid1", "gameid2"] }

• Status codes

* 200 - OK. On success

• Input:

{ "players": ["player1", "player2"],
  "columns": 4,
  "rows": 4
}

• Output:

{ "gameId": "some_string_token"}

• Status codes

  • 200 - OK. On success
  • 400 - Malformed request

• output:

{ "players" : ["player1", "player2"], # Initial list of players.
  "state": "DONE/IN_PROGRESS",
  "winner": "player1", # in case of draw, winner will be null, state will be DONE.
                       # in case game is still in progess, key should not exist.
}

• Status codes

  • 200 - OK. On success
  • 400 - Malformed request
  • 404 - Game/moves not found.

Optional Query parameters: GET /drop_token/{gameId}/moves?start=0&until=1.

• Output:

{
  "moves": [{"type": "MOVE", "player": "player1", "column":1}, {"type": "QUIT", "player": "player2"}]
}

• Status codes

  • 200 - OK. On success
  • 400 - Malformed request
  • 404 - Game/moves not found.

• Input:

{
 "column" : 2
}

• Output:

{
  "move": "{gameId}/moves/{move_number}"
}

• Status codes

  • 200 - OK. On success
  • 400 - Malformed input. Illegal move
  • 404 - Game not found or player is not a part of it.
  • 409 - Player tried to post when it's not their turn.

• Output:

{
  "type" : "MOVE",
  "player": "player1",
  "column": 2
}

• Status codes

  • 200 - OK. On success
  • 400 - Malformed request
  • 404 - Game/moves not found.

• Status codes

  • 202 - OK. On success
  • 404 - Game not found or player is not a part of it.
  • 410 - Game is already in DONE state.

After we receive your submission we will conduct a code review and execute our suite of integration tests that assert the correctness of the API. Through the course of our review and testing we will assess your implementation on several different criteria:

• Correctness: Does your API adhere to the specification
• Robustness: Does your implementation handle malformed, edge case, or fuzzed input without failing and while returning meaningful messages on the cause of the failure?
• Readability: Can an engineer unfamiliar with your implementation read and understand what you wrote with sufficient depth to make modifications? This criteria speaks to style, naming conventions, organization, and comments.
• Scalability: Will your solution perform under stress of hundreds-to-thousands of games.

On the day of your on-site interview you will present your solution to 2-3 members of the engineering team. You should prepare to talk about your implementation approach, design trade offs and approach to testing and validation.

Through the course of the one-on-one interviews we will ask you further questions about how you would extend your service implementation and how you would fix any issues we find in our own testing to improve your solution.

Please submit your source code and instructions for building/running it to your 98point6 contact.

To submit the source code, the preferred way is to share a Github or BitBucket repository with us. Alternatively, we can accept compressed tarballs or zip archives. We cannot accept those over email, though, so we recommend a file sharing service like Google Drive, Dropbox, or similar.

Please submit your solution by 12pm (noon) the day before your interview.

A starting point shim for your code is provided in the hope it will reduce boiler-plate code and some ramp-up in unknown technologies. Feel free to use/ignore it.

If you choose not to use the provided shim, you must provide a thorough instructions on how to setup and run your service. We are experienced developers, but we may not be familiar with the tools or languages you used, so please draft the instructions accordingly.

For .NET solutions, we will compile and run your code using mono.