How to Create a Web Dev Portfolio That Both HR and Other Developers Will Love, with Josh Comeau

Show Notes

🎙 About the episode

Meet Josh W. Comeau 🇨🇦! Josh is a developer, indie hacker, educator, and author. He worked in some companies you might have heard of (including, but not limited to, DigitalOcean, Gatsby, and Khan Academy). He also wrote a book on how to build an effective web dev portfolio. In this episode, we're answering that and many other questions! Spoiler alert: all the advice is actionable.

You'll learn why you need to have a portfolio, how to make one, and is there a formula that works. Josh will teach you how to steal a design for your portfolio website and not get caught and how to develop an eye for design in the long run. Plus: why everybody needs junior developers and how to create an exciting portfolio project even if you don't have any niche interests to base them on. Josh and Alex also discuss handy tools you can use, writing cover letters, and hiring biases in the industry. 

🔗 Connect with Josh

• 👨🏻‍💼 LinkedIn
• 🌐 Blog + Website
• 🐦 Twitter

⏰ Timestamps

• Josh's trajectory from development to education (01:09)
• Why Josh wrote a book on web developer portfolios (02:12)
• Don't put skill bars on your website! What do they even mean?! (04:40)
• Who should you cater your portfolio to, and how to do it? There are two main target audiences. (06:16)
• How does a portfolio compare to a LinkedIn profile or a resume? (10:53)
• Why everybody needs to hire juniors (12:41)
• Can you get away with not having a portfolio? (14:40)
• What to do if you're a developer but not good at design? (16:00)
• Why minimal design could be better (21:53)
• Can you use a template? (23:45)
• What should you put on your portfolio website (25:46)
• How to present your projects (29:49)
• How to choose your projects... and write about them (31:10)
• How to write a good cover letter (34:58)
• How to approach looking for a job (39:07)
• Hiring biases in the industry (40:56)

🧰 Resources mentioned

• Josh's book, Building an Effective Dev Portfolio (it's FREE!)
• xScope
• PixelSnap
• Fontpair

⭐️ Leave a Review

If you enjoy this episode, please leave a 5-star review here and let us know who you want to see on the next podcast.

You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so they can thank you personally for tuning in 🙏

Creators & Guests

Host

Alex Booker

Host of The Scrimba Podcast

Producer

Jan Gregory Arsenovic

Producer of the Scrimba Podcast

What is The Scrimba Podcast?

Learn from inspiring developers about how they found meaningful and fulfilling work that that also pays them well. On The Scrimba Podcast, you'll hear motivational advice and job-hunting strategies from developers who've been exactly where you are now. We talk to developers about their challenges, learnings, and switching industries in the hopes of inspiring YOU. This is the podcast that provides the inspiration, tools, and roadmaps to move from where you are to work that matters to you and uniquely fits your strengths and talents.

Alex (00:00):
... and then I realized I needed to refactor the function, my hands got sweaty, my eyes widened.

Josh (00:07):
A lot of developers think that portfolio sites don't matter, which means a lot of developers don't put that much work into their portfolio site, which means if you put a lot of work into your portfolio site...

Alex (00:16):
Hello and welcome to the Scrimba Podcast. My name is Alex.

Jan (00:20):
And I'm Jan, and this is a show bringing you advise from successful developers on learning to code and getting your first junior developer job. Today we're talking to Josh W. Comeau, who is a developer, teacher, and author.

Alex (00:34):
He's previously worked with some companies you might have heard of like Unsplash, Khan Academy, Digital Ocean, and Gatsby.

Jan (00:40):
Josh wrote a book about building an effective developer portfolio. And that's exactly what he's going to teach us today.

Alex (00:47):
Why do you need one? What makes a good portfolio project? And what, in Josh's varied experiences, are the things hiring managers, and developers, and recruiters are looking for in your portfolio that you need to make sure you cover?

Jan (01:02):
All this and more, today are the Scrimba podcast.

Alex (01:06):
Let's get into it.

Josh (01:09):
I am a front end/full stack software developer from Montreal up in Canada. I've been doing stuff on the web, I started tinkering in 2007, 2008, but professionally been doing it since about 2014. I worked at companies like Gatsby, Digital Ocean, Khan Academy. And in 2020, I left that type of work to focus on education. So I've been creating online courses. My first course is about CSS. I'm working on a react course now. Yeah. And I have a blog too, joshwcomeau.com where I share a lot of developer tips and things.

Alex (01:39):
Your blog is beautiful, by the way. And I think it serves as both a blog and somewhat of a portfolio because you feature some of your projects and a little bit about yourself. I figure it's a really nice segue because the big reason I was excited to speak with you today was about your book, which is about building an effective developer portfolio. For anybody listening, it's quite an interesting story because I was actually reading that book to learn and offer better advice to our new developers at Scrimba, when I thought Josh would be a great person to have on. It got me wondering, what was your motivation to write that book and offer it for free?

