FAQs For a Software Engineering Hiring Manager - Part 3 of 5: Portfolios & GitHubs

Technical Interviews have evolved a lot since I transitioned from being a Software Engineer to an Engineering Manager. Particularly in the post-Covid era, there's been a greater emphasis on the person, which I think is an important and welcome change.

Over the decade of interviewing hundreds of coders, I've also had the pleasure of working with various bootcamps, colleges, and hundreds of individual job seekers on LinkedIn. Across all the changes over the past years, across the various locations and mediums, something remained consistent throughout: The questions I get asked.

With that in mind, I thought - why not make a FAQ from my perspective as a hiring manager?

While this is my perspective, it's based on years of observation and supporting data. But that being said, advice is not fact. You may disagree with certain points, and that's OK. Opinions we disagree with allow us to better understand our own views. At best, I hope these responses help you land your dream job. At worst, I hope they'll help you form your own ideas on how to approach your career.

In this part, I’ll focus on the questions I’ve received about portfolios and GitHubs.

On Portfolios

1. Do I really need a portfolio/website?

   It really depends - but I'm hugely in favor of them. Resumes show me your professional side. Portfolios show case your personality, your interests. They give hiring managers a different sense of who you are, and how you are looking to grow.

   
   

   Of course, not everyone needs one - or has the desire to build one. I know many successful coders who don't have a portfolio/website and never needed one. In fact, most of the developers I know don't have one. And if that's the case, why do I push for them?

   
   

   The simple answer is it's an odds game. Tech Hiring is a wild world right now - there's lots of demand, lots of candidates, it's ultra-competitive but people are also struggling to find jobs. A portfolio isn't going to guarantee you land a job, but it gives you a meaningful edge over other candidates provided you do it right.

   
   

   Your portfolio doesn't have to be a huge undertaking - and because the benefits far outweigh the costs, I think building them makes a ton of sense. Because portfolios are personal, I think people get overwhelmed by "the art of the possible" - and then they never actually produce anything.

   
   

   If you build your portfolio iteratively, starting small, and only expanding as needed and as you have the time, it's a great way to establish yourself.

   
   

   For more, here are some resources on how to build yourself a killer portfolio:

   • Let's Talk Portfolios!

   • Let's Talk (Even More!) About Portfolios!

   • 7 Steps to Building your Portfolio MVP

   • Lumbot

     
     

2. What do I even put on my portfolio?

   First off, know your audience. Your portfolio isn't for your friends, your family - your real audience is the hiring manager. You want to focus your content such that it's easy to consume - so focus on how you lay things out. Think of it as your resume + creativity. Add some style to it but make it usable.

   
   

   I'm a big fan of quick visuals that help someone get an impression of what you can do - so whether it's listing your languages, listing your years of experience with each, listing your projects, make it visual, interactive, but don't add any "friction" to it either. By that I mean, slow slideshows that require me to sit and wait for things to fade in and out is not a good approach. List it all so I can see it, consume it, and move on.

   
   

   Another thing is: give it some life. Don't make it look like you built it years ago and forgot about it - add some dynamic elements, so it's always looking fresh. Have it feed off your twitter, or just build a small integration into your blog, or just have a "micro-blog" that keeps people up to date on what you're working on.

   
   

   The main content is all around your projects. What have you built, what are you building. Include nice write ups that cover what you've learned, what challenged you, what you're proud of, what you'd do better. Impacts and Outcomes.

   
   

   This template I made is the bare minimum that you should list. It's all static, it has minimal design elements, but it really helps a hiring manager understand who you are:

   
   

   
   

   

   
   

   As you can see, the key things to list are:

   • The Tech Stack & Methodologies you know

   • A mini-bio

   • Important links - to your GitHub, your resume, your LinkedIn,

   • Quick visuals that summarize your career

   • Projects, with the tech stack and links to GitHub

   • "Live" sections that you can easily update with what you're working on / reading (update these maybe once a month.)

     
     

   Like I said before, it should take you more than a weekend to build something like this and it'll help give your application that extra bit of edge.

   
   

   As you grow in your career, updating it becomes pretty trivial.

   
   

3. Can't I just use GitHub?

   You can - yes. But don't just dump your projects on GitHub and call it a day. Build a proper GitHub landing page and use that as your portfolio.

   
   

   You can build it using GitHub Pages - just follow the same principles as I listed above.

   
   

4. Should I get my own domain name?

   You don't need one - but having your own domain is like having your stationary. It's a nice touch.

   
   

5. How personal should I get on my website? Should I share family photos? Recipes? A picture of my pet salamander?

   Share what you like - just ultimately know it's purpose. It's not meant to be a Facebook profile - but it's also not meant to be a LinkedIn profile either. Your audience would be a hiring manager.

   
   

   Help them get to know the social yet professional you.

   
   

