You can see it all the time: In the hope of landing a job, new developers put in hour after hour creating their portfolio website. They have a great design in mind with a cool color palette, fancy animations, and a great UX.
But after weeks of work, the result looks more like... eh.
Why all this effort? It seems like everyone in the industry believes that you need a portfolio website to get a job.
Actually, not everyone. Many developers (including myself) get great jobs without ever having a personal website. Even if they are self-taught (again including myself).
So the crucial question is: What do the people involved in the hiring process think? These people are the gatekeepers. You have to spark their interest to get a job. If they don't care about your personal website why build it at all?
To answer this question I went out and conducted a survey among recruiters and hiring managers. The results are clear: you don't need a personal website to get a job. On the contrary, it can even backfire.
So before you start (or continue) wasting a lot of time on your portfolio website let's talk about
- The results of the survey
- Why portfolio websites often turn into a huge time-sink
- How they can even hurt your chances of getting a job
- 4 alternatives to a portfolio website that have a higher impact on your job search
I gathered answers from 60+ hiring managers. Turns out, a portfolio website won't get you a job
My personal experience with portfolio websites is clear: many of my colleagues never had one. Neither did I. Still we found great jobs.
But this is not objective, is it? Does this personal experience hold true for others as well?
To dig deeper I reached out to 300+ recruiters and React team leads who are involved in the hiring process. I asked them two questions.
Imagine this situation:
You see two job applications by developers without professional experience. Both resumes include a link to their GitHub profile and a list of portfolio projects. One developer also mentions a personal website. How would you rate the following questions from 0 to 5?
- Would you look at the personal website?
- Would the chances of the dev without a personal website be lower?
Hold your breath. Here are the results:
Note: If you're involved in hiring developers feel free to take the survey yourself. Follow this link to get to the survey on Google Forms.
The results are clear. The overwhelming majority of hiring managers look at your website... but don't give a crap.
Now you're right. Reality isn't black and white. Not everyone rated the second question with a 0. A considerable number voted with a 1 or 2. Some even higher.
At the same time, the framing of the survey was quite open and left some questions: How does the portfolio website look like? Are the GitHub projects of one dev better than the others?
So the question "Would the dev without a personal website have lower chances?" unsurprisingly was often answered with:
It depends.
Luckily, many of the hiring managers were so nice and provided deeper insights. That's what we'll discuss in the rest of this article.
There's still a slight chance that a portfolio website helps me get a job. Why not give it a try and build one?
You're right. Depending on the hiring manager a portfolio website might give you a bonus. But why is that? Let's hear two of the more positive voices:
The key takeaways here are that a website can show
- character
- creativity
- dedication and passion
Now, these are all important points. Especially for devs without much experience. Your character is important to fit into the team. Creativity is crucial for solving problems.
But most importantly, a Junior developer needs to grow. In their first years, they have to learn a ton. This can be very difficult. Or exciting depending on the perspective. In any case, dedication and passion get them through this time.
If you can convince a hiring manager that you're dedicated, passionate, and willing to learn you will get a step ahead. And a portfolio website may help with that.
At the same time, as Renato mentions, all of this can be found in GitHub projects as well. And from my perspective projects on GitHub are superior to a personal website. By a lot. But we'll come to that later.
For now, let's have a look at two reasons why you shouldn't build a portfolio website.
Reason 1: A portfolio website can become a huge time-sink
When I build a website from scratch this is what typically happens:
- I have a design in mind which looks really cool.
- I start writing code, create the markup, and style it with CSS.
- A few hours in, I'm done with maybe 10% of what I planned. And what I created looks like crap.
- I start moving elements pixel by pixel, add a border here, change a color there. All in the browser's dev tools.
- The layout still looks like crap. So I search for nice-looking websites, professional designs, or any other example that I could copy.
- After days of work, the website looks okay-ish. But nothing I'd be proud of. And I still need to make it responsive and cross-browser compatible...
If you have experienced something similar you know one of the biggest drawbacks of creating a portfolio website from scratch:
You can spend a lot of time getting everything straight. Usually much more than expected.
The question is: Do you really want to invest all this time in a portfolio website? Even if the most important people don't care? The people who decide whether you get the job or not.
You probably got it. Time-wise a portfolio website is a risky investment. But you might think: "I got time. And it's still an opportunity to practice my coding skills."
Ok. But there's another problem.
Reason 2: A portfolio website may hurt your chances of getting a job
Let's face it: Most developers aren't born designers. And they don't need to be. After all, it's usually not part of a developer's job.
But the problem is that unlike your personal projects on GitHub, a portfolio website is expected to look good.
A bad design can make you look incompetent even though everything works fine and the information on the website isn't bad at all. And even if your website looks great in your eyes another person might not agree.
That's not all though.
He's got a point. It's not only about the design. There's a part that we rarely think about in advance:
Websites have to be maintained.
Over time, things will change. Your links might go 404, a change in one part of the code might break another feature. Personal projects that once were cool look crappy now. Our resume receives updates.
A website has to be checked regularly. I've seen broken links in portfolios that were only a few weeks or months old. Especially in the early days when there are lots of changes to your website and GitHub portfolio the risk of breaking things is high.
To summarize:
A wise man once said: "Better to remain silent and be thought a fool than to speak and to remove all doubt."
In that manner: it might be better to have no portfolio website than one that looks bad or is broken. Especially since there are great alternatives. Alternatives that have a way higher impact on your job search as you will see in the next section.
But before we continue it's time for... an ad break. (Not really an ad, more of a freebie that might come in handy if you're just starting your career as a developer. Anyway, grab a coffee, and let's continue.)
Alternatives with a higher impact on your job search than a portfolio website
If you made the decision to ditch your portfolio website you just saved a lot of time! Congrats.
But what should you do instead?
Here are some alternatives that have a higher impact on your job search.
Alternative 1: Focus on your GitHub portfolio
If you don't have professional experience as a developer yet you have to prove your skills. From the perspective of a hiring manager, offering you a job means taking a bet on you. Will you be a valuable asset to their team or not?
Your public projects on GitHub are a great opportunity to prove that you're job-ready. Your code speaks for itself. And if you build your project in a professional way you can hit a home run on your job search.
Sam has an important point: Your GitHub projects are a great conversation starter in job interviews. The interview will typically start with a short introduction round. After that, you'll likely be asked about your past experience.
If you don't have professional experience yet your GitHub projects provide the interviewers with an alternative. They will ask you about your technical decisions. They will try to follow your thought process. They might ask what you would improve from hindsight.
This is not only an advantage to the interviewers.
You will start the interview by talking about something where you're the expert. You built this project. You can show your enthusiasm. You can share your expertise.
Doesn't this sound much more comfortable than getting purely technical questions about the component life-cycle in React or prototypical inheritance in JavaScript?
At this point, you might rightfully ask where the difference is. If you publish the source code of your portfolio website it's basically the same as any other GitHub project, isn't it?
Some of the hiring managers I asked said exactly that. But there's still a small difference.
A portfolio website is exactly that: a website. To be more precise, a static website.
Now, to be frank, these are miles away from real-world web applications. And building web apps is what you're getting hired for as a React developer. Not building static websites.
The difference is that web applications are dynamic by nature. They are stateful and load data from APIs. They offer interactive elements and forms.
So instead of investing a lot of time into a personal website build one or two full-blown web apps. This will much better prove that you have the skills to work on real-world production projects than any static website could do.
That leaves only one question: how and what exactly should you build if your goal is to impress hiring managers?
No worries, I got your back. Here is an in-depth guide into building React portfolio projects that make you shine like a pro.
Alternative 2: Share your learnings in blog posts or videos
You have a personal website that also includes a blog? That changes the game.
It's still a static website that doesn't really prove your production skills. But the focus is not on the website anymore. It's the content that you create.
In fact, you don't even need a website. Just create an account on dev.to. On your resume, you simply add a link to your dev.to account instead of the personal website. That's it.
The reason why blog posts or other content can have such a great impact are these:
- You allow the reader (aka hiring manager) to tap into your thought process.
- You can prove your communication skills.
- You show your expertise.
- You can give the reader a glimpse at your personality.
All these points are super important in getting your first job. But it's difficult for hiring managers to assess your thought process or communication skills outside of a personal interview.
By creating educational content you provide these valuable insights right away. That can get you a step ahead of other candidates.
Now, also blog posts may backfire if they are too chaotic. So here are two tips for writing good content.
- Keep the reader in mind: Ask yourself if you would understand what you write. Identify gaps in your explanations and logically connect your thoughts. This isn't easy and takes practice. But the next step will help a lot.
- Edit the hell out of your content: Once you've written a blog post don't hit the publish button immediately. Let it rest for a bit. Don't look at it for some days. Then come back and read it with a fresh pair of eyes. While you read keep the first point in mind.
At this point, you may be convinced that writing blog posts is a good idea. But you may feel that you don't know enough yet, that your English isn't good enough, or that you have no idea what to write about.
But let me guess: You do the following two things regularly, right?
- You write code, run into problems, and overcome them somehow.
- You learn new things about coding.
It's simple. Pick either of those and write about it.
I personally like the first approach a lot because it gives deep insights into your thought process. And it's relatively easy to write about. Just note that it might be helpful to create a stripped-down version of your code to illustrate the problem. That will allow the reader to follow along.
Kelvin, a student of mine, took the other approach. He learned about integration testing while building the Reddit Analytics app here on Profy. He's not a native English speaker and he was new to testing at that point. But still, he wrote this article on dev.to which even got featured in their newsletter.
I think I made my point: It doesn't take a lot to write a few blog posts. It will be much less effort than building a portfolio website from scratch. But the impact on getting your first job can be tremendous.
If you want to take a deep dive into blogging as a developer I can highly recommend this free course to get started.
Alternative 3: Write detailed READMEs for your portfolio projects
This point is very similar to creating blog posts. Still, it deserves separate mention.
By writing detailed READMEs for your projects on GitHub you can show your communication skills and present your thought process. Surely not in such a deep way as by writing blog posts. At the same time, it's less time-consuming.
To be honest, a good README is a must-have for any portfolio project. Here's why:
Imagine a hiring manager opening one of your GitHub repos. One of the first things they see is the content of the README. Yet most developers simply leave the default content created by "Create React App" untouched.
What a wasted opportunity.
Instead, give some information about your app. Write about your technical decisions. Lead the reader to the most important code.
It can be hard to write your first READMEs, I know. So if you want more information here is a guide to writing READMEs that impress hiring managers. You can also get a template there.
Alternative 4: Optimize your resume
When you apply for a job your resume is the first thing anyone sees of you. Let me point it out again: The very first thing.
This initial contact is likely a recruiter or someone from HR. They will decide within seconds if your resume goes to the trash or if it is worth spending more time on.
I hope you get the importance of getting your resume in order. Without a decent resume, nobody will even look at your portfolio website or your GitHub projects.
Despite its impact, many developers seem to spend a very limited amount of time and effort on their resumes. At least judging from many of the resumes I've seen so far.
Here are my most important tips around resumes.
- Choose a clean template: Please nothing fancy. It shouldn't use many colors. Just clean and easy to read. You can use flowcv.io to create a great resume quickly.
- Fix spelling and grammar mistakes: Start with an app like Grammarly. If you can, get a friend (ideally a native speaker) to proofread.
- Keep the information concise: Use bullet points where you can. If you write a summary paragraph keep it short. If you have work experience mention your impact and contributions.
- Keep the reader in mind: Is everything clear and understandable to an outside person? For example, if you worked for a company in the past, the internal names of projects or features are meaningless to an outsider.
If you want more information here are some simple tips from an experienced hiring manager that can help you create a standout resume.
Now you know how to write a resume. But what about the content?
Obviously, your resume should include all the relevant facts about your personal data, work history, experience, and education.
If you don't have professional experience as a dev yet you should mention your GitHub projects instead. The same is true for any open-source contributions.
To make life easier for the recruiters or hiring managers, add links to your projects (source code and deployed version). If you have any OS contributions link them as well. For example, by providing links to the Pull Requests on GitHub.
Wrapping it up
The results of the survey are clear: The majority of the 60+ hiring managers who took part would look at your portfolio website. But looking at your chances of getting a job we can say:
It wouldn't matter much if you didn't have a website at all.
If you want to build a portfolio website anyway, make sure that it looks great and is maintained. It should be responsive. No broken links. No outdated data.
But be aware that it can take a long time to get everything straight. A portfolio website can become a huge timesink.
So maybe it's better to pick one of the alternatives mentioned here:
- Focus on your GitHub portfolio
- Write blog posts
- Write detailed READMEs for your projects
- Optimize your resume
Each of these will have a bigger impact on your job hunt than a portfolio website. So invest your time wisely.
Top comments (20)
I think this is good advice, but I'd be skeptical of responses saying "I'd look at it, but it wouldn't influence my decision at all". That's like when people say "advertising doesn't influence me at all".
Yeah true, there's probably an influence at least inconspicuously. Similarly to hire you get biased because of a name, a photo, or other information. Maybe your point is also what Louis in his quote is pointing at:
"Websites are cool and look nice but they open the door for more interpretation and criticism because they’d naturally form an opinion."
I actually haven't been to a single job interview where my portfolio page wasn't mentioned as something that helped convince the employer that they wanted me for an interview. I must have done it all wrong! 😂
I love this article... partially because it echoes what I've found from my surveys and career coaching.
The thing is that people form their first impression of you from your resume/cv. They form that impression in 60-90 seconds. After that they'll look at whatever else you've sent.
So while github and portfolio do have an impact on how people view you, the problem is does it change their mind TO YOUR BENEFIT. That is where those materials are like threading a needle a bit and huge time commitments.
Whats worse is you don't have any idea what they're judging you on when they look.
So the order of importance I teach where I can get 100% interview rates is this:
You can get to 100% after number 2, but people won't stop obsessing about 3, so I address it with them. Even after they start getting interviews every time they insist they have to have those extra things.
Hopefully this doesn't turn into some sort of thing about cover letters being a thing of the past.
Thanks a lot for the feedback and sharing your insights. Really fascinating.
I'm curious now. Is this advice also valid for developers without professional experience? And if you don't provide any proof of your technical skills how can you convince a hiring manager of giving you a shot?
So there are two things that it comes down to for me.
First, the interview is where your skills are measured. The resume and all those things provide a strong indication that you'd be a good fit. No amount of portfolio or github replaces that, so thats why they're still secondary materials.
Second, for folks starting off with no previous dev experience, unless they've never worked anywhere they actually DO have experience, just not paid development experience. So their resumes and everything emphasize how they still can deliver results regardless of their environment, and their technical skills is yet another way they can do that.
Its that last sentence that makes the difference. If we reduce ourselves to a collection of technical skills we actually don't have value for companies and teams. The magic is connecting our effort to results.
Focus on your GitHub portfolio
Write blog posts
Write detailed READMEs for your projects
Optimize your resume
those points are, I completely agree. BTW Thanks man for good content.
I agree totally - you really don't need a portfolio site. I've never had one, and all the best devs I've hired didn't have one either.
It's also true that having one can backfire. I've rejected potential candidates due to their portfolio sites before - overengineered, using inappropriate technology for such a simple site, poor code etc.
Thanks for the feedback and sharing your perspective
I have a "portfolio React website" which I use to interview on, as it's a P2P (WebRTC-based) chat / audio / screen-sharing program.
It's neither brilliantly designed, nor even brilliantly coded, but it's a passion project, and cool to some individuals, and that's all that matters to me at this point.
speaker.app / github.com/zenOSmosis/speaker.app
I create my portfolio because it's fun to build & I enjoy doing it, not because If someone will hire me after seeing it, but I would say it increases the chance to land the interview.
Of course if someone wants to create his portfolio just because everyone is creating just to get a job & under pressure it's better not to waste time in such case.
Great sharing, thanks for all those valuable insights.
Inspiring post.
It covers a lot of the stuff that juniors are looking to know.
Thank you for your insight.
I especially appreciated the bashing of portfolio websites and the uplifting of blogs, open-source project building!
Thanks a lot for the feedback. Means a lot that you found it helpful
Thanks for sharing, good advice, I'll keep it in mind.