This is the Emsi API Developer technical exercise. Emsi's goal is to observe how you think about problems and write code. Rather than limiting you to whiteboarding or writing code live, we want to simulate actual working conditions as closely as possible: you are welcome to use whatever technology stack you feel most comfortable with, to search Google and StackOverflow, and to generally approach the problem however you like.
Once you've finished your implementation (which we don't expect to take more than eight hours), be sure to push it to GitHub and send us a link to the repository. The team at Emsi will review your code, then conduct a call with you to discuss it. Please include a file in the project root called INSTALL.md
which describes whatever steps we need to take to run your code and verify that it works.
In this hypothetical scenario, Emsi is working with major corporations who are looking at relocating their headquarters to more favorable cities. Each customer is different, but a data research team has identified a few key metrics and scored major U.S. metros by them. These metrics include things like overall economic growth indicators such as job growth as well as quality of life indicators such as "walkability." A frontend team is building out a web application which will be used directly by executives at client organizations to explore good options based on which metrics they value most highly. Your job is to build out the API to support the frontend application.
There are two general "flows":
- The customer wants to see how a particular city scores on all metrics.
- The customer wants to weight each available metric and see a ranked list of cities. For instance, they care very deeply about walkability and weight it as
4
, while job growth is left at a weight of1
. A city's overall score is determined by multiplying the metric value by the metric weight, then adding all metrics together. So if Chicago has a walkability score of1.7
and a jobs-growth score of2.32
, in this scenario its overall score would be1.7 x 4 + 2.32 x 1 = 9.12
.
A description of these endpoints is in doc/endpoints.md
. Data is in data/cities.json
; consider this a sample and design as if there are at least 300 cities in the full data set. If you choose to put the data into a database of some sort, make sure you script it so that we can replicate it.
- Write an API service that implements the endpoints described in
doc/endpoints.md
. - If some aspect of the spec is ambiguous, use your best judgement and document what decision you made and why.
- Sample requests and responses are supplied in
doc/endpoints.md
. You do not need to match the pretty-printing style, field order, etc. - Write a file named
INSTALL.md
which describes the steps we need to take to run your code, preferably something that works on a recent Linux release. - Push everything up to a repository on GitHub, then send us a link.
Remember to include a text file named INSTALL.md
which clearly describes how we can go about running your code, preferably on a recent Linux release.
Here are the questions that we'll ask as we look at your code:
- Does the code run and work as expected?
- Is the implementation well thought out?
- Can we understand the structure within a few minutes?
- In what ways has your implementation exceeded our expectations?