6. Should I worry about SEO, page ranks, etc.?

   No. That's over doing it. Keep your HTML clean - but don't stress over it either.

   
   

   Only do what is most relevant to the roles you pursue: If it’s a Node developer, build things with Node. If it’s SEO, then sure - optimize for search engines. But if you’re a SQL Engineer, I’m likely not going to judge you on your HTML/CSS skills.

   
   

7. Should I include a downloadable resume / my email?

   That is ultimately up to you - but if you do include either, be weary of what information you make public. Maybe remove your phone number from your downloadable resume. Make sure your email provider will filter spam.

   
   

   Alternatively, direct people to your LinkedIn or include a form where they can get in touch with you.

On GitHub

1. What should my GitHub landing page look like?

   Write a simple ReadMe that mimics the content on your portfolio. Simple, clean and elegant. You're going to want to keep it up to date, so make sure you build it in such a way that it's minimal effort.

   
   

   Pin your projects and include important links to your portfolio/LinkedIn.

   
   

   You don't need to overdo it though. While there are some amazing ones out there, I think keeping it simple is the best approach (unless you are building this in lieu of a portfolio).

   For reference, here's my own GitHub landing page: GitHub - Alishah Novin

   
   

2. Do I need to really build out my project pages?

   Make sure you have a ReadMe file. You can do a lot with them - and I'd approach them as if you're writing it for other developers (secretly thinking about the hiring manager.)

   
   

   In a professional setting you'll often need to explain what a product or feature does, how it should be used, what its limitations are, etc. This is your opportunity to showcase that to a hiring manager - so while you are writing it for other developers who will consume your project, remember your real audience is the hiring manager.

   
   

   Provide an overview, provide screenshots, provide a change log. Document things to show that you can communicate technical concepts.

   
   

   As another example, for reference, is my GitHub page for code / collision. Keep in mind, there are far better ones out there, but I built this page out to give a sense of what your bare minimum should look like.

   
   

   Do not just upload your project and call it a day.

   
   

3. Do I need to worry about the quality of my code, or how much I've commented?

   Your code will be looked at, yes. People will look for comments and read them. They likely won't go into super detail, but you will want to make sure your code files are presentable.
   
   Treat it like you would a real project. Especially if you've improved an algorithm, make sure it appears in your commit comments.
   
   Hiring Managers probably won't sit there and dissect your code to make sure it's hyper-efficient - but they will look at it to get a sense of what you know/don't know.
   
   Be careful of over-engineering or writing over-complicated spaghetti code. In fact, try to reduce any code-smells.
   
   A great resource I like that helps you write super-presentable code isRefactoring and Design Patterns.
   

   
   

4. Should I include my GitHub on my resume?
   Yes. As a URL not as linked text. Resumes get printed - and, so far as I know, you can't click a link on paper.
   

   
   

5. Should I include my GitHub on my LinkedIn?
   Yes.
   

   
   

6. Do I need to worry about how active my GitHub is?
   No. This is unnecessary pressure that we coders put on ourselves. We want the coveted wall of green. While having multiple daily commits is great, it's not going to guarantee you a job. Worry less about having a high frequency of commits, and instead worry more about having impactful commits: projects that show your evolution and growth as a developer. That may just be a few a month.
   
   On the flipside, make sure you don't have tons and tons of abandoned/unfinished projects. Have complete ideas - they can all be at various stages of completion, but don't have more than 2 projects that aren't at an MVP stage. Finish what you start. Sacrifice novelty for nuance.

   
   

7. Should I include course projects?

   Coursework is only good in the absence of your own projects. Keep coursework visible until you have your own projects to stand on - then hide the assignments.

   
   

8. Should I include all my projects?
   Only include those that are full and complete ideas - they don't have to be full products. I like to distinguish between projects and products. A "Product" is building full Twitter/Facebook clone. The size and scope of products can be so large you may never really complete it - and it won't serve you much good because it'll overwhelm the hiring manager.
   
   "Projects" are more discrete units of work. A library. An experiment.
   
   You should definitely share projects and include in your writeup what they were about - and what you tried to achieve.
   
   Include "Products" provided they're far enough along that they can stand on their own. If you never got beyond the log-in screen, then don't include it.
   
   I'll re-iterate*(actually, I'm just copy & pasting)*: Make sure you don't have tons and tons of abandoned/unfinished projects. Have complete ideas - they can all be at various stages of completion, but don't have more than 2 projects that aren't at an MVP stage. Finish what you start. Sacrifice novelty for nuance.

   
   

It's worth noting, all these responses are my own subjective views that I've generalized across small and large companies. They reflect my personal style, but I'll also happily submit they're not 100% right either. It's what's worked for me - but I love getting input and thoughts from others.

Have any questions I haven't answered? Connect with me on LinkedIn and send them to me!

Also published here.