Getting your first dev job can be depressing. Especially without professional experience. You send out application after application but get no replies. Every company wants experienced people but how to gain experience without a job? A classic hen egg problem...
This is where your personal projects come in. They are the best way to showcase your abilities without a prior work history. So getting them right is very important to score an interview.
I have been on both sides of the table
I'm a self-taught developer myself. When I applied for my first jobs, I was asked about my experience during the interview. I was able to spend the first ten minutes or so talking about my projects and the technical decisions I made. This gave me a huge head start for the rest of the interview.
On the other side when I was reviewing personal projects of candidates for job positions I was often irritated. Projects were hard to run, didn't work, or the code formatting was awful.
So believe me: There are a lot of quick fixes that will allow you to stand out of the crowd. That's why I created a checklist that you can apply to your personal projects.
A checklist for your portfolio projects
Note: This list is designed for web frontend positions. Still, most of the items are also applicable to other developers.
- The app should work
- Deploy a running version
- Add links to deployed app and source code in resume
- Users should understand the purpose of the app
- Don't hide the app behind a login
- Well-structured and informative readme
- Clean code formatting
- Custom CSS
- Somewhat complex logic
- Mobile responsiveness
- Pin your GitHub repos
- Don't use tutorial apps
Before we start going into the details: Also have a look at my free course where you learn many more tips like this about your portfolio projects, your resume, and the hiring process.
Let's have a more detailed look at each point.
1. The app should work
That sounds kind of ridiculous but I've seen it multiple times. Either you enter the URL and there's only a "white screen of death" or you try to run the source code and only see errors. Make sure to test everything manually before applying for a job.
2. Deploy a running version
Being able to take a look at the app is important for non-technical people. It will also make it easier for developers who review your source code to understand what its purpose is. It's important that its response time is not totally slow, so don't use a free Heroku plan. When the app is not opened for some time Heroku needs to restart the application which takes quite some time. Make sure people don't get bored and close the app before having a chance to look at it.
3. Links to deployed app and source code in resume
Make it as easy as possible for anyone looking at the resume to check out your projects. Imagine having limited time to review a pile of applications. You don't want to be forced to enter a URL manually or scroll through a list of unordered projects on GitHub.
4. Users should understand the purpose of the app
The UX doesn't need to be overwhelmingly great. But a new user should be able to understand what the project is doing. Think about someone who has never seen the app and doesn't know how it works. Will they understand what to do? Is it clear where they need to input data etc?
5. Don't hide the app behind a login
Again imagine a person with limited time. You don't want to force them to create an account before being able to access your app. If you need a login make sure to note the user credentials in the resume or prefill the login form.
6. Well-structured and informative readme
This should at least contain instructions to install and run the app as well as a link to a deployed version. You can use the readme to show off your skills and ability to communicate. Add sections where you explain your technical decisions and the structure of the code. You can also include a link and description to a place in your code with custom CSS (see 8) and some more complex business logic (see 9). Developers reviewing your app often won't have the time to step through the complete source code. So guiding them to the beautiful places may be advantageous.
7. Clean code formatting
This is really simple but yet a lot of junior candidates don't have a nicely formatted code base. Some files may have four spaces indentation, some only two. Use a tool like Eslint or prettier and format your code automatically.
8. Custom CSS
It's okay to use a UI framework like bootstrap, material-ui, you name it. It's way easier to build an app that looks nice without a lot of design skills. A nice looking app can be a good way to leave a good impression after all. But your day-to-day work as a developer will most likely include writing lots of custom CSS. So be sure to write the styles of some feature yourself. Add some mobile responsiveness if you like. Also, see point 6.
9. Somewhat complex logic
Another big part of your responsibilities will be writing business logic. So make sure you have at least one feature where you implement something more complex than iterating over an array and rendering the contained objects. Transform some data. Make use of some array functions like map, filter or reduce. Write this code as readable as you can. Also, see point 6.
10. Mobile responsiveness
CTRL+Shift+I, that's how easy it is for the reviewing developer to test the mobile responsiveness of your app. And nowadays it's an essential topic for companies to not upset the Google search engine. So be sure that your app is not totally broken on mobile devices.
11. Pin your GitHub repos
Assume that someone who wants to check out your skills might end up on your GitHub profile. The default order of the repositories there is by popularity. Which doesn't mean a lot when you don't have popular repos. But you can select which projects should appear in this list by clicking "customize your pins".
12. Don't use tutorial apps
Everybody watches tutorials and a lot of people implement these apps. Many people also list them in their portfolio. This makes it likely that the person reviewing your projects already saw the same thing over and over again and recognizes it as belonging to a tutorial.
Even worse, a lot of people don't say that they implemented this app with a tutorial. Don't do this. It feels like you're lying about your achievements and diminishes any trust in you.
After all, following a tutorial is relatively easy. Even if you customize the app afterward. So writing your projects from scratch is a better option.
More tips in my free course
If this post was helpful to you make sure to check out my free course and learn about the hiring process behind the curtains, how to optimize your resume and many more tips like this for outstanding portfolio projects.
Top comments (0)