How to Build a Project That Will ACTUALLY Get You a Job

Trying to get a job as a software developer is hard enough at the moment. But what if you don't have a computer science degree or any relevant experience?

How on earth are you supposed to stand out from all the other candidates and prove that you have the skills needed?

As I am sure you are aware, blindly following tutorials isn't the best way to learn how to code and you need to build your own projects. But when it comes to getting hired, that to-do list, tick-tack toe or snake clone isn't going to help you.

In this article, I will show you what recruiters and hiring managers are looking for in your projects so you can actually get a job.

So a lot of YouTube tutorials will show you how to make games because they are a fun way to get people interested in learning how to code.

However, if you want to be a professional software developer then you need your projects to show off your skills. Recruiters need to know what you are capable of and on top of that, they need proof that is actually your own work.

I came across this great project the other day by a developer that showcases exactly what you should be doing in your own projects if you want to stand out.

Juraj created an Uber simulator that runs in the browser. You can see straight away that this is quite an advanced project. It took him around 300 hours to build this.

This isn't a simple application that you can build over a weekend and that is one of the things that makes it stand out.

Subscribe for more video content

Deploy your projects

The fact that we can see the project in action and play around with it brings me to my first point.

You need to deploy your projects.

Unless it is a desktop app it is no good having your project running on your computer. You need something that someone non-technical can actually see and appreciate.

Tech recruiters know what specific skills they are looking for in a candidate but they aren't developers. They aren't going to look through your GitHub repos and be impressed by all the code you have written, they aren't going to understand what any of it means.

Now you might not think that matters but if you can't impress the recruiter, then your job application isn't going to get passed on to the hiring manager who is likely a developer or at least will appreciate all that clean code you have written.

There are often hundreds of applicants for a job and unless you have something you can quickly show to others your project is just going to get ignored.

Deploying your project to the cloud doesn't need to be expensive. AWS has a generous free tier and there are also other places like Vercel, Railway, Digital Ocean and Heroku where you can host your projects either for free or for the price of a cup of coffee a month.

Show your working

So you have your project running in the cloud and you have your code up on GitHub.

Job done, right?

Not yet.

Just having your code up isn't enough to actually prove that you created it and it doesn't tell those hiring you anything about your thought processes.

When hiring developers it isn't just your skills and your winning personality that they are interested in. They want to know how you think and how you would tackle a problem.

Juraj has done this by writing 35 blog posts while he was building the project, such as why he picked the technologies, how he designed the map and everything in between.

You can see in these posts why he has made certain decisions such as using Docker, the database he chose and migrating the application to React.

If you haven't started a project yet then a great way to do this could be a daily journal covering what you built that day and the various decisions you made.

Even just a single long blog post at the end of a project can be a great way to prove that this is your work and it isn't someone else's code that you have put online.

Don't forget the documentation

When you are building out your project you should do the same things you would do on an actual job.

There is one thing that lots of developers do really badly and that is writing documentation. So once you have built your application put together some documentation for it.

This might include system diagrams, user journeys and Open API specs. There should be enough information there for another developer to understand how your project is built.

If you do manage to get past the first stages of a job application you will likely be given a small technical exercise to do such as build an API. Again don't forget the documentation.

It used to infuriate me when reviewing a candidate's technical exercise that they didn't include any documentation on how to run their code or even the API key to use.

It doesn't leave a very good first impression if the reviewer has to hunt through your code to find what API key to put in to run your application.

Your documentation should be just as important as your code and even more so if you are trying to show off what you have built.

Treat it Like Production

Once your application is up and running online you need to treat it like a real production application.

If it was a real application you wouldn't just put it up online and forget about it.

You would put in monitoring and logging, you would have a CI/CD pipeline and you make sure that everything is secure.

In this project, Juraj has described how he has set up Prometheus and Grafana and has even made the dashboard public as part of his application.

It is this attention to detail that will really make your project stand out from everyone else.

This might seem a bit daunting at first but once you have these things set up you can carry on using them for all of your applications.

For a CI/CD pipeline, I would just use GitHub actions which if your repository is public is completely free. Even for private repositories you get 2,000 minutes a month which I never get anywhere near when I am using it for my personal projects.

Ideas for Projects

Of course, coming up with ideas for projects can be a bit daunting. If you are just doing it for experience and to show on your resume then making clones of popular applications is a good start.

You are not coming up with an idea from scratch but you will still need to pick appropriate technologies and write about your thought processes. Like Juraj did in this example you will likely have to simulate some of the user interaction.

For example, if you created a Twitter clone it would be pretty boring if there were no other tweets to look at.

If you are looking to be a full-stack engineer then you need to look for a project that will show off all your skills.

Even for backend engineers, you will need some form of frontend to interact with your application. Remember it will be a non-technical recruiter that will first see your project, so it needs to look interesting enough for them to pass on to the hiring manager.

So your project needs to have:

• A Frontend
• An API
• Database
• A blog post about what you have built and why.
• Documentation which includes system diagrams, API specs etc.
• Monitoring and Logging (for extra credit)

If you can do all of that then your project will really stand out when you apply for your next job.

If you are struggling to know what to learn to do all of this then check out my backend developer roadmap where I cover everything you need to know to get started.

📨 Are you looking to level up your skills in the tech industry?

My weekly newsletter is written for engineers like you, providing you with the tools you need to excel in your career. Join here for free →