If you're a new developer, you're probably familiar with the “Experience Paradox”.

It describes the frustrating cycle many of us go through when we're trying to get our first developer jobs:

To get a job, you need "work experience". But to get "work experience", you need a job...!

Job requires experience => requires job => requires experience

Now, of course there are reasons why companies prefer hiring more experienced developers. But it's also true that unexperienced candidates might be more motivated, might fit the company culture better, and so on.

In this article, I won't explore all the different ways that new developers can get around this paradox (increasing your online presence, talking at meetups, getting in touch with HR managers, and so on).

Instead, I’m here to talk about what I believe is the main approach beginners should take to avoid the paradox altogether: getting real experience.

How to Get Development Experience Before You Have a Job

In order to get a real coding experience (not only coding – but we’ll talk about that later) you should actively be, well, coding. Makes sense, right?

As a mentor, I've often been asked what the best project ideas are that developers should work on and create to practice and demonstrate their skills.

While it’s not a direct answer, I will say that the project idea itself is not the most important thing.‌‌

‌There are a lot of ideas for projects out there. Yes, some are better than others in terms of complexity, skill demonstration, and verity of technologies. My point is that you shouldn’t necessarily go with the most eye-popping project.

Instead, I recommend creating a product that you or someone you know will actually use.

Why is it important to build a product you would use?

One of the goals of creating a portfolio project is to demonstrate to companies that you can work on their product just like you did on your project.‌‌

I’m not talking about the final product alone – but also the debates, the design decisions, and the choices you made. All this is what developers do on a daily basis and that's what companies will expect from you.

Every gap between your project and their product is an unknown variable, a risk they'll have to take when hiring you. Your goal is to show them that the risk is as small as possible.‌‌

Hypothetically, if your project would be exactly like their product, they would hire you on spot. ‌‌This is not the case, of course, but my point is that your project should demonstrate as many aspects of a real project as possible. Everything you show them you can do – each skill you confirm – decreases their risk in hiring you.

When I say “aspects” of the project, I mean the system components, layers and skills every product requires.‌

If we’re talking about a web-based product, these features can be technical such as frameworks and libraries for UI / server, authentication, communication, 3rd party integrations and so on. You can also showcase your engineering knowledge about topics such as architecture, system design, clean code, readable code, scalable solutions, and so on.‌‌

With this understanding, we can agree that it's better to build a bigger and more complex project than you might have originally thought.

There are some challenges that come with building big complex projects. This is actually the topic I want to talk about in this post.

How to Build a Big, Complex Project – Successfully

‌When you work on a project, your biggest enemy is not your technical knowledge level (you can improve it), your confidence (you can improve it), or lack of resources (there are a ton out there).‌‌

The biggest enemy is yourself or more precisely your motivation. Many times, developers, including myself, start a new project full of excitement but lose their motivation along the way and drop the project.

Why does motivation fade?

Let’s take a step back and remember how motivation works. As proud owners of a reward system, we are “programmed” to keep doing things that help us accomplish goals by giving us good feelings (the “reward”).

The stronger the “connection” between the action and the reward, the greater the chance we will do it again. This is how our body and our mind “direct” us to do the right things.‌‌

Just think of the things you do to get emotional rewards: producing funny videos to get likes on Ticktock, answering questions on StackOverflow to build up your reputation, or working hard to be able to fund the vacation you always dreamed of.

Our motivation is strongly affected by the reward system.

Motivation is a function of the prize size and the time it takes to get it.

But what if the prize is not immediate? What if the journey to the prize is long? The connection between the action and the prize gets weaker, and then so does the motivation.

How to Stay Motivated when Working on a Project

One solution is to enlarge the prize – but this is not always possible. Many times, the prize is given.‌‌ Another solution is to “split” the prize into smaller pieces so we can win things along the way.

For example, $100K in a year = ~$274 a day.

So in order to keep our motivation strong, we should set ourselves up to win, even small wins, more often. We should get the reward frequently to keep the motivation high, otherwise, it falls.

Do you know “Flappy Bird”? It's a game where you need to keep hitting “space” (reward) to prevent the bird (motivation) from falling.

Screenshot taken from https://flappybird.io/

Same goes with your project. When a project helps you achieve a goal (getting a job) or makes you feel a positive feeling such as proud  ( you won the challenge), you get a reward. Or maybe you get satisfaction  from helping people you care about, or you feel flattered when  someone mentions you on Twitter.