Josh (02:12):
A few years ago, while I was still working full-time doing typical software development work, I started working part-time for a local coding bootcamp. Every cohort, which was every 12 weeks, I'd be assigned two or three students to work with that had recently graduated as a career coach. So to help them prep for interviews and essentially to help them land their first job. Part of that was working on their portfolio and their portfolio site.
And I noticed that even in the relatively small number of students I've been working with, the standard template that people use for their portfolio sites, it doesn't do the job that it's intended to do. Which is highlight the work that you've done in the best possible light for prospective employers. And I forget exactly why I did this, but on Twitter, I decided to offer portfolio reviews.
So I said like, "Hey, if you have a portfolio site drop the link, I'll take a look." And 500 people responded to that. So over the course of many weeks, every night, I would go through five or 10 and write a quick couple of paragraphs on Twitter. And I found I was giving the same advice over and over and over again. Because like I mentioned, the standard template, the idea that so many of us have for what a portfolio site should be, or you have maybe a grid with different thumbnails, and then you have the tools that are used, and then you have a paragraph describing what it does.
None of that is really the best possible showcase for your work. And so because I found I was giving the same advice over and over and over again, I thought, "Why don't I put this in a book?" And that way whenever anybody asks, I can redirect them to this book. And I made it free because... Well, there's two parts of it. One is that it's intended for people that are looking for their first or maybe second job. So it's not meant for people that are seasoned professional developers, people that have been in the industry for a long time. And because of that, I feel weird charging money for people that are just getting started in their career.
Especially like you just spent a whole bunch of money on a bootcamp in many cases. But the more, sinister is too strong of a word, because I do think it's not sinister at all. But the marketing angle of this is that maybe they read the book, they get benefit out of it, they get their job and then in a few months, maybe they'll buy one of my professional courses. Which are intended for people who are working as developers. The funny thing is that it doesn't really... People that download the book for a while were putting it into their own separate newsletter. And people in this newsletter are the most hostile to receiving marketing email from me, which I guess makes sense. They're not part of my regular newsletter group.
So it's like I pop out every six months. I'm like, "Hey, here's the thing I'd like you to buy," of course people are going to react a little bit poorly to that. But yeah, that was the reason for the book is just I found out I was giving the same advice. And it worked out perfectly because I think the book is 70 or 80 pages, so it's not huge. I tried to make it as no fluff and condensed as possible, because I didn't have that much to say. But it was too much for a tweet or a blog post.

Alex (04:40):
It's very approachable and easy to digest. And of course it's incredibly useful to hear from the perspective of someone who's had a successful career, but also had exposure within the industry to, "How are companies actually using these portfolios?" A lot of new developers get this good intentioned advice to build a portfolio, but then they end up not even really having a project to show on their project portfolio yet. And then relying on things like skill bars to indicate their skills or adding a bunch of technologies in a huge list. And actually sometimes even though you're taking well intentioned advice, arguably those practices, like skill bars in particular, can do more harm than good.

Josh (05:18):
Yeah. I do think skill bars are probably the clearest example of a thing that many people do that really nobody should do. Because what does it mean to have nine 9/10 JavaScript? You can interpret that in a couple of ways. One is that you know 90% of everything there is to know about JavaScript, which nobody in the world knows that much. So at best, you'll seem overconfident. There's just no good interpretation because the alternative is like, "Well let me be a little bit more realistic. Let me put that I have like 6/10 JavaScript. But then like that doesn't look great either." There's no way to win with it.

Alex (05:51):
And then you ask yourself a question like, "Okay, if I'm a 9/10 with JavaScript, what's Donald Knuth with JavaScript? What are some of my favorite developers like on JavaScript?" And they probably wouldn't give themselves a 9 or a 10, because the more you learn, the more you realize how little you actually know. And so I think an experienced developer looking at someone rating themselves a 9/10, they probably interpret that as, "You don't know what you don't know yet." sort of thing.

Josh (06:16):
Totally. I get the impulse. And like you mentioned, it is very well intentioned people that are just doing what they've seen other people do. The very first thing I do in my book is I talk a little bit about, Who are the people looking at this? This is a sweeping generalization and it's much more complicated and granular, but broadly speaking, the two types of people that look at your portfolio site are people that are in the hiring pipeline, so maybe they work in HR, maybe they're management.
The idea is they're non-technical people who are involved in hiring technical people. Or they're developers at the company who have been pulled into this pipeline to give their opinion. Like, "Hey, we got this application from so and so, take a look at their site." And so those are the two audiences that we have to make ourselves stand out with. And the way that you tackle that it's a little bit different. But in both cases, you want to show the work that you've done because as someone starting your career, it's difficult.
Because if you don't have a previous work experience, you have maybe a boot camp certification, but those tend not to carry so much weight. The most impressive thing you have often is the portfolio projects, the things that you've built. And so if you can tell a story about the things that you've built, and tell it in a way that makes it compelling and not just list like, "Hey, I built a calendar application with React and Redux." That doesn't really tell me anything. "Tell me about why you wanted to build this project? Tell me about the hurdles that you ran into, the problems that you had to solve?"
Even if you may not think you're doing anything super outside the normal course of business, I guarantee there's a couple of problems you had building that thing, and you could tell an interesting story about that. Like the random CSS bug that you ran into and how you overcame it. Those are the things that can be really interesting.

Alex (07:47):
And memorable.

Josh (07:48):
Right. That's the other thing too. You got to figure, if you're looking at a company that's mid-sized or large, they likely have hundreds of people applying to them. And so first of all, a lot of people won't go through the portfolio side, which is a shame. But the ones that do are probably going through 50 other peoples in that same session. And so memorable is a really important thing. You want to make sure that when they've gone through this list, you don't just blend into the group. You want to stand out and do something a little bit different from what everyone else is doing, which can be tricky, but super important.

Alex (08:14):
What you're describing is putting yourself in the shoes of the user. I think that's so important for portfolios. One thing I see quite a bit on portfolios is people do list their skills. And as a design endeavor, they will use the logos of the technologies like Tailwind, for example. But if you see a Tailwind logo, as a HR person, you don't know it's Tailwind necessarily, unless it's the letter mark. Even if you hover over it in some cases, there's no tool tip.
And I'm sure we'll get some more depth about the sections, but I think another thing with projects is people linking to the source code. But to a non-technical person, probably means nothing to them if they just go to get a profile or project with an empty README.

