How important are portfolios to developers
This week I attended the Junior Dev meetup. I like going to events like this occasionally to get a sense of what's happening in the industry and the various things that are impacting juniors. There were some good talks and discussions afterwards. I enjoyed the talk by Zubin about the importance building a profile and portfolio work for people in the industry. Someone in the audience asked "After you have been in the industry longer how important is portfolio work?", I think this is an especially good question. I discussed this with a few people at the event and I think the discussion is worth sharing.
Getting a direct assessment of someone's skills is time consuming and is sometimes difficult even if you have the time. For people such as hiring managers who have not got a lot of time the temptation to try to find shortcuts to assessing knowledge is often irresistible. These shortcuts to making a more detailed assessment are knowing as signalling and is, unfortunately, different from the process of building the skills being signaled.
I spend a lot of time writing content for someone who has the sort of workload I have, it's a hobby I guess (it's also an important way for me to solidify thoughts and consolidate my knowledge in certain areas too), but lately I've been super busy and the last post I made on here was that post about loreum ipsum generators and that was on the 4th of August 2019. Honestly I had another post in mind and definitely didn't want that to be on the front page for longer than a day, but alas I was busy running Python workshops with Python Charmers and then had a bunch of commitments doing client work through my software consulting company. Specifically I had to do an intense period of learning more about some of the networking protocols and standards so I could do better network automation with Python for some clients and also I had to deal with a bunch of work with timezones (yes timezones are hell). This didn't leave me with any time at all to dedicate to any sort of portfolio work or profile building. For senior staff however I don't think this lack of time, and energy, is at all uncommon. A lot of people who are senior technical staff either on an engineering track or management track will simply not have the time to do these things, and they will understand many people in the industry won't have the time either. But more about that scenario in a moment.
I don't think there's a one size fits all answer for everyone here.
How much a portfolio matters and what is most effective will change over someone's career.
Here's a few scenarios:
Completely new to the industry
Any reasonable employer will not expect juniors/interns to have all the answers, so what are they looking for?
If you are new to the industry you will want to appreciate that there's a very substantial amount of risk that an employer will have to take on in hiring a junior. They want someone who's able to learn fast and has basic proficiency. This is why there's tests like FizzBuzz, some people honestly can't do it and hence it's a filter that's quite a strong one.
The main driver around junior or unproven tech staff is fear that they will not be able to be productive or learn fast enough to be productive.
If you can prove some proficiency with the technologies involved this is a very strong signal that you will be able to be productive enough for someone to invest the time and money into hiring and upskilling you. With juniors and other people without a proven track record most of the discussions around hiring involve discussions about risk.
A well placed portfolio piece will help me as a hiring manager have more confidence in your abilities. If you can show that you understand a technology that's a major component of the product that's a huge amount of risk that goes away from the perspective of the hiring side. The other thing this does is provides an efficient way to reduce the informational asymmetry going on, a portfolio project allows the hiring manager to open up a highly efficient discussion about your skills and this allows a much more accurate assessment of your skills to be made. In many organizations this increased accuracy is very beneficial for someone looking to be hired since from the perspective of the hiring side the lower risk of your skills being subpar when you get on the job.
As Zubin mentioned in his talk, no matter what people will say the reality is that HR people are often extremely risk averse in many organizations. As a hiring manager if I can say with high confidence that I think the person applying is skilled and there's a low risk of them turning out to be unsuitable when they are hired this carries a substantial amount of weight. Be good at what you do then make it easy for other people to discover your skills.
Part of the transition from junior to more intermediate is one of the nature of oversight needed for being productive. There's a bunch of productivity work skills and on-the-job experience intermediate staff have that juniors don't have. Specifically intermediate developers I expect to be able to solve many routine problems on their own without needing a lot of oversight.
Relevant portfolio work is that work that shows you are capable of solving some more advanced problems and are able to see some of the edge cases and difficulties that can arise. Also relevant is anything that shows you have some of those relevant on-the-job skills like a good understanding of version control or anything that shows understanding of the practical application of development skills in messy real life situations.
Once people have the ability to be productive with code then other skills such as other industry verticals starts becoming more valuable. For example if I'm working in say digital delivery if two people with roughly the same intermediate development skills apply but one has experience in the associated areas of the product being delivered then this will be a very strongly positive thing to see.
With senior staff there's definitely a few dimensions at play, including:
- Management track
- Technical track
And considerations such as what the nature of the visibility of the work is:
- Publicly visible contributions
- Internal contributions
By the time that people are talking about senior positions portfolio pieces get less important relatively speaking for hiring for roles that are not public roles.
Across all these dimensions there's a definite factor of senior staff having an impact that goes beyond their own individual contributions. In the management track its fairly obvious, you bring your skills to positively influence a team, that can take a few different forms. In the technical tack it's not as obvious, Andy Grove in his book High Output Management has a good description of how senior technical staff are effectively "managers" in some sense since people will come to those technical experts for coaching, guidance and advice, the sorts of things that are very traditionally management jobs.
There's definitely a group of roles that have a sizeable marketing component, there's obvious ones with job titles like "Developer advocate" but there's less obvious ones where a large amount of value is in the ability to show other prospective hires/clients that you have high profile engineers on staff. For those roles having a public profile is beneficial. Some of the workshop work I do benefits from public visibility, being active in some open source Python projects is important for building the credibility that I'm needing to have to be a trainer in the high end workshop and training space.
There are however a lot of senior roles (maybe the majority of them?) that aren't so leveraged to the publicity side. Beneficial signals for these roles include previous projects, the ability to communicate effectively with multiple stakeholders from both inside engineering and outside. Selecting only on public contributions might be a very sizeable mistake in this area of the market, highly skilled people just aren't that easy to come by.
When you start getting to the very senior technical track roles you will obviously want to show a very deep level of technical understanding of a certain area. Generally speaking at this level it's not a matter of time, these people solve problems that any number of junior/intermediate people cannot solve at all. When you can't substitute a larger number of less experienced staff then you know you are in the territory where senior technical track people start to really bring a game changing benefit.
There's 2 people in my career who I have learned substantial amounts in a technical capacity from working with, these people are really what you would consider technical subject matter experts in a deep sense. Neither of them have a substantial open source or public facing portfolio. Specifically their work forms a core part of some very important systems which are well engineered/performant/profitable etc and hence are substantial trade secrets at times. I don't personally think that's an issue for either of them since they have mostly been in the internal software space and they aren't aspiring to do things like the conference circuit.
If I was trying to hire someone like this it would be tricky in some senses because in their areas of expertise their technical skills will likely exceed my own and the products produced might not be accessible to me to view, so being able to judge those technical skills isn't easy.
Looking for people who are more publicly oriented has another dimension that really comes down to marketing. Put simply having good technical staff at your company is a draw card since it adds a lot of value to the careers of those at your company who area able to learn from them. In this way having well known senior staff can make recruiting easier, and honestly recruiting for tech is hard as it is, so any help like this can make a difference. Portfolio work at this level tends to be well known open source libraries, conference talks, research papers and other things that show a deep understanding of the domain.
There's a variety of specific highly technical niche areas, many other people have wrote about what's involved in getting into those roles and I'd suggest reading those articles to get a sense of how people got into those areas. For example this post about SRE is a good one, there's likely others in your area of interest.
As time goes on I find that the technical management type of roles are the ones I end up doing, while I do like technical contributions I find that feeling of making an entire team more productive very satisfying. Andy Grove has a really good definition of the output of a manager from High Output Management:
manager's output = output of his organization + output of neighboring organizations which benefit from his know-how
Effective technical managers are definitely hard to find because their skills exist at the intersection of at least a couple of distinct skill sets. In the case of engineering projects the managers organization is often an engineering department/group and "the neighboring organizations" tend to be other business units. Being able to maximize the value provided to both requires skills in both those areas. The reason I emphasise the technical part here is because there are management roles that someone who is a manager without technical skills won't be able to be as effective in.
A situation where someone can provide a lot of value as a technical manager is in the situations where a substantial engineering component in a project exists and having a clear understanding across both the business and technical side of a project is needed. In these cases having someone who is able to understand the context within which the work is done and can help the business team understand the engineering requirements as they apply to the business. They can communicate to the engineering team what the business requirements are in the language that the engineering team can act upon which can increase the value being provided for the same amount of engineering effort substantially. Proficiency with the technologies involved is important and various other skills like stakeholder management and project management tend to be highly valuable in such a role.
For these sorts of roles good communications skills are absolutely crucial. People who can keep the development team moving forward without getting distracted are incredibly useful to have around, but this is the sort of thing that isn't easily captured in a portfolio piece. Outside of showing experience in the relevant vertical skills in the industry I'm not sure that there's really any sort of portfolio work that easily fits for these types of positions. A track record of being able to do these sorts of work and a demonstrated ability to be able to communicate along with other managerial skills seems to be important.
Transitioning between roles
At the more senior levels people will sometimes transition between roles, for example going into more people management roles or going back to technical roles.
There's a variety of reasons that people switch from technical roles to management roles. Also there's also a variety of reasons that people switch from management roles to technical roles.
Making this transition will more likely be something that you have to communicate clearly about, I doubt portfolio work really comes into this one much.