Copilot Engineering Interview - Take Home

Context

Copilot wants to provide a customer facing API. The customer facing API allows customers to access their workspace data in external systems. One of the main resources is the client resource. This resource represents a client user in a customer’s portal. Every portal has a set of clients which are used in various apps likes requesting a contracts, sharing a file, sending an invoice etc. E.g. Bob’s Law firm has a portal with several clients and Jane’s Accounting firm has a separate portal with their own clients. Each of these portal owners can use the customer facing API to manage their clients. At a high level the Copilot system has the following data model

Assignment

For this exercise our objective is to create an API that can perform the basic CRUD operations for the client resource. These are the following attributes that we want the client resource to support. This is not an exhaustive list and you can add more attributes if you need for your design.

Name	Description
givenName	The client’s given name (First name)
familyName	The client’s family name (Last name)
email	The client's email
companyId	The ID of the company this client is assigned to. Companies are a way to group clients that work together. E.g. Bob who has a portal with Copilot might serve individual clients or companies that consistent of a set of clients. Every client will always have a company. If no company is provided when a client is being created then a placeholder company should be created.
status	The status of the client, one of `inactive`, `invited` or `active`. This property cannot be set via the api and is determined on the backend.
visibility	The list of internal users id that are allowed to view this client. This is a way to restrict permissions for users. Internal users are the individuals that run the business. E.g. Bob’s Law Firm might have three partners: Bob, Bill, and Brad that work with many clients.
customFields	A map containing additional properties. The key is the `id` of the custom field property and the value is the client’s custom field value.

Notes

Limit yourself to 3-4 hours
Focus on getting some e2e flow working.
- It’s not necessary to spin up a full db or persistence layer. Some mocked persistence interface that can track items while the app is running is sufficient.
Focus on the pieces that you think are most important to cover. E.g. you might only be able to implement one endpoint but have a lot of functionality covered in that, or you might have a few endpoints with support for a only a few attributes
The custom fields is a special property that allows every portal to create their unique fields for their clients. Portal owners have the ability to define custom properties they want to track and are able to set those values for their clients. These custom fields can also have different types e.g. string, number, list, etc. Some examples would be phone number, address, favorite colors. For this exercise you do not need to implement the ability to create or manage these custom fields and you can have some hard-coded data.
Here is an example of the custom field metadata that might be part of a workspace

Submission

We ask that you share a Private Github repository of your implementation.

Please invite @makeitraina with Write access.
Please provide instructions in the ReadMe on how to run your app and call endpoints.

Evaluation

We will be running your app and calling the endpoints that you implemented to verify the basic behavior and validate various scenarios.
We will review your code to understand the implementation details. We care that you can design for correctness, simplicity and readability

Context

Assignment

Notes

Submission

Evaluation

Next steps: