Hello! First of all, thanks for taking the time to do our case study. We're looking forward to seeing what you're able to do and having an in-depth technical discussion afterwards.
This case study servers as the foundation of a good & results-driven interview process, to help ensure we can onboard technical talent as quickly as possible.
- Please use either
node,ruby on rails, orgolangfor implementing a solution to this case forTask 1andsvelteorreactfor implementingTask 2 - From receipt of this case, you have 2 hours to get as far as you can, and email your solution back to us.
- Please do not hesitate to reach out to us during the assessment if you have any questions
- Please choose one of the two tasks to focus on
To help you focus on solving the tasks below, we've provided some base setups, so you don't need to spend time on them.
- There are backends provided in
node,ruby on rails, andgolang, that have connections to apostgresdatabase, and CRUD endpoints implemented forusersandgroups. - There are frontends provided in
svelteandreact, that you can continue to build upon
Many systems have to deal with users & groups, and their interactions between them. Ours is no different, so it's your task to design & implement a system for doing so. We'd like to see (at a minimum) the ability to do the following via API endpoints:
- Add, remove, & list members of a group
- Check if a member is within a group heirarchy
- Get all members within a group heirarchy
One important note:
In our system, a group member can be either a user or another group (hence the aforementioned "group heirarchy" points). Example:
Europe (Group)
├── Denmark (Group)
│ ├── Product (Group)
│ ├── Finance (Group)
│ ├── Tom (User)
│ └── Mark (User)
│
├── Germany (Group)
│ ├── Sales (Group)
│ ├── Karen (User)
│ └── Fritz (User)
│
└── Sweden (Group)Many systems have to deal with users & groups, and visualize how they are displayed & interacted with. Please implement an interface that can list, create, update, and delete users and groups. Use your creativity to show off design & UX patterns that you believe are important.
All possible backends have CRUD endpoints implemented for both users & groups, so feel free to select whichever one you want. The routes are accessible at:
There are a number of other areas that are also interesting to see your thoughts & methodologies around, including but not limited to:
- Testing
- Documentation
- Scaling strategies
- Multitenancy architectures
- CI/CD strategies
- Make sure you have
dockerinstalled on your machine - Open the
docker-compose.ymlfile, and uncomment either thenode,rails, orgolangsection, depending on which backend languge you'd like to do the case in, and uncomment eithersvelte-frontendorreact-frontend, depending on which frontend language you'd like to work in. - Run
docker compose up --build
And that should be it! You should be able to access the api server at http://localhost:3000 regardless of which language you've chosen and the frontend server at http://localhost:5173.
All images have been setup with live reloading enabled. This means that your changes to the files on your local computer should take immediate effect inside the running docker image, and you don't need to restart the server.
There is a connection to a PostgreSQL database already set up & ready for usage. 2 tables are already created, and you can add more either via your chosen language or modifying the init_schema.sql file and then calling docker compose down to remove the database and then docker compose up --build to recreate it.
You can access the terminal where the server is running via the command:
- Node:
docker compose exec node ash - Ruby:
docker compose exec rails bash - Golang:
docker compose exec golang ash - Svelte:
docker compose exec svelte-frontend ash - React:
docker compose exec react-frontend ash
The Rails server has been configured & set up in "API Mode". This means that the assest pipeline & views portions have not been included, and we do not recommend spending time trying to get it working. Please use the react or svelte frontends instead.
Originally designed by Philip Hansen phil@simplerqms.com
Last updated Jan. 9, 2024