For this interview we'll be building a lightweight CRUD app. We'll start by creating some system diagrams and wireframes then build out a server and client.
The application is called Pokedéx.io (we use .io because it's a brilliant startup).
We have some basic functional requirements for this application:
- We will list Pokémon on a page. We'll pull from the Pokeapi (https://pokeapi.co/) to get this list.
- Users can create an account and login. They can authenticate using email & password, Oauth with Google, or the slick new magic link strategy! Up to you!
- Once authenticated, users can capture Pokémon. Next to each Pokémon in the list, there will be a capture button. When capturing a Pokémon, the user will be given the oppurtunity to name the capture and add a note. A user can retroactively update this name and note. Captures must be persisted and users cannot capture a Pokémon more than once.
We also have some fun features that we'd like to diagram (but not build):
- A public link that can be shared to display which Pokémon you've captured. This can be enabled/disabled by the user.
- Invite others users by email to join your team. Users can list their team members and see their captures!
For the first part of this interview, we'll use Whimsical (or your favorite flowchart/wireframing tool du jour) to diagram the architecture of our Pokedéx app!
First, we'll create some system diagram to describe how we'll organize our application and its data. This can look like an ERD diagram, or a flowchart, or just some bullet points! However we feel is best to communicate the architecture to other devs.
Secondly, we'll sketch some supppper rough wireframes so we can see how data will displayed to the users. Let's just answer the basic questions of:
- How does a user list Pokémon?
- How does a user sign up/sign in/sign out?
- How does a user capture a Pokémon?
- How does a user update a capture's name and note?
Some things we'd like to thing about in our diagramming exercise (No right or wrong answers here, just stuff we'll chat about!):
- Security — Pokémon captures are sensative information! We don't want to expose users' captures (or any of their info for that matter) to the public, unless explicitly told to. Let's think about how we can architect an app that is safe and secure!
- Data Requirements — For the sake of this exercise, let's just fetch the first page of Pokémon from the Pokeapi. However, let's think about how pagination will effect this application downstream.
- Scalability/Futureproofing — As we make decisions, let's think about the implications that they have as we grow the application. We're not keen on overengineering, but always keep an eye towards the future! Let's think about scalability as we decide where in application data is fetched from, how things are persisted, etc.
Also, we'd love to save a bit of time at the end to brainstorm some other cool ideas you may have for the Pokédex app!
For the second part of this interview, we'll write some code. It's ultimately up to the interviewee as to what part of the system they'd like to work on, but we generally prefer to see backend code, and database work here. The team should have a conversation about what makes the most sense to tackle during the session.
There are no real rules here, but things we like are:
- Simplicity — We'd prefer a less than perfect solution over time spent wrestling technologies.
- Testability — We prefer code that is easily tested and easy to understand, over code that is heavily abstracted.
Although we have high hopes of our Pokédex application becoming a unicorn, it's totally okay if we're not feature-complete by the end this interview! We're much more interested in learning about your process!