Introduction
Congratulations on getting the assignment.
Let me tell you how to crush it!
Mindset
It's not a coding assignment.
It's a feature or product you will build and ship to customers. When you have this mindset, you won't rush through the assignment. You will have a different perspective on it.
Most people see coding assignments as assignments.
Because you have this mindset, you will ask questions you wouldn't otherwise ask:
Who are my customers?
How do I ship this with confidence?
How do I make it a pleasant and simple experience?
How do I make the system adaptable and easy to maintain?
How would I scale this system as we get more users?
This will lead to research.
This will lead to intentionally building your software and what technologies you pick.
Customers
You're shipping this to customers.
You're not building a demo.
Keep it in mind.
Understanding the problem
The worst thing that could happen is you build something that doesn't match the requirements.
One of my quotes:
The solution lies in understanding the problem.
To build effective solutions, you need to have a thorough understanding of the problem.
Read the requirements multiple times.
Make sure you understand every single word.
Make sure you understand every single letter.
Talk to yourself and explain the problem. I'd also recommend talking with AI about the problem. Try to explain the problem and have a conversation about it.
If the domain of the problem is unfamiliar to you, learn about it. For instance, if I get an assignment that's related to healthcare and I come across words I don't understand, I shouldn't mindlessly move on. Stop!
Feel free to put the assignment aside for a while to learn the domain and language they use and acquire knowledge to help you better understand the problem.
Building
I don't know if you're on a time limit.
When it comes to building, you want to be pragmatic.
Try to understand which requirements have a higher priority.
Use libraries instead of building your own technical solutions for complicated logic.
Keep track of every requirement done and focus on one thing at a time.
Build this as you would at work:
Testing
The assignments can be so different.
If you know Test-Driven Development and it would be a fit, apply it. It'll also help you focus on one thing at a time.
If you aren't too familiar with testing, here is my advice:
For every major requirement, write higher-level tests. This would be integration or E2E tests.
Once you're done with the assignment, write higher-level tests for the main features.
The reason we write tests is that we want to ship the software with confidence to our customers.
Some tests are better than none.
Some features covered are better than none.
However, don't get too deep into testing. It's better to have something ready than nothing and many tests.
In reality, it's better to be in business without tests than out of business with no tests.
After all, we build software to solve problems and make money. We aren't building software to write tests.
Ending
You have built the project.
You haven't missed any requirements.
Make sure to document the project nicely in your README file:
The problem
Process
Tools you picked and why you picked them
How to get the project running locally
Solution
Challenges you encountered
What could be better
Thoughts on how you would scale the project
Conclusion
The average developer sees assignments as assignments.
The outstanding ones focus on shipping to customers and dealing with growth in users:
Adaptability
Scale
Maintainability
