In part 1 of this series we saw how you can build impressive portfolio projects by working like a professional developer in a real team.
The idea in a nutshell: you build your project with a structured approach. You start with designs, create tasks, and only then write the code. You use the tools, workflows, and libraries that also real companies use. You write custom and responsive CSS. Your app contains state and business logic. You write concise yet descriptive Git commit messages and work on branches.
And if you really want to stand out, write automated tests with React Testing Library. That will put you way ahead of a typical Junior candidate.
Now it's time for part 2 of this series.
Let's say you built your portfolio project. You used all the advice from part 1. The code quality is alright. In short: You're a great candidate for a Junior React position.
Finally, you take the leap and send out job applications. You're confident that you'll get some interviews soon.
But nothing happens. Nada. No replies. No interviews. Just crickets...
If only somebody could tell you what's going on.
The thing is, you need to understand how the hiring process works. Entry-level positions get swamped with applications. And the people reviewing the applications on a technical level (e.g. team leads or developers) have other things to do.
See for yourself. Let's switch sides for a moment.
Let's pretend you're a developer at a company. A Junior dev applied for an open position. And you're the one who has to review the portfolio projects.
You have a busy day. You're in-between meetings and need to finish a feature you've been working on. Not much time to spend on this candidate.
Now try to observe yourself:
How do you scan the information in this repository?
My eyes quickly scan the folders and files. The folder structure looks pretty standard for a React project at first glance.
In a matter of split seconds, they arrive at the bottom where we can see the content of the README file.
This project obviously was created using create-react-app. The README wasn't changed, so we can dismiss it. Not much information there.
If we were carefully investigating the repository we'd see that there are open issues, pull requests as well as a dozen branches. This might indicate a good workflow.
But let's face it. We're in a hurry, so probably we won't even notice these details.
So what would you being the reviewer do next?
You only have a few options. The most likely ones are
- Start opening files more or less randomly.
- Have a look at the commit history.
My guess: Most people would start opening files.
Now it all depends on how much time you invest and how quickly you get bored. In any case, you are likely to miss some impressive code hidden in the file structure.
You (the reviewer) have to decide by chance if I'm a great candidate for that Junior position.
How can we fix this?
Let me show you another version of the same repository.
This is the same repository. I only changed the README and the About section at the top right.
As a reviewer, my eyes again would quickly arrive at the README content at the bottom. But instead of dismissing it right away, I'd stop and start reading the section "How I worked on this project":
"Oh wow, this guy knows his sh... On his resume, I saw he has no job experience. But that's pretty much how we work in our team. I bet he'd quickly be productive." - Made-up conversation with myself
The next section "How to navigate this project" points me to the most important parts of the application. If the code behind these links looks OK, I'm ready to give this candidate a go.
The section "Why I built the project this way" reveals information about the reasoning behind some technical decisions. That's really great because it allows the reviewer to tap into your thought process.
A final section "If I had more time I would change this" shows that you can take a step back and self-reflect. Very important for working in a team.
Only at the very bottom, you can see the available scripts. These almost don't matter anymore. Probably nobody will download the project and run it anyway. But it's good documentation practice to have them.
There's one final advantage of writing such a README that I didn't mention yet:
By writing all this documentation you not only guide the reviewer through the project. You also prove your communication skills. Any experienced hiring manager knows how important yet rare these are among engineers.
So invest some time into writing a clear and descriptive README. Write it. Let it rest. Then return a couple of days later to review it with a fresh pair of eyes.
Part 2: Summary
- the README might be the most important page of your project
- you can make sure that the reviewer sees what they need to see
- you can impress the hiring manager with your communication skills
- you will appear a lot more professional
In short: a clean and informative README will let you stand out from other candidates.
In the next days I'll release part 3 here on dev.to. I'll share 3 project ideas that will make a great impression on your React portfolio. If you don't want to wait you can read the whole series on a single page on Profy.dev already now.
Illustration based on drawkit.io
Top comments (17)
This definately helps ❤️
I just delete the branches after merging. Any opinion on that ?
You should have 3 branches
master/main
qa
development
And seperate branch for each feature which gets deleted after merging.
First make a pr on development, if it's working properly and create a pr from development to QA, then after testing from create PR from QA to master/main
Honestly, I don't think that's necessary. Yeah, some teams work like that. My current team also uses a development and master branch. But it highly depends on the deployment process. And tbh it's quite annoying if you use mandatory code reviews and want to deploy often.
If you use continuous deployment in combination with preview branches you use a super modern and professional workflow. It works like this:
In a real team your coworkers would ideally review your code to improve quality.
Deploying the branch is usually a bit tricky if you set up deployment yourself. But in your own projects you can simply use Vercel or Netlify. They are free, easy to set up and give you advanced features like branch previews out of the box.
Btw if you where hinting at the good old "git flow" there's no need for it for a typical web app. The author himself recommend against using git flow for web apps as you can read on the original article
Wow that's quite a long process 😅
Will try to follow the steps 😇
See my comments above. No need to overthink git for your own projects imo 😊
You're right, creating 2-3 branches for prod, prev and dev in personal projects is kinda stretch !
As I use vercel the branch preview does the job !
Generally that's totally fine. In a production app you'd typically delete your branches. At least from time to time since you end up with a big mess otherwise.
For a portfolio project there mighty be an advantage of leaving them if the reviewer wants to check them out. It's unlikely that they will though. And if you use pull requests you might see the changes there even if you delete the branch (not at all sure about this though 🙂)
Thanks, I'll keep this in mind. I use PR when I introduce massive changes or I'm not sure about a feature will work or not. Also, I create issues that I label and assign myself. Just have to improve my README.md file as I never edit those 😅 and also the about section.
That sounds great. Yeah the readme is important. But you're on the right path it seems 🙂
I have been reviewing a lot of coding exercises and interviewing for a lot of developers this year, I can confirm this advice is bang on.
It's not just what you have done but also showing the thought process behind it and what you would like to do with more time.
I like to see the full commit history you can learn a lot about a developer by seeing what changes commit by commit, also if their commit messages are clear and logical.
Don't forget all the small things like moving as many imports as possible into dev imports to keep main bundle size down and don't forget to remove junk like console logs.
Thanks a lot for the nice words and sharing your insights. That's very valuable.
I wasn't sure how many people actually investigate the commit history. But seems like I'm not the only one :)
I'm pretty sure that this will change my life.
Thanks 😊 Let me know if it does
Great content here👏🏿. As a junior starting out this came at the right time. Thanks for this
Thanks a lot for your kind words. Very motivating for me. All the best for your journey
Loved it! Never thought about it from this prospective. Keep up the good work👍