prove(it);
We believe the best way to show what you can do is to actually do it. This open challenge is for developers who are starting their careers and want to join MindShore. No resume. No cover letter. Just a pull request.
What is this challenge?
It is a small, real-world coding problem hosted on GitHub. We use it to get to know how you think, how you structure solutions, and how you communicate through code. It is not a trick question or a competitive exam. It is a conversation starter; written in your favorite language.
Open to everyone
No invitation needed. The repo is public. If you are a junior developer or trainee anywhere in LATAM, this is for you.
Work at your own pace
There is no timer. Take the time you need to write something you are proud of. Quality matters more than speed.
You will get feedback
Every submission gets a code review from our engineering team. Whether or not it leads to an offer, you will learn something.
How it works
Five steps. All on GitHub. No forms to fill, no PDFs to upload.
Fork the repo
Go to the GitHub repository and fork it into your own account.
Read the brief
The README explains the problem, constraints, and what we expect to see.
Build your solution
Write clean, working code. Use the language and tools you know best.
Open a pull request
Submit your work as a PR against the original repo. Include a short description of your approach.
Get reviewed
Our engineers will review your code and reach out with feedback within a few days.
What we look for
We are not looking for perfection. We are looking for signal: how you think, how you organize, and how you communicate through code.
Code structure
Is the code organized in a way that is easy to follow? Naming, separation of concerns, and readability matter more than cleverness.
Problem solving
Did you understand the problem? Is your approach reasonable? We care about how you break down a problem, not whether you found the optimal solution.
Communication
Your PR description, commit messages, and any comments in the code tell us how you collaborate. Write as if a teammate will read this tomorrow.
Testing & edge cases
Do you think about what could go wrong? Even basic tests or a note about what you would test given more time shows maturity.
Git practices
Clean commits, meaningful messages, and a logical history. We look at how you use version control as a communication tool.
Attention to detail
Did you follow the instructions in the README? Small things like formatting, linting, and a complete README show discipline.
Tips before you start
Some honest advice from our engineering team.
Read the entire README before writing a single line of code
Understanding the full scope saves you from rework. The brief is short on purpose — every detail matters.
Keep it simple
You do not need a framework, a database, or Docker to impress us. A clean script that works is better than an over-engineered app that does not.
Write a good PR description
Explain what you built, why you made the choices you made, and what you would improve with more time. This is the first thing our reviewers read.
Commit often, commit small
Show us your process. A history of atomic commits tells a story that a single “done” commit does not.
Test your code, even if it is simple
A few unit tests show that you think about correctness. If time is short, at least describe your testing strategy in the PR.
Ask if something is unclear
Open an issue on the repo. Asking good questions is a skill we value highly. Nobody has all the answers on day one.
Ready to write some code?
The repo is open. The challenge is waiting. Your next career step starts with a pull request.