Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/uber-archive/coding-challenge-tools
Uber's tools team coding challenge
https://github.com/uber-archive/coding-challenge-tools
Last synced: about 1 month ago
JSON representation
Uber's tools team coding challenge
- Host: GitHub
- URL: https://github.com/uber-archive/coding-challenge-tools
- Owner: uber-archive
- Archived: true
- Created: 2013-08-01T23:39:21.000Z (over 11 years ago)
- Default Branch: master
- Last Pushed: 2016-12-19T19:17:47.000Z (about 8 years ago)
- Last Synced: 2024-04-14T12:21:57.764Z (8 months ago)
- Size: 26.4 KB
- Stars: 642
- Watchers: 2,186
- Forks: 163
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- awesome-recruitment-tests - Uber - You can work on one of the four challenges provided. (JavaScript)
README
Coding challenge or existing code?
==================================The [coding challenge](coding_challenge.md) is optional if you already have some code that you're proud of and can share with us.
Existing code
-------------If you have existing code, please follow the following guidelines:
* Include a link to the hosted repository (e.g. Github, Bitbucket...). We cannot review archives or single files.
* 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.
* Ideally, the code you're providing:
* Has been written by you alone. If not, please tell us which part you wrote and are most proud of in the README.
* Is leveraging web technologies.
* Is deployed and hosted somewhere.Readme
------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:
* Description of the problem and solution.
* Whether the solution focuses on back-end, front-end or if it's full stack.
* Reasoning behind your technical choices, including architectural.
* 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.
* Link to other code you're particularly proud of.
* Link to your resume or public profile.
* Link to to the hosted application where applicable.How we review
-------------Your application will be reviewed by at least three of our engineers. We do take into consideration your experience level.
**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.
The aspects of your code we will assess include:
* **Architecture**: how clean is the separation between the front-end and the back-end?
* **Clarity**: does the README clearly and concisely explains the problem and solution? Are technical tradeoffs explained?
* **Correctness**: does the application do what was asked? If there is anything missing, does the README explain why it is missing?
* **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?
* **Security**: are there any obvious vulnerability?
* **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?
* We're not looking for full coverage (given time constraint) but just trying to get a feel for your testing skills.
* **UX**: is the web interface understandable and pleasing to use? Is the API intuitive?
* **Technical choices**: do choices of libraries, databases, architecture etc. seem appropriate for the chosen application?Bonus point (those items are optional):
* **Scalability**: will technical choices scale well? If not, is there a discussion of those choices in the README?
* **Production-readiness**: does the code include monitoring? logging? proper error handling?Coding Challenge
----------------[Guidelines can be found here.](coding_challenge.md)