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.
Your application will be reviewed by at least two 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?
- Technical choices: do choices of libraries, databases, architecture etc. seem appropriate for the chosen application?
Bonus point (those items are optional):
- UX: is the web interface understandable and pleasing to use? Is the API intuitive?
- 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?