Josh (08:54):
I do think it can be helpful to link to the code. I think in any case, very few people are likely to dig that deep. Honestly, most people will spend 20 seconds scrolling through quickly and they get the impression that they get, unless you find some way to hook them in. The logos is interesting because I totally agree. The idea of just putting the React atom symbol, like it probably is better to list it as an actual word, because I do think often, and I disagree with this as a practice, but my disagreement doesn't stop it from happening.
HR people will look for specific technologies because they've heard from their team, that's what they use. So they're looking for React or Readex because they know that's what they use at their company. The logos may not be serving that purpose as well as just putting the name of the tool. Maybe you could do both, you could put the logo and the name.

Alex (09:36):
Coming up on the Scrimba Podcast. How to design a portfolio when you're not good at designs?

Josh (09:41):
The easiest thing is to steal something.

Jan (09:44):
But first, could you do us a favor. If you're enjoying this episode of the podcast and if you're finding it useful, could you share it with someone on socials, or in real life, word of mouth is the best way to support a podcast that you like. And if you want to make sure we can keep doing what we're doing, you can also subscribe to the show or leave us a rating or a review on Spotify or Apple podcasts. We release new shows every Tuesday and we haven't skipped a week since April 2021. And on that note, Alex will tell us what to expect in the next episode.

Alex (10:18):
Next week, I'm talking with Wemerson, a recently hired junior developer.

Wemerson (10:23):
Basically I've always been related to tech, since I was a child, always taking pieces apart of headsets, my first video game. So I always tried to learn about how things worked. I quit the uni and started doing sales. I was like, "Okay, I need more money." And I started doing sales and working for money, chasing for money, but in the end money doesn't make me happy. And then I said, "Look, I definitely need to eat my humble pie and get back to be a techy side."

Alex (10:53):
That is next week on the Scrimba Podcast. So make sure to subscribe if you want to hear it.
Back to the interview with Josh. How does a portfolio compare to say a LinkedIn profile or a resume? How important do you view it towards the success of a new developer trying to break into the industry?

Josh (11:11):
I wish I had proper data for this. All I have is my own anecdotes. But I've heard enough of them now to know that some companies will never look at portfolio sites and maybe even the majority, although I think it's a pretty slim majority. But for the people that do, you only need one company to look at it and be impressed by what you're doing to get the offer, really to get scheduled for the interview that leads to the offer. So in my experience, from what I've seen working with students and hearing from other developers, it's not many people that look at them, but the people that do, you can really have a pretty good impact.
There's three pieces, right? There's the resume, the cover letter and the portfolio site. And often the cover letter is arguably maybe even more important in terms of standing out in that immediate first impression. But in terms of really trying to stand out and impress somebody, the portfolio site is such an amazing opportunity to do that.
And the fact is a lot of developers think that portfolio sites don't matter, which means a lot of developers don't put that much work into their portfolio site, which means if you put a lot of work into your portfolio site... As a new developer, you should always be looking for little ways to find advantages because there's a ton of competition for a relatively small number of junior developer positions, which is itself a shame. So yeah, I do think the strategic angle, maybe I'm over strategizing or trying to over engineer this process, but essentially find a place you can shine in that process.
And often the portfolio site is one of the best places to do that, because with a bit of effort and strategizing, you can really create a portfolio site that stands out from a group. And even if not every company looks at it, the companies that do will be like, "Whoa, this is something different and interesting."

Alex (12:41):
Yeah. I think as a new developer, you are often disadvantaged in some ways, and you're a little bit of an underdog. What you're describing is just stacking the deck in your favor as much as possible.

Josh (12:51):
Yeah, no, definitely. And it's frustrating to me because one of the companies I worked at, I kept advocating for like, "We should be hiring more junior developers. Not because it's like good for the industry because it's good for us as a company. Bringing new developers in energizes the more senior developers, because there's a contagious energy that often comes with people that are starting their careers. It makes it better for our code base because it reminds us that we have to write code in a way that is accessible. If we build code, trying to make sure that a junior developer can understand it, we'll wind up with more understandable code, which is a good thing for everybody."
And there's just so many reasons that it's good for the team to have a balanced set of experience levels. And I think a lot of companies really, they try to find the best developers or not even the best, but the most senior. The people with the most experience, it's really important to have that balance. But I know from working with students and doing the career coaching that oftentimes they're not even applying to junior jobs because those don't exist. You're applying to intermediate jobs and hoping that you can find a way in any way.

Alex (13:46):
I have come across that a few times and it's certainly worth giving it a go. A lot of companies either don't specify the seniority or they're just not sure yet. A lot of job ads are feelers from companies. And if the right person comes across, could be you listening, then it's certainly worth giving it a go. But I really appreciate you outlining some of the reasons why junior developers are awesome. You know it, I know it. It's not always so easy to convince yourself when you're a new developer on the back foot, but it's great when senior developers are put in positions to mentor others, because that will challenge their understanding and help them then teach it.
And from an industry perspective as well, there's only a finite number of developers in the ocean, say. If you just fish all the fish and don't replenish the supply in any way, that's just selfish and is a bad thing overall. It hurts in the long run.
But do you need a portfolio or could you get away with... because LinkedIn has a projects section. And you could arguably, if it's freelance work, put that under work experience or volunteer experience, there's a section for that. But also GitHub in recent years, since they added profile READMEs, people have got super creative with highlighting their projects, their skills, their work, because a portfolio can take so much time and effort to get right, how does it compare to those other ways of demonstrating your skills, aptitude, and projects?

Josh (15:02):
You know, it's interesting, because I don't actually have that much experience. I haven't seen the results of spending a lot of time to put a lot of work and making your GitHub profile README served the same function. I imagine it could, it certainly doesn't have to be a portfolio site. What you want is that ability to hook someone in, tell a story about who you are, what you're doing. Find some way to stand out. None of this stuff requires a portfolio site. And really, I think the ideal strategy includes cover letters, which we should also talk about at some point, because I think are super important.

Alex (15:29):
Definitely.

Josh (15:29):
But yeah, no. It doesn't have to be a portfolio site. But I do think when you're talking about LinkedIn, you are beholden to the way LinkedIn structures things. Maybe you can rearrange the sections, but even if you can, you can't add two pages worth of content to a project without them tucking it behind a read more expander, you're beholden to their presentation. And one of the cool things about building your own portfolio site is you can really tailor it to highlight the stuff you want to highlight, guide people through in the way that you want to. There's a design challenge there, which I know is tricky for a lot of developers.

Alex (16:00):
What do you do if you're a developer, but you're not good at design?

Josh (16:03):
The easiest thing is to steal something. And let me very quickly caveat that, steal it ethically. Find three or four sources of inspiration, even actually what I encourage people to do, template builders like Wix or Squarespace, you could use them. Although I think you may as well build it yourself, if its good practice for the skill set you're trying to develop, but you can copy their templates because a lot of their templates are quite nice. Just rebuild it and try to change a few things. You don't want it to look like an exact clone because if anyone recognizes it, it's not a good look. Plus you're building something custom, you want it to look a little bit custom.
But I think the quickest solution to building something that looks pretty good is to find three or four different sources of inspiration and take the layout from this one, the colors from this one, the typography styles from this other one. You still need to think a little bit critically in terms of trying to figure out if it looks good or not. But it's much, much... I don't want to say the term easier, because it's still not easy, but it is less daunting than starting from a blank HTML file and trying to come up with something that looks professional.
That at least gets you 75% of the way there. I wish we lived in a world where when you create a portfolio site for a development job, the design, in terms of like the UI design, shouldn't matter because you're not applying for UI design jobs. But I think its human nature that if you have two people applying and one of their portfolio sites looks really professional and well designed, that influences people. Compared to another one that is choppy and looks as amateur as you would expect for someone that doesn't have design skills, designing a website.
But in my experience, I think that it has worked the most. Two or three sources of inspiration and combining them to build something that still doesn't look too much like any of them, but still looks pretty professional.

Alex (17:37):
I'm not a designer, I'm a developer and I've relied on that strategy for a long time. It's a great way for you to feel inspired and get started. And only over time, can you develop your own aesthetic style and creative ideas, by which point you will be a designer. Do you have any advice on how to either improve your intuition, when you are designing? Or at the very least seek feedback that can help you make the tweaks you need for it to look cohesive and pleasant?

Josh (18:02):
The ideal case is if you have designers in your network, you can ping them and be like, "Hey, can you critique this for me?" Of course not everyone has that privilege. I like that you used the word intuition, because that really is such an important thing. And even if you're of the attitude that, "I'm a developer, I'm not a designer. I don't want to spend time learning a skill that isn't development." You will be surprised by how helpful a little bit of design intuition is as a front end developer specifically.
Because when you work as a front end developer, you'll be given a design in Figma or Sketch or something like that. That design is never going to be... At best, it's a 75% of the way. And what I mean by that is if you're lucky, you'll get mobile tablet and desktop and you'll be given loading states maybe, but it's up to you to figure out how things should flex and grow and scale between those three fixed sizes.
It's super common that designers will omit or forget to include loading states and error states. What happens when the data in the mockup, which is all these small and nice little names, when it encounters real data where like, "Oh, some people don't have a name field. Some people have a name that's 125 characters. Like how do I fit that into the design?" Those are design questions, and if you can build a bit of an intuition, it really helps with that.
Because the alternative is every time you hit one of these situations, you have to ping the designer and say like, "Hey, I'm stuck here." And then you're blocked waiting on them to get back to you. And maybe they're not there right now, especially with everyone we're working remotely, they might be in a different time zone and they might not see your message until tomorrow.
It's to the point now in my own career where I've never done any professional design work and I've never trained as a designer, but I've built enough of an intuition just from working in development and context. And also as a developer with side projects, needing to design them, because I don't have a designer, that I've built up enough of an intuition now that in most cases I can take an educated guess about like, "Okay." Especially if you understand the context behind the design's. Like what model the designer is using, you can say, "Okay. This is what I imagine I should do."
And you can unblock yourself and maybe 20% of the time I'll get it wrong and the designer will say like, "Oh actually we should do this instead." And that's fine, I can go back and change it. But because I have pretty good confidence in what I'm doing, I can just keep rolling with it.
Now in terms of how to develop that intuition, the honest answer is it just takes some time. And if you're hoping to build something in the next couple months, that's not really an option. But I would say start looking really critically at the things that you use every day. Pay attention to spacing, pull up three or four different websites that are similar to yours and see how they spaced things and how it feels to you. I've noticed a lot of the time that font sizes and spaces are the things that are all over the place on developer portfolios.
So if anything, you can just steal those elements. Come up with your own layout, come up with your own colors, but then just steal the font size and the specific number of pixels between the headings and the paragraphs. That'll make such a big difference.

