We appreciate your interest in joining SeeClickFix's development team. As an exercise to base our conversation moving forward, please complete and submit the following command line app.
For this project, please use the programming language that you think will best illustrate your skills. For reference SeeClickFix uses Javascript, Ruby, Kotlin, Swift, and Java but you aren't required to use one of our languages.
We would like you to spend 2-3 hours on this project, don't ruin your weekend! If you run out of time, let us know what your next steps would be.
We would like you to create several versions of a command line tool as described below. The versions should be stored in a single branch such that we could check out a particular commit for each version. It isn't necessary to complete all the versions, do as much as you can in the 2-3 hours. We are more interested in high quality code than we are in how quickly you can go through the versions.
We would like to see a git commit history for each version of the command (rather than just one commit for each version). Show us how you moved from one version to the next. Commits should be constructed in a way that facilitates code review and you should aim to have a running app at every commit (not necessarily fully functional though). We would like to see a couple of tests associated with each version of the command (unit and/or integration).
Once you have completed a version, don't rebase or modify the commit history -- pretend that it has been published/shared and can't be modified. Any enhancements, refactoring, or bug fixes should show up as a subsequent commit.
Please include a README file in your repo and put any instructions on how to build/execute the command in that file.
Create a command line tool that will query our open311 API (https://seeclickfix.com/open311/v2/docs) to display service requests.
Version 1: The command should query the open311 endpoint for service requests associated with a particular account specified on the command line. For example, account 29 is New Haven. The results should be re-formatted from json to CSV including service_request_id, description, service_name fields for each request in the response written to stdout.
Tests for this version might include validating the account id or ensuring a error message is displayed if the request fails. Don't forget to add tests along the way for the new versions below.
Version 2: Geospatial query
- allow the user to indicate they want to specific lat/lng coordinates instead of an account id
- make sure the user can still query by account id if they want to
Version 3: Names instead of Numbers
- allow the user to specify a file that contains a comma separated list of account names and numbers. The user should be able to now specify an account by name or number. In addition to 29 for New Haven, other valid account numbers include: 53, 548, 549. If you look at the requests for those accounts you can infer their city name.
Version 4: Alternate output
- allow the user to specify on the command line which properties should appear in the CSV output
- allow the user to specify something other than a comma for the field separator
Version 5: Filtering
- allow the user to specify a search string and only output service requests that match the search string
Feel free to include additional features as you see fit.
You can submit the project via email (just tar up the app directory) or link us to a repo at Github/Gitlab, etc.