In all these cases, you are rewarded.‌‌ But it’s not enough to have the good feeling once in a while. In order to stay motivated, you should feel it frequently.

Now we can understand why the exact type of project doesn’t matter so much. Because it doesn’t necessarily reward you often.

Here are some examples of projects that can reward often:

  • A product that's used by many users and gets good feedback. Reward: likes, number of downloads / visits, and so on.
  • A product for a good cause (like a nonprofit organization). Reward: Your happy face in the mirror every morning, doing something good.
  • A product that improves your life. Reward: Your quality of life is constantly improved.

What, about a product that helps you get a job? It should give you good feeling, right?‌‌

Well, this is tricky. Do you remember the equation: “Motivation is a function of the prize size and the time it takes to get it”?‌‌ The prize of being hired is of course very high, but the time? The time is unknown. So as the time passes “The connection between the action and the prize gets weaker, and so does the motivation”‌‌.

While working on a project that receives good feedback makes you feel good frequently, a meaningless project that you make only for getting a job doesn’t (unless you get hired, of course).

How to Build a Project that You Actually Use

Usually the first two types of projects – one with tons of users and one for a good cause – are harder to get as a beginner. It might take some time to get to a such point.‌‌

This leaves us with the 3rd type  — “A product that improves your life”. ‌‌The nice thing about this kind of project is that it usually starts as a simple improvement to your life only. Then along the way, you discover more features that you need and add them as you go. Using a good product you made rewards you of course so your motivation remains high.

As you add more and more features, the app becomes more complex. Now you can't just throw in components here and there. You have to make plans and decisions about structure, design, and architecture. You have to make decisions about which tools and libraries to adopt.

Every thought and every decision you make covers aspects from the "aspects list" I talked about above (that is, skills companies want to see that you have). If you do this right, it reduces the risk of companies when they hire you.

In fact, in my experience, a major part of the technical interview is the "previous experience" conversation. In this conversation, interviewers ask you about your previous experience, focusing on decisions you made, challenges you handled, and how thoroughly you know the product in technical terms.

The more you have to talk about in this section, the higher your chances of doing well and impressing the interviewer.

Ok, back to your big project. One day you start thinking “This app is great. If I get real value from using it, maybe others will, too”. So you publish it. Now, people can find and use your app and who knows, maybe they'll even like it.

Some of them will like it so much that they leave good feedback publicly. There are HR managers in the crowd. They use your app, they read the feedback, and by chance, they need a new developer — a happy coincidence!

‌See what happened? You created this app to improve your life, and then:

  • It’s doing good for others ❤️ and then
  • You get good feedback 👏 and then
  • You get an interview 💻

It’s a win-win-win-win situation.

The nice thing about this idea that it helps you out even if it doesn't end up in a job offer. Maybe other people won't even use your app – but hey, it still improves your life and your coding skills, which brings you closer to a job. The extra benefits are just extras.

What's the Risk Here?

While you're reading this, at some point you might thinking "why should I create a product for myself? Every product I need has been made. There is no way I can do it better".

First of all, you are not a startup (yet). Nothing bad will happen if you will build a product that's already been built.

Second, you probably have some good ideas about how to improve the products you use. Maybe some features you'd like to see added, some that could be removed, and so on.

Here's an example: I've been using one of the shopping list apps. It's a great app, syncs the list between all the family devices, allows you to set categories, keeps history to re-add products more easily, and can be opened on phones and desktops. Very handy.

I really enjoyed using it, but along the way I felt that it wasn't perfect for me. Some features were missing, like there wasn't a way to upload a product photo. I also couldn't set an urgency level and I couldn't see who had added each product if it was a shared list. Also the history view showed products that were already added to the list, so it was confusing.

I'm pretty sure this sounds familiar for at least for one of the apps you're using. So take your ideas and try to run with them.

Conclusion

So what was the question? What type of projects you should make as a new developer?

Make a product that you or someone you know will actually enjoy using and find helpful.

How do I know this works? Well, this is exactly what I did to get my first job 10 years ago. It's also how some of my own successful projects started.

Oh, and about the shopping list app? Yeah, I made one of my own. It's a Progressive Web App, with all the features I mentioned and more. You are more than welcome to review it and my other open source projects on my Github.

Thanks for reading! Good luck with your developer journey.