The software development industry is booming right now and there are more jobs than ever. However, getting your first job can still be a real challenge as there are many juniors seeking jobs but lacking work experience. This makes it hard for companies to figure out what you can do. Building your own hobby projects is one way to showcase your skills and direct the job interview in the direction you want.
What to build?
The first thing you need to figure out after deciding you want to build a project is what to build. Doing free work for companies might be tempting at some point but I don’t recommend doing that. By working for free for a business, you diminish the value of your work and it will be hard to turn it into making money later. Luckily, there are many options to choose from.
1. Something you need
The best way to start is to solve your own problems. Is there something in your life that’s missing and could be solved by building a web application, mobile app or script that automates things? Start from there. Not only will you build something that makes your life easier, but you can figure out which features it should have and how it should behave. Designing the functionality and having people test your application to give feedback is always challenging but when it’s for yourself, you have a natural shortcut to those decisions and feedback. I have developed software for almost 20 years and in this entire time I have been building things for myself in addition to my professional work. Being a software developer is like having a super power. You’re able to build whatever you need, whenever you want.
2. Helping a nonprofit
While I don’t advise you to work for a business for free, creating something for a non-profit - especially one that you’re personally involved with - is a good idea. You could help to build membership management tools,their website or a mobile app to help volunteers record their findings.
Since smaller nonprofits don’t usually have the money to buy software, every piece of help is valuable. That’s why it’s a great opportunity for junior developers to build something at their own pace and according to their own skills. In addition, you learn valuable lessons about project management, testing with real users and communicating what your project does.
3. Replicate an existing product
If you are completely out of ideas, one way to showcase your development skills is to take an existing product or service and replicate its functionality. If it’s a commercial product, you cannot publish it or make money with it but showing the code and discussing it during the job interview can be done.
Replicating something existing also gives you an opportunity to focus on the technical implementation as design and features are already decided by someone else. Many of the applications you use daily have been built by large teams for a longer time so don’t try to build everything just like they have.
One example of this that I really like is from Prototyping Playbook. In this example Matt takes one functionality from Instagram and implements that using web technologies. It’s exactly the kind of project that I mean in this point. Matt’s Playbook contains other good examples as well so you can use that for inspiration.
Try to choose something that you’re familiar with as a user but that is on the edge of your skills. This will force you to learn something new while building it so when it’s finished and you showcase it, it will be at the highest potential of your current skills.
Showcasing your project
Communication is an important skill for software developers. Your hobby project functions as an exercise in getting better at it as well as a showcase of your skills right now - just like it does for your technical skills.
Nobody is going to read your code if you only put it into a repository to Github and send a link to it. It’s difficult to figure out what a codebase is doing and how it functions so the next step is to write documentation and create a landing page for the project.
In its simplest form, it can be just a README file at the root of your project repository. It should explain what the project is, what it does, what technologies it uses and how it can be run. A couple of good examples of README files are in git-point and edlib repositories.
2. Create a landing page
If you want to be a bit more dashing, consider building a project landing page. Add screenshots of the product or explain different ways to use it. Some examples of projects with good landing pages are Pushfolio, Github Pages and TLDR pages.
With Github Pages, you can even host the landing page directly from your repository so you don’t have to think about web hosting or domains.
There’s no need to overthink the landing page. It doesn’t have to be all shiny and professionally designed, the information written on the page is the key. Try to answer the following questions:
What does your project do?
Who would use it?
How do you run it?
What does it look like?
3. Publish a demo
If it is a web application, consider publishing a demo somewhere and linking to that from the README or landing page so that the reader can check it out.
If you like to blog, you can also write a post explaining your project or a part of it from a technical point of view. Share what you built and how other people can take your application and test it. For an extra adventure, give a talk about it in a local meetup group. You never know where it can lead when other people know about what you’re doing.
Direct your interview discussion
Interviews are all about both sides of the discussion - the interviewer and interviewee - trying to find out if the other side is a good match. It means that you can try to direct the discussion into topics that you are familiar with and excited about rather than merely waiting for the other party to ask questions about topics you don’t know so well. A hobby project is really good for this.
Explain how you think
Talk about your decisions. Why did you choose the technology or libraries that you did? Why did you choose to build this thing in the first place? Is anyone else using it or just you? Talk about what you learned during the process and what you would do differently if you started from scratch now. It might feel weird to discuss things that you think were not good but it shows that your understanding of software development has grown and that you can reflect on your own work and communicate what you have learned.
“I built this web application that helps me track my personal finances. I used Vue.js on the frontend and Python’s Flask framework on the backend as I know those technologies best. Would you like to discuss that project?”
There's no one-size-fits-all approach
However, it doesn’t always work. Some companies might have very strict question palettes that they stick to and in that case, do your best and try to bring up learnings and experiences from building your project as answers to specific questions.
I have been on both sides of the table in job interviews and every time we’ve had an opportunity to discuss a project the candidate had done, it ended up being a good discussion and gave me a much better view into what kind of developer I was discussing with.
Building hobby projects is not the only way to get a job in the industry but it’s a very effective way to showcase your skills and convince your future employer that you can create something. By building something that is helpful for you or a non-profit you're involved with, you’ll have something in your portfolio to show in job interviews and you have created something that has a real impact in the world.
Writing the code is only half of the way though. Make sure to present your project in a well-documented manner with a good landing page and you can be sure it will be noticed by more people reading through your portfolio.
In the job interview, use the projects you’ve built to direct the discussion. This allows you to focus on things you are good at and have a demonstrable track record. And as I’ve been on both sides of the interview table, believe me when I say it makes the interview process much easier for both sides.