This is how Backend Projects are evaluated.
Each submission must contain the following, if these are not included, the submission is not considered in the review.
Source code full source code of the application, excluding any Binaries or generated files (any thing that should be .gitignored, like libs, packages, exe, obj)
Readme.md at the root of the source code explains the following:
installation steps, dependencies (Node, etc)
running steps, commands, etc
automated testing steps, commands, etc
information about important decisions made during the implementation.
All files should be zipped in 1 file called username_submission.zip, and uploaded in the submission form.
If the code is shared on Github (or any other online repository) publically, it will not be accepted and your submission will be disqualified.
Do not use public or open source repositories to write or share your code.
Total score is 100 points. A submission must score 80 points to be considered for a cash prize. Highest score above the minimum required score wins the first place, then the second, etc.
The following list shows the weight of each criteria in scoring the submissions:
Functional Requirements [50 points]
Non-Functional Requirements [30 points]
Testing [15 points]
Deployment [5 points]
Technical Requirements (Pass/Fail)
Fail = Code uses the wrong programming language or framework or database, etc. or violates any specific requirements in the technology section.
Pass = Code honors the technology requirements and compatible with all the technical requirements.
Use-cases and Functional Requirements
Code meets all the required features and use cases (10 points per feature count)
No Bugs, Code covers detailed logical scenarios and implements the business logic and checks (5 points - for 0 to 10 bugs)
Code Style and Practices (2 points)
0 = Code does not follow the best practices.
1 = Follows best practices with some issues or spelling mistakes or confusing naming conventions.
2 = Clean code and strict adherence to best practices.
Maintainability and Design (2 points)
0 = Code has very poor design with large amount of code-smells, and anti-patterns.
1 = Code is maintainable with minor code-smells
2 = Code is clean and maintainable, follows SOLID principals (or other acceptable patterns)
Readability: Comments and Documentation (2 points)
0 = No comments or unclear comments
1 = Some useful comments provided, but missing in areas or redundant on self-explaining code.
2 = Comments provided and they are clear, and help understanding the whole codebase.
Traceability and Observability (2 points)
0 = The code has no logging or very poor attention to tracing.
1 = Logs are printed but are not organized or excessive (leak information) or not descriptive enough.
2 = Clear useful trace log messages, with clear severity, and contexts are provided in the message.
Security (2 points)
0 = No attention to security or confidentiality of data handled. and no validation of user input.
1 = Some attention to security but poor implementation, or not enough handling of input.
2 = Good attention to security of data (like passwords or keys), encryption, with attention to input validation and privileges, and secure communication between modules or external systems.
Performance (2 points)
0 = Poor performance with timeouts, hangs or crashes or has excessive use of resources.
1 = Good performance, but not be scalable with large datasets or will consume heavy resources.
2 = Good performance with attention to scalability and resource and IO constraints.
Automated Test Coverage (3 points)
0 = No test cases, or 50% of the features were not covered
1 = Test cases do not cover 25% of the system
2 = Test cases cover all use cases except minor edge cases.
3 = Covers all features
Test Cases Success (3 points)
0 < 70% pass
1 > 80% pass
2 > 90% pass
3 = 100% pass
Code runs and works correctly when deployed to a server (3 points)
0 = Code fails to run or does not compile for the specified language
1 = Code runs but fails in one of the scenarios locally, or requires manual preparations like importing a database or manual data entry. (use database seeding and migrations)
2 = Code runs but fails on the server due to permissions or other server specific cases
3 = Code runs correctly on the server
Unless explicitly declared in the quest project page by the client, you can only use Free, Open Source Libraries following a permissive license including:
MIT License
ISC License
BSD 3-Clause License
GNU Lesser General Public License v3 - LGPL (Exclusively as external libraries)
Apache License 2.0
Copyleft licenses (OSL, GPL, AGPL, MPL, etc) are not allowed for commercial Quests unless specified by in the requirements.
Copying existing code from the internet or Github without its proper licence is prohibited. Submissions are screened for copyright infringement.