Submission guidelines
Everything you need to know before you submit a build. Read these once, and your submission won't get held up on a technicality.
Submission Format
GitHub Repository is mandatory. All code, documentation, and assets must be committed to a public GitHub repository.
No other forms of submission (ZIP, email, forms) are accepted.
If you're working in a team, the repo owner must make the submission.
Contributions of all team members will be evaluated based on their commits and GitHub activity.
Make sure everyone has meaningful, verifiable contributions.
Repository Requirements
Your submitted GitHub repository must include:
Your README.md Should Include:
What your project does
How to set it up and run it
Cool features you've built
Screenshots or demo (if you have them)
Proper documentation for any major logic, APIs, or flows
All required files and assets within the repository itself (no external links)
Code Quality Standards
Write code like you're building something real that people will use:
Write clean, understandable, and modular code
Use consistent formatting and naming conventions
Comment non-trivial or complex logic clearly
Avoid unnecessary bloat or unused code
Ensure the application works as described, without errors
Deadlines & Commit Policy
You can submit any time before the deadline.
You can continue committing after submitting, as long as it's before the deadline.
The deadline rule
Any code pushed after the deadline = automatic disqualification. No exceptions!
You can only update documentation (README, comments) after the deadline.
No code changes, no new features, no bug fixes after time's up!
Do not share your code with others — if we detect similar or reused submissions, all involved parties will be disqualified.
Important: What Not To Do
Plagiarism is not tolerated. Directly copying from other open-source repositories, AI tools, or public codebases without meaningful understanding will result in instant rejection.
Excessive or low-effort usage of AI (e.g., entire files clearly generated and unchecked) will also be flagged.
Private repositories will be rejected automatically. Ensure your repo is public at all times.
How We Evaluate Your Work
Here's what we look for when reviewing your work:
Functionality & Completeness – Does the solution solve the problem fully?
Code Quality & Best Practices – Is the code clean, structured, and well-documented?
User Experience & Interface – Is the product intuitive and usable?
Innovation & Thought Process – Did you bring originality or a smart approach?
Teamwork (if applicable) – Are all members meaningfully involved?
Feedback Process
If your project is rejected, you will receive brief reviewer feedback explaining why.
If it is accepted, you'll hear from us in the results timeline.
Final Reminders
Remember
No edits are allowed after the deadline – make sure your submission is final.
No excuses will be accepted for private repos, missed deadlines, or accidental pushes.
Read this twice before submitting. You only get one shot.
That's everything.
Take your time, build something you'd be proud to show a senior engineer, and push it before the deadline.