---
GA: UA-83160642-4
tags: t1.gl/Public, t1.gl/Assessments
---
# #2Assessments - Assessment Submission and Review Guidelines
:::warning
:warning: You **MUST** submit your assessment [**→ here ←**](https://t1.gl/submit-assessment).
:::
## Existing Code
Among other criteria, we would be assessing functionality, code quality, architecture, documentation, and testing. Please follow the following guidelines:
* Include a link to the hosted GitHub or Bitbucket repository. We cannot review archives or single files.
* Produce beautiful and *maintainable* code. You may wish to spend a few moments thinking of how another developer may wish to extend your work. Prioritize quality over feature completeness.
* Unless otherwise noted, your code must be ready to be deployed:
* For Web applications, to [Heroku](https://heroku.com) (or a similar free/cheap PaaS deployment tool like [Netlify](https://www.netlify.com/)) with no issues.
* For mobile apps, ready to be installed on to a mobile device.
* The repo should include a README file that follows the [principles described below](#README). In particular, please make sure to include high-level explanation about what the code is doing and a problem statement.
* 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 current technologies.
* Is deployed and hosted somewhere (unless otherwise noted).
## README
Regardless of whether it's your own code or our coding challenge, write your README as if it was for a production service and the only document available for other developers. Include the following items:
* Description of the problem and solution.
* How to test/build/deploy/use your solution. Link to the hosted application if applicable (heroku/netlify).
* 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 projects or code you're particularly proud of.
The easier it is to understand your code the better grade it would have.
## How We Review
Your application will be reviewed by at least one of our engineers.
**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 *quality 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. Review [common mistakes](#Common-mistakes).
Terminal 1 grades essential skills in every assessment by categories, including architecture, code quality, documentation, testing and user experience.
#### Skill Grading Levels
We assign levels to each assessed skill (could be interpreted as a seniority level).
| Level | Icon | Notes |
|---|---|---|
| 0 |  | No knowledge of the skill, everyone who attempts the challenge gets this level. |
| 1 |  | Basic knowledge of the skill, could be awarded via online course completion or certification. Would be the main skill for junior positions. |
| 2 |  | Good knowledge of the skill. Approximately 200-800 hours dedicated directly to the skill mastering or 3-5 years of job experience. Only 10% of people get to this level. |
| 3 |  | Senior/Lead level with typically 5-10 years of experience. This is a high mark achieved by 3% of people. |
#### Skill assessment criteria
Terminal 1 uses predefined criteria to qualify candidates for every skill level. A full list of grading criteria could be found in our [library](https://www.tty1.co/skills).
For example, to be awarded level 2 in "API and Service Design", a candidate needs to show the ability to 1) architect scalable solutions, including sync/async responses, web sockets, caching and 2) implement common API protocol in the assignment.
| Category | Description |
| --- | --- |
| Architecture | How clean is the separation between the front-end and the back-end? Are choices of libraries, databases, tools etc. appropriate for the chosen application? |
| Communication | Does the README clearly and concisely explain the problem, solution, and areas for review? Are choices, remaining TODOs, and technical tradeoffs explored and explained? Was there clear communication and expectation setting with us during the process? |
| Code Quality | Is the code simple, easy to understand/extend, reuseable and maintainable? Would it pass a code review? Are there any code smells or other red flags? Is the coding style consistent with the language's guidelines? Is it consistent throughout the codebase? Is there good logging? Is it easy to debug? |
| Functionality | Does the application do what was asked? If there is anything missing, does the README explain why it is missing? You **will** gain extra points if you go above and beyond in implementing additional **helpful** features. Think carefully about the intended user. |
| Security | Are there any obvious vulnerability? |
| Testing Skills | 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 constraints) but trying to get a feel for your testing skills. |
| UX | Is the web interface understandable and pleasing to use? Is the API intuitive? |
We will assign a grade to each category:
| Grade | Description |
| --- | --- |
| F | Category is missing or a failure. |
| D | Major/minor complaints about a category. |
| C | Passing in a category; nothing major to complain about. |
| B | We're impressed. Something clever happened. |
| A | World-class solution. Exceptional. |
We also might award **optional** bonus points at our discretion. For example:
| Weight | Aspect | Description |
| --- | --- | --- |
| V. Low | Scalability | Will technical choices scale well? If not, is there a discussion of those choices in the README? |
| V. Low | Production-readiness | Does the code include monitoring? Proper error handling? Is it deployable as is? |
We will average your scores together according to weight to derive a final submission score. Receiving a **C** on our assessments (which are quite difficult) is considered impressive.
## Submission
Hit the deadline you assign yourself with all requirements met. Before submission, please read the grading criteria carefully and ensure your application is the best you can do in each category. **With your submission, please submit a suggested grade for each category with justification notes.** We will only use your rubric to ensure we didn't miss any parts of how you thought about the assignment.
Please show your best work when you submit. If there are problems with your submission, you will be allowed one minor edit.
:warning: Submit your final deliverable at https://t1.gl/submit-assessment.
Please send any questions to <<a href='mailto:2assessments@terminal1.co'>2assessments@terminal1.co</a>>. Almost all assessments test your communication skills, so please clear up any ambiguities with us.
### Common Mistakes
1. Missing documentation, tests or solution.
2. Project does not work (execution command raises an exception) or tests fail.
3. Provided solution does not solve the problem.
4. Poor knowledge of version control systems:
* Source code (if applicable) is not under version control.
* Temporary/redundant/binary files (`.DS_Store`, `.idea`, `.vscode`) are in repository or result archive. Choose a good [.gitignore](https://gist.github.com/octocat/9257657).
5. Underestimation of quality standards. We would carefully assess your submission including commit messages, code comments, redundant/comented code blocks, code style and mention them in the report.
## FAQ
### You say getting a "C" is impressive. How could you tell the difference between a junior and senior developer? If they both do the same challenge, can I assume a junior getting a C means *impressive* while a senior getting a C means *not impressive*?
For seniors we naturally take into account their level of experience and expect more. We'll ask them to aim for a B but also understand if they're under more time constraints (e.g. family).
We strongly suggest they utilize their greater experience to score more points in the **communication** category (e.g. better understanding and documentation of architecture and tradeoffs, what they'd do with more time).
We would expect average for seniors should be **C/B**.
### How will you grade challenges involving a data science model?
* Model quality: ideally looking for something more than scikit-learn. We would check model's performance and techniques used.
* Code quality: should be easy to read by others, have modules and helper functions, redundant code should be eliminated.
* Result presentation and visual component of the submission.
* Business approach, architecture and scalability.
### If you found problems in my code and asked me to resubmit, how much change from the original submission is allowed?
This is at our discretion, but a rule of thumb is no more than 10% of the code.
### If I failed the assessment, can I redo it again?
If you wish to do the same assessment, you may retry and resubmit 3 months after your previous submission. Alternatively, our engineers may recommend you to try another one of our assessments.
## Attribution
Some of these review guidelines are originally forked from [Uber](https://github.com/uber/coding-challenge-tools).
## Other materials
* [How to ace your technical challenge (Reality Check + 7 Tips)](https://medium.com/terminal-1/how-to-ace-your-non-hackerrank-technical-challenge-reality-check-6-tips-64c4679dd879)
* [How to prepare to HackerRank challenge](https://medium.com/terminal-1/10-things-to-do-to-get-closer-to-your-dream-job-how-to-beat-the-hackerrank-challenge-4984a461da51)
---
Copyright (c) 2016-2020 Terminal 1 Limited.
{%hackmd hp8GBradSpO0m-MA4UKFRg %}
Sign in with Wallet
Connect another wallet