Alex (20:42):
You're saying that a really great design tip is when in doubt be consistent, same font, same patterning, same line heights. If you have images, maybe put them all in rectangles, all in ovals, try and use a consistent of color palettes.

Josh (20:56):
Yeah. And just to make sure what I said is clear. Steal the spacing from something else that you think looks good. And there are tools that you can use, like xScope is one, PixelSnap is one I discovered recently, it's a macOS exclusive. But what's cool about it is you toggle it on, and then using contrast, it's able to draw the distance between two elements. So you move your cursor between the heading and the paragraph and it shows you like, "Oh, there's 72 pixels between these two things."
Granted with typography it's a little bit tricky because it's giving you the distance between the bottom of the characters in the heading and the top of the characters in the paragraph and on the web there's built in spacing. You can't then take that 72 pixels and slap that in padding or margin. But be as precise as you think you can in this, have your site next to some other site and then visually try and make sure that the spacing looks pretty close to identical because spacing in particular is just one of those things that it takes forever to build an intuition. And no one's going to notice if you steal the spacing from some other site, if everything else looks different.

Alex (21:52):
Yeah. You can't patent that.

Josh (21:53):
Yeah.

Alex (21:53):
Another good utility for non designers is Font Pair, which gives you Google fonts that pair well together. Another piece of advice I could share, I don't think ambitious developers want to hear it, but sometimes the right thing to do when you're not good at designer is to actually lower your ambition a little bit. It's very nice and exciting to look at an awesome portfolio and think, "Oh, mine needs to look like this to be competitive." But probably you're looking at the portfolio of somebody with far more experience.
And what often happens, in my experience helping new developers is that they underestimate what they can do in a couple of weeks. And what that leads to is analysis paralysis, procrastination. It never really gets done or you have to cut so many corners. It would've been better if you went with something in quite a minimal style. Do you think that if your portfolio doesn't look very good, I sometimes wonder if it hurts you more than it helps you? Because at the end of the day, every company is looking at you as a potential web developer. They're going to assume it's your best work even though it might not be a fair thing to assume.

Josh (22:55):
It's a great question. And I imagine it could, it makes sense to me. It probably depends on the company too. Like I mentioned earlier, there's two audiences you're appealing to. You're looking to appeal to developers and to HR folks. I would expect that when a developer is pulled into the hiring pipeline and told like, "Hey, we have this candidate, here's their information. Here's their resume. Here's their portfolio site." Maybe the developer would be able to look past that. And if the content is really good, it still helps you more than it hurts.
And I think what the advice that you gave about keeping things minimal, it's true. My own blog is maybe a decent example of this. I put lots of little details in, but this is the third or fourth version of my blog and my first iteration did not look anywhere near as good as the one now.

Alex (23:34):
Great word by the way, iterating, because the thing about developers is that we iterate on websites. It's not like a book or a movie when it's done, it's done. The whole point is that you're meant to iterate on it.

Josh (23:45):
Yeah, Totally.

Alex (23:45):
When does it make sense then to use a template? I certainly get that a template is a double edged sword. On one hand, you're trying to stand out and if you are using a generic template, there's a chance you may be in the same cohort of applicants, easy enough to mistake. And that could be a bad thing, but also if you're not particularly design orientated or maybe you're in a pinch, a template can be a great thing to lean on. What's your advice?

Josh (24:09):
I think it gets back to the idea of finding two or three templates that you like and mixing them together. Because it's true, there are probably three or four... In fact, when I was doing that thing where I asked for portfolio sites on Twitter, there were three or four people that had an identical website. They all just took the same source, inspiration and copy pasted. Or maybe they re-implemented it, but either way it looked pixel perfect. And you don't want that. That's not great.
I meant to mention earlier one of the reasons to focus and follow your advice on building something a little bit more minimal is that you don't need it to stand out. You don't need it to be the most beautifully designed portfolio. That's not really the goal, because you're applying for developer roles. You just want it to be well designed enough that the design doesn't bring it down, that doesn't call attention in a bad way to it.
Ultimately, it's probably not the worst thing in the world if you take a template and just run with it. But mix two of them together and make it a little bit unique. You also want to include some of your personality, like if you're a particularly colorful or serious person, it's fine to make tweaks to let it be a little bit more personal to you. But the goal is just to make sure the design gets out of the way so that you're not distracting from the content, which is the important thing.

Alex (25:18):
That's a great way of looking at it. No one looks at Wikipedia and goes, "Wow, this is a mind blowing design." But it takes every single box when it comes to clarity, and so maybe think of your website and your portfolio a bit like a personal Wikipedia. You can make it look really beautiful with fonts and spacing and things. That begs the question and something I've been quite looking forward to speak about, which is what should that content be? I think we know projects, that's something we spoke about before, but there are all kinds of things you can put on your portfolio.

