├── README.md └── coding_challenge.md /README.md: -------------------------------------------------------------------------------- 1 | Coding challenge or existing code? 2 | ================================== 3 | 4 | The [coding challenge](coding_challenge.md) is optional if you already have some code that you're proud of and can share with us. 5 | 6 | Existing code 7 | ------------- 8 | 9 | If you have existing code, please follow the following guidelines: 10 | 11 | * Include a link to the hosted repository (e.g. Github, Bitbucket...). We cannot review archives or single files. 12 | * The repo should include a README that follows the [principles described below](#readme) In particular, please make sure to include high-level explanation about what the code is doing. 13 | * Ideally, the code you're providing: 14 | * Has been written by you alone. If not, please tell us which part you wrote and are most proud of in the README. 15 | * Is leveraging web technologies. 16 | * Is deployed and hosted somewhere. 17 | 18 | Readme 19 | ------ 20 | 21 | Regardless of whether it's your own code or our coding challenge, write your README as if it was for a production service. Include the following items: 22 | 23 | * Description of the problem and solution. 24 | * Whether the solution focuses on back-end, front-end or if it's full stack. 25 | * Reasoning behind your technical choices, including architectural. 26 | * Trade-offs you might have made, anything you left out, or what you might do differently if you were to spend additional time on the project. 27 | * Link to other code you're particularly proud of. 28 | * Link to your resume or public profile. 29 | * Link to to the hosted application where applicable. 30 | 31 | How we review 32 | ------------- 33 | 34 | Your application will be reviewed by one or more of our engineers and an colleague from outside the company. We do take into consideration your experience level. 35 | 36 | **We value quality over feature-completeness**. It is fine to leave things aside provided you call them out in your project's README. The goal of this code sample is to help us identify what you consider production-ready code. You should consider this code ready for final review with your colleague, i.e. this would be the last step before deploying to production. 37 | 38 | The aspects of your code we will assess include: 39 | 40 | * **Architecture**: how clean is the separation between the front-end and the back-end? 41 | * **Clarity**: does the README clearly and concisely explains the problem and solution? Are technical tradeoffs explained? 42 | * **Correctness**: does the application do what was asked? If there is anything missing, does the README explain why it is missing? 43 | * **Code quality**: is the code simple, easy to understand, and maintainable? Are there any code smells or other red flags? Does object-oriented code follows principles such as the single responsibility principle? Is the coding style consistent with the language's guidelines? Is it consistent throughout the codebase? 44 | * **Security**: are there any obvious vulnerability? 45 | * **Testing**: how thorough are the automated tests? Will they be difficult to change if the requirements of the application were to change? Are there some unit and some integration tests? 46 | * We're not looking for full coverage (given time constraint) but just trying to get a feel for your testing skills. 47 | * **UX**: is the web interface understandable and pleasing to use? Is the API intuitive? 48 | * **Technical choices**: do choices of libraries, databases, architecture etc. seem appropriate for the chosen application? 49 | 50 | Bonus point (those items are optional): 51 | 52 | * **Scalability**: will technical choices scale well? If not, is there a discussion of those choices in the README? 53 | * **Production-readiness**: does the code include monitoring? logging? proper error handling? 54 | 55 | Coding Challenge 56 | ---------------- 57 | 58 | [Guidelines can be found here.](coding_challenge.md) 59 | -------------------------------------------------------------------------------- /coding_challenge.md: -------------------------------------------------------------------------------- 1 | Coding Challenge Guidelines 2 | =========================== 3 | 4 | If you don't have code to share, you can work on our coding challenge described 5 | below. 6 | 7 | Please organize, design, test, document and deploy your code as if it were 8 | going into production, then send us a link to the hosted repository (e.g. 9 | Github, Bitbucket...). 10 | 11 | Functional spec 12 | --------------- 13 | 14 | Prototype **one** of the following projects: 15 | 16 | 1. SF Movies 17 | 2. Email Service 18 | 3. Food Trucks 19 | 20 | The UX/UI is totally up to you. If you like, get creative and add additional 21 | features a user might find useful! 22 | 23 | 24 | ### SF Movies 25 | 26 | Create a service that shows on a map where movies have been filmed in San 27 | Francisco. The user should be able to filter the view using autocompletion 28 | search. 29 | 30 | The data is available on [DataSF](http://www.datasf.org/): [Film 31 | Locations](https://data.sfgov.org/Arts-Culture-and-Recreation-/Film-Locations-in-San-Francisco/yitu-d5am). 32 | 33 | ### Email Service 34 | 35 | Create a service that accepts the necessary information and sends emails. It 36 | should provide an abstraction between two different email service providers. 37 | If one of the services goes down, your service can quickly failover to 38 | a different provider without affecting your customers. 39 | 40 | Example Email Providers: 41 | 42 | * [SendGrid](https://sendgrid.com/user/signup) - [Simple Send Documentation](https://sendgrid.com/docs/API_Reference/Web_API/mail.html) 43 | * [Mailgun](http://www.mailgun.com) - [Simple Send Documentation](http://documentation.mailgun.com/quickstart.html#sending-messages) 44 | * [Mandrill](https://mandrillapp.com) - [Simple Send Documentation](https://mandrillapp.com/api/docs/messages.JSON.html#method-send) 45 | * [Amazon SES](http://aws.amazon.com/ses/) - [Simple Send Documentation](http://docs.aws.amazon.com/ses/latest/APIReference/API_SendEmail.html) 46 | 47 | All listed services are free to try and are pretty painless to sign up for, so 48 | please register your own test accounts on each. 49 | 50 | ### Food Trucks 51 | 52 | Create a service that tells the user what types of food trucks might be found 53 | near a specific location on a map. 54 | 55 | The data is available on [DataSF](http://www.datasf.org/): [Food 56 | Trucks](https://data.sfgov.org/Permitting/Mobile-Food-Facility-Permit/rqzj-sfat) 57 | 58 | Technical spec 59 | -------------- 60 | 61 | The architecture will be split between a back-end and a web front-end, for 62 | instance providing a JSON in/out RESTful API. Feel free to use any other 63 | technologies provided that the general client/service architecture is 64 | respected. 65 | 66 | Choose **one** of the following technical tracks that best suits your skillset: 67 | 68 | 1. **Full-stack**: include both front-end and back-end. 69 | 2. **Back-end track**: include a minimal front-end (e.g. a static view or API 70 | docs). Write, document and test your API as if it will be used by other 71 | services. 72 | 3. **Front-end track**: include a minimal back-end, or use the data service 73 | directly. Focus on making the interface as polished as possible. 74 | 75 | ### Back-end 76 | 77 | We believe there is no one-size-fits-all technology. Good engineering is about 78 | using the right tool for the right job, and constantly learning about them. 79 | Therefore, feel free to mention in your `README` how much experience you have 80 | with the technical stack you choose, we will take note of that when reviewing 81 | your challenge. 82 | 83 | Here are some technologies we are more familiar with: 84 | 85 | * Python 86 | * JavaScript 87 | * Java 88 | * Ruby 89 | * PHP 90 | * Go 91 | 92 | You are also free to use any web framework. If you choose to use a framework 93 | that results in boilerplate code in the repository, please detail in your 94 | README which code was written by you (as opposed to generated code). 95 | 96 | ### Front-end 97 | 98 | The front-end should ideally be a single page app with a single `index.html` 99 | linking to external JS/CSS/etc. You may take this opportunity to demonstrate 100 | your CSS3 or HTML5 knowledge. 101 | 102 | Host it! 103 | -------- 104 | 105 | When you’re done, host it somewhere (e.g. on Amazon EC2, Heroku, Google AppEngine, etc.). 106 | 107 | How will we review? 108 | ------------------- 109 | 110 | [Guidelines can be found here](https://github.com/shellypalmer/coding-challenge/blob/master/README.md) 111 | --------------------------------------------------------------------------------