Creating example projects is a common way of showing your skills to potential employers. Let’s take a look at what’s important to keep in mind when building personal projects with an eye toward impressing prospective employers.
Simplicity
Building applications takes a lot of time and effort. Most projects of any kind are greatly underestimated. There are always unpredictable difficulties that you encounter only after you start working. Besides that, in the case of personal projects, the project will compete with all the other things that you could be spending your spare time on.
The solution to that problem is to keep the feature set as simple as possible. Even the simplest project proves your ability to deliver and shows how you work and what code you can create. If you can make the application solve some problem, that’s great—but focus on finding the minimal feature scope to address the need.
If you are looking for inspiration for an application to build, in my other article I present a simple energy usage calculator.
Covers many aspects
Keeping your feature set small will leave you with time and energy for expanding in another direction—to cover many different aspects of application development. Of all the types of things you can create, it’s always the first of its kind that delivers the most value. For example, demonstrating one class with full unit test coverage shows that you can design testable code, write unit tests, and set up the environment to run them. Writing ten classes would prove your persistence and commitment to the project, but there is a diminishing return on your investment.
Idea
First and foremost, you need an idea for your project. The scope constraints make it tricky to find something that is simultaneously interesting and simple. A common approach is to either make a simple clone of a known application or to follow somebody’s idea for a demo app.
A more creative approach would be to find a small real-world problem and try to solve it with an application. To keep the scope under control, you should aim for making a minimum viable product (MVP)—the simplest product that addresses the users’ needs.
The nice way to describe your application idea is to write user stories. You could start with a very high-level one:
As a gym user, I want an application to book training sessions.
Then you can move down to more precise ones:
As a gym user, I want to have a page that shows the gym schedule with available spots for each class. I want to be able to book classes that have spaces left.
Mockup
Before you begin in your code editor, it makes sense to draw the interface that you plan to build. You can catch many potential issues by thinking about how exactly things will be presented and how users will transition from one place to another. Working with pen and paper is much faster than working with code, and you can easily make many iterations of your interface in an hour or two.
You can use the mockups to communicate your ideas—as I wrote before.
Code repository
As you start working with code, it makes sense to start a new repository. Git is an important skill for all developers, and it’s worth showing that you are familiar with it and that you follow good practices. At the same time, putting your project on GitHub makes it accessible for others as well—so you show your skills and publish your work at the same time.
Communication
Communication skills are as important for programmers as technical skills. Your work has no way of impacting others if they cannot understand what your project is supposed to do. Usually, you demonstrate your communication skills in action to the people who interact directly with you. A demo project presents an excellent opportunity to demonstrate your skill to the broader public: the README file.
In the README file, your audience is clear: people interested in your project, most likely other programmers who have no idea about what it does and how it works. Providing this information efficiently will show that you can understand what users want to know and provide them just that. You can see more info about writing README files in a guest post on my blog.
Prototype
The next step would be to build a clickable interface. Build the screens that you designed with mockups using the technologies you plan to use in your final application. Don’t worry about implementing any functionalities: use hard-coded data and buttons that set values without any logic behind the updates. The goal is to give an impression of a usable application before spending time on building the actual thing.
The benefits of starting with a prototype are two-fold. You will be able to try out the interface or ask others to give it a shot. The feedback from this experience will inform your further work on the application—maybe you will tweak some screens, or you will realize you are missing something. Besides that, at this stage your project will be ready to share as a demo with others: there is not much code in there yet, but one will already be able to see enough of your work to evaluate your skills.
Code quality
With some code ready to go, I recommend you put some code quality checks in place. The most basic verification will be static analysis of your code—checking your code without executing it. A few things that you can set up for your code:
- linters—Programs that check code for possible issues and recommend best practices. For frontend projects you can use things such as ESLint, Stylelint, HTMLHint
- code style tools—Programs that enforce a specific formatting for your code. On the frontend, Prettier covers almost all file types you could expect. I already wrote about it on the blog
Vanilla JS
The next step is to implement the features with Vanilla JS alone. You can skip this step if you already know a JS framework well enough to build an application with it. If you don't, Vanilla JS is the safest bet—it’s the foundation that other solutions are using. I have a simple guide on how to set up a simple JS project with Webpack.
Continuous Integration
At this stage, your project will already have scripts:
- static analysis to ensure the quality and styling of the code, and
- a build script that prepares the code for deployment.
For each change set, you can expect the codebase to be able to pass both scripts without any errors. You can enforce this expectation by setting up continuous integration (CI). Git hosting providers such as GitHub and GitLab offer CI on even the free plans. You can read more about the benefits here.
Deployment
With CI in place, the very next step is to deploy your application somewhere. Deploying the application will make it easy for anybody to check out your application in action—after all, people are more likely to click on the link than to download and build code locally. The easiest places to deploy are GitHub Pages, or GitLab Pages—each of them is easy to set up from the repository hosting. For GitLab, I have a guide on the blog.
Framework
Finally, with all that in place, you can move your application to your framework of choice. There are many options available, and you should choose one that matches what you would like to learn and what’s needed in your job market.
If your application is indeed small, rewriting it to a framework shouldn’t be a big project—changing a few files from JS+HTML to whatever your frameworks uses. If it’s much more than that, you can rethink the scope of the project and find a smaller set of features to build your MVP. And build the rest after you move your project to the framework.
Testing
Lastly, to show that you care about the quality of the code you produce, you can add tests to the application. On the front end, we usually consider two levels of testing: unit tests that check the individual parts of the application, and end-to-end tests that interact with the whole app through its user interface. For a professional project, I recommend using both. For demo projects, unit tests alone should be enough—they are easier to set up and faster to run.
It makes sense to add unit tests after moving to a framework because Vanilla JS code is often difficult to test. Frameworks such as React, Vue, or Angular come with their own unit testing tools and best practices, so you should follow framework-related advice.
Good examples
In my work with mentees, I’ve had a chance to see this idea applied in practice.
Laundry
Gulfani Putra is working on an application that is for laundry services to inform customers about the progress of their order. It’s a practical and simple example: the idea came from inefficiencies that he had seen in local business and that could be addressed with a simple application. If you go to the project page at GitHub, you can see the power of a good README file. By reading it, you will get a pretty good overview of what, why, and how he is building.
Hexter
Wojciech Peczyk is building an application that randomly generates a color code: Hexter. The use case is straightforward to implement, and it allows showcasing all aspects of the project. In the case of features, it’s always possible to add more later on: things such as a button to copy the color to the clipboard, storing previously found colors, etc.
Summary
Writing a demo project is a great idea to showcase your ability to deliver useful applications. At the same time, it’s a lot of work: more than one expects before starting. That’s why it’s important to keep the feature set small, cover many aspects of the project in it, and make sure you can show it to others before you are completely done with it. If you manage to build a project that touches all aspects covered in this article, you will have a strong demo project to show anybody interested in your skills.
