The Difference between a Good Take-Home Project and a Not-So-Good
I often find it easier to apply the advice when it’s negative: “do not do this” instead of “do this.” Therefore, I will show a not-so-good example next to a good example.

Introduction
This article aims to explain, with examples, the difference between a good take-home project and a not-so-good one.
I often find it easier to apply the advice when it's negative: "do not do this" instead of "do this." Therefore, I will show a not-so-good example next to a good example.
I have created two Github repositories: good and not-so-good. Feel free to check them out, fork them, take ideas, whatever you want.
Subscribe for more articles like this:
Thanks for subscribing! A confirmation email has been sent.
Check the SPAM folder if you don't receive it shortly.
Sorry, there was an error 🤫.
Try again and contact me at llorenc[at]gimtec.io if it doesn't work. Thanks!
Subscribe
The Project
The good and the not-so-good projects come from the same assignment, a Job Application Tracker—a common full-stack CRUD project.
The stack I chose is React and NodeJS. Yet, the differences of what makes it good and not-so-good is not entirely related to React or Javascript in particular.
Both projects have exactly the same functionality, features, and experience for the user. The differences are in how the project is built, not in what is built.
Fulfilling the requirements is a minimum when submitting a project. Here, I would like to discuss recommendations that will make you stand out from the other projects.
Communication
The first main difference we find is the readme file. One is full of details: explaining how to set up the project, screenshots, etc. In contrast, the other one is just a sentence. It could have been even worse if, for example, you left the default readme created by "create-react-app."
Everybody agrees that good communication is key to good development and teamwork. But, what is "good communication"? Do you have to write the bible or just a tweet?
My suggestion: put yourself in the reviewers’ shoes and make it easy for them.
A few examples of good communication:
Explain carefully how to set up the project and what technologies are needed.
Screenshots are always nice; gifs are better.
Help them navigate your project. Explain the main folders and where to find what.
Explain the important decisions. I like the idea of an ARCHITECTURE.md file where you summarize the main decisions regarding code architecture and design.
Showing your communication skills is important, especially for remote positions.
Clean Code: Consistency
Be consistent in the code and the folder structure.
The previous example shows how the not-so-good example has the same files, but some are grouped in a folder, and others are not.
Once you choose a way to solve a problem, keep always solving it the same way.
If you like a pattern, such as using the model and returning the data, keep it always like that. Repeating patterns is a good sign; it's not the same as repeating code.
Clean Code: Readability
Err on the side of adding extra lines to make your code more readable. Do not try to solve everything in one single line. Use variables and their names as documentation.
Writing readable code does not mean adding extra comments. If you find yourself adding too many comments, review your code. The code should be self-explanatory. Maybe you need an extra variable or create a new function to hide that logic and make it readable.
Yet, sometimes, readability also comes from the lines of code. The more lines of code a function has, the more complex it is. Sometimes the solution is to extract a piece of logic to its own function to make your code more readable. If you can't remove the complexity, hide it.
Try reading your functions out loud. If they make some sense, you are doing well.
Code Smell Examples
Let's go over some common patterns in junior developers and a better solution for the same problem.
Callback hell
The first example above it's hard to read. That's why is a code smell. When you need to read code many times, it means that it's not readable. You should refactor.
Not catching errors with async functions.
Forget to add comments when doing something not obvious.
Lastly, Some Controversial Tips
A few tips that not everybody might agree with, but I find useful for different reasons.
Two of them are focused on frontend. Yet, the generic advice still applies to all stacks.
Add some of your personality
Hiring managers receive many projects per position. You need to stand out. Show who you are and why you are different. For example, make the project theme-based on a tv-show you like, or if you like good UI, spend extra time with it, avoid using a UI framework.
In my case, I wrote a few pieces of code that could be considered libraries, for example, the useAPI and the models. In my case, I love finding patterns and writing the generic solution.
Be comfortable with a UI framework
Take-home projects usually have a deadline. Knowing a UI framework frees up a lot of time that you can use to add the little extra mentioned above.
Know your forms
In any CRUD application, there are forms. Forms mean submitting and also validating the input. The way to do that is always similar, yet different enough to be annoying.
I recommend that you get comfortable working with forms. Learn how to use a library or learn how to do it yourself, but learn to be fast and efficient when working with forms.
This tip is similar to the UI framework. We could generalize it to: "be comfortable and fast with generic tasks."
A list to rule them all
Here are the sentences in bold as a summary:
Put yourself in the reviewers' shoes and make it easy for them.
Once you choose a way to solve a problem, keep always solving it the same way.
Repeating patterns is a good sign. It's not the same as repeating code.
Err on the side of adding extra lines to make your code more readable
If you can't remove the complexity, hide it.
Show who you are and why you are different.
Be comfortable and fast with generic tasks.
If you like this post, consider sharing it with your friends on twitter or forwarding this email to them 🙈
Don't hesitate to reach out to me if you have any questions or see an error. I highly appreciate it.