Portfolios for software engineers

Saturday, 7 September, 2013 — work engineering career

It’s entirely possible that you’re thrilled to bits with your current gig. You haven’t seen the need to update your résumé in months or years. So, I totally get it when I tell you to assemble a portfolio and you respond with, “I’m happy, I’m not going anywhere anytime soon.” Build a portfolio anyway.

In my last piece, I talked about avoiding career stagnation and working where your work is valued. Building and maintaining a portfolio is an insurance policy against stagnation and the “go bag” for your career.

Background

There’s plenty out there on programming interview questions and answers, so I’m bypassing that. Same with résumés and cover letters. I don’t see many candidates with a portfolio of past work, so that’s why I’m telling you to have one. You will automatically stand apart.

Recommending a candidate for interview or hire is a lot easier when I see how that candidate approaches problems. Onsite interviews covering design exercises and problem solving cover some of this. A take-home exercise might cover another. However, that’s still oftentimes a hint at direction than true comfort. The interview itself relies on candidates telling an interviewer a story (and make no mistake, I want to hear how you explain how you did something.) Still, four or five hours of conversation with a group of hiring managers or potential peers is barely enough time for them to reach a very solid opinion of you.

A portfolio brings an entire other dimension to bear. I get a feel how you write code completely outside the context of the interview process. I see how you think through solving a problem with design, how you model a domain. It’s a window into how you think.

What’s in your portfolio

There should be some manner of map to what’s in the portfolio. Let’s first stipulate this portfolio is online and publicly available. What I would like is a straight-ahead path to get there. Ideally, it’s a simple, direct URL. So, let’s also stipulate I’m looking at an index page that gives me a brief amount of information about you and pointers to more (a blog, Twitter, etc) and the main body of the portfolio itself. The number of items on the portfolio isn’t particularly important past there being more than one or two things there and not seeing absolutely everything you’ve ever created a repository for. Select for breadth or depth, but know what you’re deciding and why.

I would love to see a mix of complete projects, pull requests for other projects, bug reports and even some toy code. That’s strictly what I’d be most comfortable with. Vary as you like and believe you can articulate well. Choose what best demonstrates your goals and practices.

For complete projects, a README describing the project’s purpose, installation process, support and contribution practices are the first thing I’ll read. Before I read any code, I’ll try to install it. Then, I’ll probably dive into the code structure itself. Can I make sense of how the code is structured? Is it structured how I’d expect to see other code in the same language? From there, I’ll likely dive into individual files to get an understanding of classes, frameworks and so on in use. After that, I’m going to read your commit messages. How do you work with source control? I’m looking for commits that explain the why behind the what. I’m also going to take note of whether or not your project has documentation, how your code is commented or not and your code style. There’s no one right or wrong thing with these. I do like to see consistency, clarity and readability.

Pull requests are a little different. I presume there’s an originating issue I can look at to see how you interacted with the project in question, in either opening the issue or proposing a solution with the pull request. If the project initially turned down or requested changes in your pull request, how did you handle that?

Toy code is great to show how you might address a problem like FizzBuzz, practice code kata, try out different sorting algorithms or learn a new language, to name some possibilities. I get a sense of how you play to learn.

Now, here’s what I care less about, what language you write code in. Sure, I can map your experience to mine easier if I’m familiar with the language you work in and it’s one you’d be working with for the position you’re being considered for. At the same time, I care more about how I see you work on your project and how you organize it. I care more if I see experience in one language that I expect you can apply to a cousin.

Work vs. personal projects

Tricky, tricky. Generally speaking, what you write at your day job is work-for-hire and code you don’t own. Businesses are understandably touchy about having processes and methods around the core of a product out in the wild. Still, it’s nice to have something to share. So, get creative. Is there anything your shop has done that’s in support of your product, but isn’t actually your product? “Sell it” by open sourcing it. You’ll need your boss and fellow engineers to support making a case to open source a project or tool to the business. What is that case? Well, consider that lots of engineers are attracted to work at places that contribute back to the sorts of open source communities they build their products on. Engineers like you. There’s more to this than what I’ve covered. Do your research, be willing to support it vs. publishing abandonware. Still, it’s a way of liberating some code for a portfolio.

Short of open sourcing an entire tool, see if you can publish some samples. Ask. Be clear that you’re publishing when asking.

Failing that, isn’t there some itch you’ve been meaning to scratch with a project of your own? It doesn’t have to be a 25 model domain. Pick a small problem, solve it in a way you want to see solved and publish. Get feedback and iterate.

Parting thoughts

A portfolio is one piece of many that’ll be considered in a hiring decision. They’re put together and refined over months and years. New pieces are added and others removed as you learn and evolve over the course of a career. A portfolio separates you from other candidates. Again, not many people submit any code samples, let alone with any sort of considered structure. Your portfolio is a vehicle to tell a story about you and your career.

A good portfolio may not get you hired at any particular job. Instead, maintaining a portfolio is you always preparing for your next gig, even when you aren’t actively looking for it. That greatly increases the chances of landing a gig that’s worthy of you. Fortune favors the prepared.