Full Stack / Backend Developer / Eng Manager Assessment
Multiplayer Conway's Game of Life

Please sign up to be eligible for up to HK$6,000 completion bonus.
This assessment awards an Intermediate level certificate.

Conway's Game of Life is a famous simulation that demonstrates cellular automaton. It is modeled as a grid with 4 simple rules:

1. Any live cell with fewer than two live neighbors dies, as if caused by under-population.
2. Any live cell with two or three live neighbors lives on to the next generation.
3. Any live cell with more than three live neighbors dies, as if by overcrowding.
4. Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.

Create a multiplayer Web app version of Game of Life, with the following functions. At minimum, you must support the latest Google Chrome desktop browser, although you may be penalized if your game doesn't work in other modern browsers. (For example, we grade using Google Chrome, but clients might open your work in Firefox or Safari.)

1. Implement the Game of Life browser frontend. You can use any representation such as <canvas>, simple DOM manipulation or even <table> cells. The game should tick automatically at a predefined interval, at say, 1 step per second.
2. The browser connects to a server, which allows multiple browsers to share the same, synchronized world view. Unless otherwise specified, the server may be written in Ruby, Node.js, or any other technology supported by Heroku. You may use any framework, e.g. Ruby on Rails, Hapi, Phoenix or just plain listening on a socket.
3. Each client is assigned a random color on initialization. From the browser, clicking on any grid will create a live cell on that grid with the client's color. This change should be synchronized across all connected clients. (You can use any mechanism to achieve this, such as polling, comet, or WebSocket.)
4. When a dead cell revives by rule #4 "Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.", it will be given a color that is the average of its neighbors (that revive it).
5. To make the evolution more interesting, include a toolbar that places some predefined patterns at random places with the player's color, such as those found at here https://en.wikipedia.org/wiki/Conway's_Game_of_Life#Examples_of_patterns (not necessary to implement all, just 3 - 4 is fine).

Skills to be graded

1. Algorithmic Programming
2. API and Service Design
3. Testing, CI/CD, and Site Reliability
4. UX Design and Prototyping
5. Web Frontend
6. Communication

If you are only applying for a Backend badge / position, please let us know and we will not grade your frontend or UX abilities. In this case, we will pretty much disregard your frontend as long as it works.

Submission

1. You can find our grading guidelines at https://t1.gl/review, including how to ask us questions.
2. Submit your solution at https://t1.gl/submit-assessment.

Pay specific attention to the following:

1. Correctness / Robustness – e.g. does it behave correctly if a client's connection is unstable for a few seconds? Can we easily build and deploy?
2. Performance / Scalability – both in client side and server side.
3. Code Style / Terseness / Proper use of latest technologies.
4. UI aesthetics.
5. Communication skills and documentation.
6. Your code must be ready to be deployed to Heroku without any issues.
7. Please spend no more than a few hours – if you run out of time, document what features are missing, and how you would approach them if you have more time.

FAQ

The description says "Each client is assigned a random color on initialization". If the client disconnects and reconnects some time in the future, do they need to keep the same color?

This is unspecified. Use your best judgment. When we grade your solution, we will also look at your engineering choices and trade-offs.

What do you mean by the average of colors?

The mathematical average is sufficient, although feel free to use other definitions of color averaging. Remember to document your choices.

How large is the playground? May I just put the width and height in the config file? Or do you need it to be full-size of the browser’s screen, or even resizable?

We have received submissions with board sizes ranging from a 10×10 board to millions of cells. Please use your best judgement. Hint: Many employers value readability and maintainability over fancy features. The choice of algorithms that are demonstrably scalable is also a big plus.

What’s the scale of the game? How many clients do you expect at the same time? Should I limit the client’s count?

We expect something that can be reasonably achieved within a few hours – we don't expect a MMO.

What's the initial state on the playground? Do we need to randomly initialize some cells? Or just leave it blank?

It is acceptable to have a blank world as the initial state.

When the predefined pattern put by a user covers an alive cell, I guess we just overwrite the cell’s color by the pattern’s color, am I correct?

This is an acceptable strategy. You may also want to put this and any other assumptions you have made that were not in the specification into the documentation.

Some parts of the spec are incomplete?

Hint: In real-world situations, you will rarely encounter a 100% complete spec. In these cases, you'll need to use your communications skills to either make reasonable assumptions or clarify with the relevant parties.

This is a game. Tell me the most attractive point of the game/the product to ensure I got the point.

The point is for you to showcase your skills and abilities while also having a bit of fun!

---

Copyright © 2016-2021 Terminal 1 Limited.