Josh (25:46):
The layout that I like, that I think ticks all the boxes that I personally think are important, I like to have some sort of hero, some sort of main thing that you are shown when you first load. Often that can include a photo of yourself, if you're comfortable with that. Your name and then some sort of brief, maybe four or five sentence description of who you are, what you're looking for. And this is where I think you can have a bit of your personality shine through. You can really make this custom to the person you are and the work you're looking to do.
Below that I like to have projects. And typically what I like to do is I like to have either a grid or a list where you have, this part is fairly typical, maybe you have a screenshot or a logo or something, the project name, a short description, but then critically a link to view more information about it. Because I think every project should have its own page and that page should go into deeper detail about how the project works. In general, I think you should have between two and five projects. You don't want to put everything you've ever made on that because realistically people are going to look at one, maybe two things and they're going to pick randomly.
If you built a calculator in half an hour and it's your 17th item in the list, that might be the only thing someone sees, which is not great. So two to five, something like that, projects and the thing and then below that you can have contact information, you can link to the resume. I don't think that type of thing matters. It's fine, it doesn't really matter. Often the portfolio site itself is linked to from a resume, or a LinkedIn, or a cover letter, or something so that the portfolio site often doesn't have to be comprehensive in that regard. Although it certainly doesn't hurt.
I think it does help to put either an email address or a contact form. Contact forms are nice where people like doing that rather than having to right click and copy email, because no one clicks on mail to links anymore. But no, I think all of that stuff, it's easy to get a bit of decision paralysis around that when ultimately I don't think it matters that much. I don't think you need to put your work experience there because you have your resume for that, you're LinkedIn for that. It's okay if it's pretty minimal, it can just be a photo or an illustration, some sort of decorative thing at the top with your name, a couple of sentences and then a list of projects.
And each of those projects can have, as we mentioned earlier, their own page that describes what is this thing? Why did you build it? What were the interesting things you ran into with it? What have you learned from this project? If you want, you can have a video because people do that. I don't know that people actually watch the videos, people breeze through these things because they have a stack of them to get through. I certainly wouldn't just have a video, if you want have a video that goes through the same stuff, but in video format, that's fine. Maybe people do watch them maybe.

Alex (28:08):
With your face, you mean?

Josh (28:08):
What I've seen more often is the screen recording. So like you're going through, you're saying, "Okay, this is my project, This is the log in flow." Honestly, I don't think that really delivers a ton of value unless there are really interesting things in your project that really only make sense to be displayed in that way. If there're intricacies that you want to highlight that are harder to do.
The most effective portfolios I've seen, in my opinion are where you have text description for the project that are interlaced with screenshots, that show what you're talking about. So you might say that you built a coffee roasting eCommerce platform and you really struggled with the best way to implement some quantity, like the cart system. And so you talk about the challenge with that. And then below that you have a screenshot that shows the little add to cart thing with a little modal that's come down and the quantity toggle. Those are the types of things that I think can be really interesting for the developers who pop by and check out your thing. And even for HR folks, there's so many reasons to do it this way.
One is just that it shows your passion, it shows you're actually interested in the problems that you're solving and you want to highlight that. When you have the typical thing where it's eCommerce platform, built in React Redox, a single screenshot. What does that tell me about why you did this and why you wanted to do this? It just feels like you're ticking a box. Someone told you that you need to build a portfolio project, so you spent a weekend on something and now you've ticked that box and you're ready to move on.
It might not even be the case. That might be totally a misrepresentation of how you feel about it. But that's just the impression I get when I see portfolio sites that just have the thumbnail and a couple sentences and the list of technologies and it's maybe a little bit unfair even that we expect passion. Nobody expects when you graduate from dentistry school and you're looking to become a dentist, no one expects you to talk passionately about cavities. So it's a little bit of an unfair thing in our industry, but it is something that employers look for.

Alex (29:49):
I think again, it's so important to remember it is a project portfolio and the projects are probably the most important thing you need to give them emphasis with the amount of screen real estate you give to them, their presidents and the websites. I think having a dedicated page is how you solve both those things, actually. I always look for that when I review portfolios, is there a slash project, slash project name, URL where you can like read more about it? I do totally understand the why people don't do this though. Maybe there's three reasons.
The first is its more effort to build that page, but I would argue you could make it a blog post and link to it as a stop gap. And the second reason is what you said, really Josh, just that there isn't really that much of a story to tell. You built it because you thought you were meant to. And maybe if you're building six okay projects, you should have just built one that you're really passionate about and can tell a story about.
And the third thing, which I really want to get your advice on because you've mentioned it a few times. You talk a little bit, and I do too, by the way, about telling a story. Which I think to you and I sounds intuitive at this point, because we write a lot of stuff and I'm doing a podcast, you're creating courses and things. I think we think a lot about how to convey information in a way that's going to captivate people and make them feel like it was worth reading. But just like a developer is not necessarily a designer, a developer might not be a writer or a storyteller. What does that mean when you say storytelling?

