The interviewer will give you a coding project to complete in your own time, usually with a deadline. This format allows you to work on the problem in a more relaxed and comfortable environment, but also requires you to manage your time effectively.
<aside> 👋 Your interviewer want to see if you can write code to the company’s standards. They’re also testing how well you are able to follow instructions and how well you communicate.
</aside>
<aside> 👋 You should expect to explain your decision making in the follow up - why did you take the decision you did etc.
</aside>
Limiting the scope allows you to deliver to a higher standard. Many people will want to add tons of features because they think it will be impressive. Actually, it’s more impressive if you execute to a high standard on a narrow scope of work, than executing lots of features poorly.
Remember: many companies will intentionally give you vague product requirements to see how you react! ALWAYS take the time to review the requirements and make sure you fully understand them. If you have any questions at all, always ask.
Asking questions shows (1) you’re willing to ask for help when you need it and (2) you know how to make sense of requirements that have gaps in them.
Plan your approach by breaking down the project into smaller parts. Start with a basic README, then open a pull request to change it.
Keep the pull request small. Step-by-step PRs and logical commits will help you stand out. It also tells your evaluators a clear story of how you reached the solution. It also enables coming back if you mess up.