Hi there!

If you're reading this, it means you're now at the coding exercise step of the engineering hiring process. We're really happy that you made it here and super appreciative of your time!

In this exercise you're asked to create a Phoenix application and implement some features on it.

💡 The Phoenix application is an API

If you have any questions, don't hesitate to reach out directly to [email protected].

• It should be production-ready code - the code will show us how you ship things to production and be a mirror of your craft.
  • Just to be extra clear: We don't actually expect you to deploy it somewhere or build a release. It's meant as a statement regarding the quality of the solution.
• Take whatever time you need - we won’t look at start/end dates, you have a life besides this and we respect that! Moreover, if there is something you had to leave incomplete or there is a better solution you would implement but couldn’t due to personal time constraints, please try to walk us through your thought process or any missing parts, using the “Implementation Details” section below.

A phoenix app with 2 endpoints to manage users.

We don’t expect you to implement authentication and authorization but your final solution should assume it will be deployed to production and the data will be consumed by a Single Page Application that runs on customer’s browsers.

To save you some setup time we prepared this repo with a phoenix app that you can use to develop your solution. Alternatively, you can also generate a new phoenix project.

• We should store users and salaries in PostgreSQL database.
• Each user has a name and can have multiple salaries.
• Each salary should have a currency.
• Every field defined above should be required.
• One user should at most have 1 salary active at a given time.
• All endpoints should return JSON.
• A readme file with instructions on how to run the app.

• mix ecto.setup should create database tables, and seed the database with 20k users, for each user it should create 2 salaries with random amounts/currencies.
• The status of each salary should also be random, allowing for users without any active salary and for users with just 1 active salary.
• Must use 4 or more different currencies. Eg: USD, EUR, JPY and GBP.
• Users’ name can be random or populated from the result of calling list_names/0 defined in the following library: https://github.com/remotecom/be_challengex

1. 📄 Implement an endpoint to provide a list of users and their salaries

   • Each user should return their name and active salary.
   • Some users might have been offboarded (offboarding functionality should be considered out of the scope for this exercise) so it’s possible that all salaries that belong to a user are inactive. In those cases, the endpoint is supposed to return the salary that was active most recently.
   • This endpoint should support filtering by partial user name and order by user name.
   • Endpoint: GET /users

2. 📬 Implement an endpoint that sends an email to all users with active salaries

   • The action of sending the email must use Remote’s Challenge lib: https://github.com/remotecom/be_challengex
   • ⚠️ This library doesn’t actually send any email so you don’t necessarily need internet access to work on your challenge.
   • Endpoint: POST /invite-users

• You can use the "Implementation Details" section to explain some decisions/shortcomings of your implementation.
• Open a Pull Request in this repo and send the link to [email protected].
• You can also send some feedback about this exercise. Was it too big/short? Boring? Let us know!

You will need the following installed:

• Elixir >= 1.14
• Postgres >= 14.5

Check out the .tool-versions file for a concrete version combination we ran the application with. Using asdf you could install their plugins and them via asdf install.

• Run mix setup to install, setup dependencies and setup the database
• Start Phoenix endpoint with mix phx.server or inside IEx with iex -S mix phx.server

Now you can visit localhost:4000 from your browser.

This section is for you to fill in with any decisions you made that may be relevant. You can also change this README to fit your needs.

• With auth I've implemented signup/in/out and didn't include the update pass/user due to personal time constraints.