Josh (31:10):
This is a skill in itself in the same way that design is a skill that it helps to have an intuition of, to design a portfolio. It's not always easy to come up with a narrative for a project, especially if your project is someone told you needed a project, so you looked online for a project idea and someone mentioned build a calculator. So you said, "Okay, I'll build a calculator." Maybe even a precursor to what we're talking about now is how do you come up with a portfolio project? And if you answer that question correctly, then you solve this other part of it.
I'm a big advocate of building things that appeal to your non-programming interests. And as an example, I used to yo-yo semi competitively, I really liked yo-yoing. I still do it every now and then. So the idea with these yo-yos is most of them are metal. They come in different diameters and widths and weights. Those are the three stats of a given yo-yo. So maybe it's a 65 millimeter diameter and a 45 millimeter width and it weighs 62 grams. This company that I liked had a dozen yo-yos and they all have their own different stats. And one of the first things that I built was, I use a radar graph, which is those circular things where you have the polygons inside.
So one of your axes is weight, one of them is width and I overlaid... And you could mouse over different yo-yos to see how they compare just as a data visualization for different yo-yos as a way to understand intuitively what the difference is between these 12 different yo-yos.
And it's exactly the sort of project that nobody else would build. It's not the same to do list application that everyone builds because it's what you think you should build. And so when you do something like that, and obviously I'm not saying build a yo-yo comparison tool, but build something that is important to you or interesting to you beyond programming, then it's much easier to tell a story about that than it is to tell a story about another to-do list application.
And I know that a lot of people struggle with this, it works if you happen to have these niche interests, but a lot of people don't. And I've heard this from so many people now that they like TV shows, they like hanging out with their friends. How do you turn that into a project? That's totally fair. But I think if you do a bit of thinking, everyone has things that they like and you could build a tool that would help you index TV shows, that's something that... I actually built that exact tool a while ago.
I built a tool that would help me remember and track TV shows I wanted to watch. So even if you don't have these like specialized interests, there're ways to find projects that are a little bit more personal to you. And then when it comes to describing them in the page, you can talk about why you decided to build this thing. And it's a totally fair point, especially not everyone speaks English as their first language. And so that's an additional hurdle that I know is tough for a lot of people. How do I tell this in a way that is coherent?
And I don't want to minimize that challenge because it's a real thing. But yeah, I think that it doesn't have to be Shakespearean quality. It doesn't have to be literally the same way that a fiction book would be. It just has to be a few paragraphs that talk about what is this thing? Why did you build it? What did you learn building it? And I know that's another question that's hard for people to learn because it's part of development. We all hit random error messages that we have to Google and find solutions for. But maybe you don't remember those things when you're coming to writing the solution. But even just picking a random part of the thing, if we were building a to do this list application then there are parts of that are difficult.
How do you track this date across this application? How do you manage, when you tick the thing, how does it get updated? Even if it's not a novel problem that you're solving, you can still talk about your approach. And especially if you had any sort of refactoring, if you built something and then you realize later, "Oh, there's a better way for me to build it." That's like the perfect thing to put in this page, because that's gold in the eyes of the developers that are coming and looking at this and trying to figure out if you'd be a good addition to their team.

Alex (34:34):
You're not trying to write the next Lord of the rings, Star Wars, song of Ice and Fire or something. You're not meant to write in crazy pros and be like, "... and then I realized I needed to refactor the function. My hands go sweaty, my eyes widened."

Josh (34:51):
In fairness, if you do have a background in literature, that would be a really interesting way to do it. But no, certainly that's not the expectation.

Alex (34:58):
Let's talk finally a little bit about cover letters. As you mentioned them earlier as being really important, and also I think actually the cover letter ties in a lot of things we spoke about today. First and foremost need to consider who's reading it and what they want to see, and then you have to match that with what you have to offer in an authentic way. Just starting with the basics. How long does a cover letter need to be, and what are the key points you need to hit?

Josh (35:20):
In general, I advocate for less than a page, like half a page, three quarters of a page. You don't want it to be more than a page. I can imagine the feeling of opening up a cover letter, seeing that it's more than a page and just being like, "Nah, I don't have time to read that." So shorter is better, but obviously you don't want it to be three sentences, it needs to look like a page that has stuff on it. It can't look like it's just two lines.
In terms of what it should cover, and this actually gets to another broader thing. I've worked with so many students now who started with the shotgun approach of like, "I have a target. I'm going to apply to 40 different positions every day." And so every position is a 32nd effort where you have a template and you swap in the name of the company and you swap in the like, "I am interested in Generic Corp industries because I have passion about manufacturing."
And those are the two... you're playing... What's that game? Madlibs. You're playing Madlibs and just slipping in the names. Don't do that. On the other end someone's receiving this and it is immediately obvious. I've worked for companies where I've been involved in hiring both as the developer that gets pulled in, but I've also worked at smaller startups where I'm the hiring person or I'm scheduling the interviews and doing the interviews and having a pretty big vote in terms of whether we decide to hire someone or not. And 75, 80% of the applications that we get are clearly zero effort.
Unless there's something really remarkable about that person, like if they have a ton of relevant experience, then maybe we'll overlook that. But generally if someone has put zero effort into the application, it's clear that we're just one job out of 100. And you know companies like when people apply to jobs they actually want to work at. The biggest advice that I give students when I work with them is pick maybe one or two jobs to apply to a day and put an hour into that process. Come up with a new cover letter. It's fine if there's... often cover letters will have portions where you're talking about yourself and that part you can copy and paste.
But you should have a novel cover letter for each company. If the company's really interesting to you might want to spend time playing with their API or if they have any public source code, getting familiar with what they've made available and talking about that. It's certainly a riskier approach in terms of you might spend one or two or 10 hours working on an application for a specific company and the company maybe filled the role by the time you apply. So there's a risk there, but it's certainly worked better from what I've seen than just the shotgun approach of a million things.
In terms of the things I think are worth putting in a cover letter, you want to hit two points. One is, why am I interested in working for this company? What about this company has appealed me, has drew me in? It's like, "Oh, I could see myself working there." And the second thing is, why do I think I'd be a good fit? So one of them is, "Why am I attracted to the company?" And the other is like, "Why should the company want to hire me?"
I don't know if you know about honey bees, this interesting thing happening with bees where there's not enough of them, the hives are collapsing for unknown reasons. So there's a lot of effort being put into making sure... because bees are so important for the whole food chain process. And so someone was applying to a company that worked in this industry and they took the time to learn about that industry and figure out what the deal was. And so they talked about that in their cover letter, "Hey. I didn't know much about this, but I've been looking into it and it's really interesting. And it seems like a really important problem that you're solving." And then you segue to like, "I've built similar things in the past. I have this project over here that seems like it's vaguely similar. And I think in terms of the culture..."
Often companies will make public their culture doc, a bunch of different names for these things. But the company values or things like that, if you can go through the company's values and find ones that honestly, and legitimately appeal to you or that like resonate with you. I used to work for Digital Ocean briefly and one of their value had the word love in it. It's like, "Do things with love." They have a whimsical brand that I actually did think spoke pretty well to me. So I mentioned that in my cover letter to them. Things like that I think really help. Clearly putting the time to build a cover letter that is specific to the company, because people notice that because so few, again, so few people do it this way, that when you do it this way, you become memorable.
You stand out when the hiring manager's gone through the stack of 50 applications, you are one of the two or three people they actually remember and forward along for the next step.

Alex (39:07):
Words come easy when they're true. If you genuinely found the company for a reason and you're excited to interview there for a reason, whether it's the tech stack, maybe you follow someone who works there on Twitter, maybe it's something they posted on LinkedIn. I really like your idea which I've never heard before to match your cover letter with their company values. I've always done the laser approach. It's always been a no brainer to me, but I come into the Scrimba podcast with an open mind. I've interviewed probably 50 people who've found success and it's a pretty fair mix.
Some people still find success using the shotgun approach. I still maintain the... and I agree with you, Josh, that you should do whatever you can to stand out and be memorable. Not least of which the point of the cover letter and the resume and your portfolio is to get your foot in the door and do an interview. I genuinely think that its human nature, that people are more likely to reciprocate when you've put some demonstrable effort forth. Maybe you can't afford, time wise, to do it for everything. But if you see an opportunity where you're like, "Ah, I see the ways in which I could be a good fit here." That's when you need to reference your book, I think Josh, because you write a bit about it and likewise draw on the advice on this podcast to write a good cover letter.

Josh (40:13):
I think you can actually take a mixed approach. For example, some companies it's impossible to do this with. Let's say you're an agency that you build client websites for different companies. All of those companies are sort of the same, because they don't have a unique product. They're an agency. And maybe they have an interesting company value. Maybe they do have some distinguishing features, but there's a lot of companies where it's hard to argue for the passion case as to why you want to work there, when there's 100 companies that do the same thing.
You can spend the time that is appropriate, that is proportional to how much energy and enthusiasm you have for a company. So put a lot of work into the companies that you're really interested in and then spend five minutes on the ones where you're... And who knows, maybe that will pan out because for certain companies it's just hard to imagine doing it any other way.

Alex (40:56):
During this interview, you've said a phrase a couple of times, which is that you don't have the stats for this. And I really appreciate that because I think it's important we take a measured approach. But equally I wanted to ask you what role do you think bias plays in the interview process or in the application process, when people are evaluating your portfolio, LinkedIn, et cetera?

Josh (41:18):
You know, I'm glad you asked about this because I want to amend something I said earlier. Which as I mentioned that you could put your face on your portfolio site and that's questionable advice. Especially if you're not a white man, which I hate saying. I wish it wasn't that way, but you read these studies about how, if you have a name that isn't a generic white person name, it's going to be harder for you to find a job which sucks. That's a really important thing to mention that certainly bias exists in our industry. I wish that we lived in a world where those biases didn't exist. And I think the best way to fight those biases is to push through the system as it is now, and then work to change the system. And I think that us white folks have a role in this as well. Which is to make sure that we're advocating for people who don't look like us in this process, which is something that I've tried to do whenever I can. And hopefully it's just one of those things that improves slowly over time.

Alex (42:07):
A person reviewing a cover letter, they have their own biases and it might be to do with your name, race, origin, whatever. But it could just be that they've interviewed people with a similar work profile and it just didn't go well. What I'm getting at is it's not an exact science, there is a certain degree of fortune and the only way you counter to balance that is by stacking for deck in your favor, whether you put your picture on a resume or not. All it really does is stands to waste valuable real estate and potentially cause someone to be biased against you on your portfolio, you certainly don't have to include one either.

Josh (42:40):
It's impossible to know how the person on the other end is going to receive whatever you produce to a certain extent. You're never going to win everybody over. And so it just becomes about find a way to make your portfolio representative of who you are and what you're comfortable sharing. Ultimately, the silver lining to this is that it will automatically tune out people. If you really believe that you've put yourself onto this portfolio and it's an accurate representation of who you are, then hopefully the people that it resonates with are people that you would actually like to work with and work for.
Granted, the further you get into your career, the more obvious this becomes and the more control you have over the process. But even at first, even if you're looking for your first job, it's a two-way street. You are interviewing them as much as they're interviewing you. It is a good way to make sure that you are filtering out the people that you wouldn't want to work with anyway. And I think it's important to keep that in mind.

Alex (43:29):
Thank you so much for joining me on the Scrimba Podcast. It's been a pleasure.

Josh (43:32):
The pleasure's all on this side of the table. Thanks for having me.

Jan (43:36):
That was Josh W. Comeau. Thank you for listening and make sure to check out the show notes for all the resources mentioned in this interview, including Josh's book.

Alex (43:46):
If you've made it this far, you might want to subscribe for more helpful and uplifting episodes with recently hired juniors and industry experts like Josh. As a reminder, next week I'm speaking with a recently hired junior developer. So we can learn from both sides how you can find success in the industry. Also, don't forget to tweet at me your host I'm Alex Booker, and really share what lessons you learned from the episode, so I can thank you personally for tuning in my Twitter handle is also in the show notes.

Jan (44:12):
This episode was produced by me, Jan Arsenovic. We will see you next week.