Creating a great developer portfolio website to showcase your work is an excellent idea. It allows potential employers and clients to get a sense of your skill set and previous work in an easy-to-digest format.
I often see developer portfolios that list skills with some sort of visualization like the above, or perhaps in the form of a dial with a percentage. Ultimately this is a subjective design decision…. but personally… I wouldn’t use these sorts of visualizations.
The problem is that they often don’t convey enough information to make them useful. Often times all they are conveying is the developer’s subjective assessment of their own capabilities relative to one another. Nobody is really “100% skilled” at JavaScript or “full bar skilled” at Java. What’s often the case is the developer is signalling their relative confidence with each technology. Developers often suffer from imposter syndrome and may even be selling themselves short!
My suggestion is to focus more on portfolio projects than anything else, listing the skills utilized in each project beneath the project.
But if you are going to use a visualization, my suggestion is to try to ground it in something less subjective, like perhaps years of experience or projects completed. So that way each bar or dial’s “progress level” represents relative years of experience or number of projects completed. This way the information conveyed is less subjective and less tied to your own self-assessment, and grounded in something more tangible.
One of the more intimidating things with building a portfolio of work is just finding the time!
Practising small coding questions on websites like codingbat.com can be an excellent way to learn.
But the larger projects that will become the centrepiece of your portfolio can’t be completed in an hour, or often even in an afternoon.
In order to tackle larger projects more successfully I strongly suggest the following:
#1 Pick a project that means something to you. If you make the 100th generic restaurant website… that’s perfectly good. But does that really motivate you? Pick something that you’re excited to work on, whether it’s something for a charity or maybe a personal hobby. It will keep you engaged and interested.
#2 Break down the project into small pieces. As small as you are able to!
#3 Assign an order to completing each piece. What pieces do you need to work on first?
#4 Set aside scheduled time to work on the project. It could just be an hour a day, or it could be an afternoon a week.
#5 Track your progress. Track your progress by checking off each piece you complete.
#6 Find support.Let others who will encourage you know about your progress. Find a group of peers online and/or offline in a similar situation and support one another. By letting others know about your project you are creating a form of accountability.
#7 Don’t give up. Every single person who ever completed a large project felt lost or confused at some point, or felt like giving up. Just keep at it, you will finish it!
And finally… when you’re all done, don’t forget to reward yourself somehow!
In a recent paper published in Nature researchers used an experiment to find evidence that language skills are a stronger predictor of new programmer learning outcomes than math skills.
Some people are suggesting that this means that learning a programming language actually has more in common with learning a natural language than traditionally believed. Traditionally the ability to learn a programming language was thought to be highly associated with math skills… often colleges will even have advanced math courses such as Calculus as a prerequisite. The results of this study are an excellent new challenge to this belief.
As a long-time computer science educator, my own belief is that students generally only need “enough” math skills to learn standard application programming. The basic mathematical operations and some algebra (use of symbols) seem to be what is important. But beyond this, stronger and stronger math skills have diminishing returns, as introductory-level programming simply does not require these skills.
The interesting part to me is the correlation with language learning. As part of my PhD I completed studies on the gamification of early computer science and adult literacy education, so this subject is near and dear to my heart.
My opinion is that language skills are not a predictor of success in learning introductory programming because learning a programming language is like learning a new natural language (e.g. French). In my opinion much of the “returns” in improved learning achieved due to language skills may be due to the ability to precisely understand instructions and educational material.
Learning to program involves consuming and interpreting written information, and precisely following instructions that are given (e.g. “write a program to print the prime numbers up to 50”). When the compiler presents the learner with an error, the learner needs to comprehend the error, and critically, understand what they might not understand. In other words, recognize what about the error message it is that they do not understand. These are hard, underappreciated skills, often involving metacognition (thinking about our own thinking).
That said, I strongly suspect there is more to it than this, underlying strong language skills are a host of abilities that transfer across subject areas, and it should not be surprising they transfer to learning programming as well.
One of the things I’ve seen new programmers struggle with the most is the error messages they get when attempting to write their first programs. They’ll pay attention to the lessons they’re being taught, do their best to understand the concepts like variables and loops, and then attempt to solve their first problem.
And then the compiler (or maybe the browser) essentially tells them they did it wrong. Often the most diligent students will take this as a personal affront… it’s not just that the compiler is telling them their program is wrong, it’s that the compiler is telling them they’re stupid (this isn’t reality, but this is how it feels).
I think this stems from a lot of the “textbook learning” that students typically encounter. In a textbook students are given an overview of concepts with some example solutions to problems, and then are asked to solve exercises (with answers provided at the back of the book). When students fail to solve a problem, they see it as a lack of understanding that needs to be corrected.
This model of learning does not directly translate to programming. On the one hand, yes, when you get a compiler error it may be a sign that you don’t understand something and there is an opportunity to correct that misunderstanding. On the other hand, experienced expert programmers spend much of their working day correcting compiler errors, because making mistakes (big and small, fundamental or trivial) is part and parcel to programming!
Programming involves the solving of novel problems on a consistent basis, with solutions expressed in a very precise and unforgiving syntax. It’s not like learning Physics 101 where once you understand the equation and how to plug in the numbers you can solve identical problems and over and over without error.
This is why I’m a big advocate of the “live coding” model of teaching programming, where the instructor writes programs in front of the students, including making mistakes and correct them. It is essential that students see this for two reasons:
Making mistakes is normalized for students. If the instructor makes mistakes and is OK with it, then it must be OK for them too.
Students learn from the problem solving process followed by the instructor. When the instructor interprets the error message and applies strategies to solve the problem (e.g. examine the line of code flagged by the compiler, use Google/Stackoverflow), this teaches students how to problem solve using these strategies as well.
I try to leave “mistakes” in my videos for Portfolio Courses for similar reasons… to help learners via adopting new strategies to solve programming errors!
When I was looking for my “first real job” I had several great opportunities and didn’t know which to take. I had the choice of a more prestigious position (software developer at IBM) or a position that offered more room for growth and learning at a smaller company (NCR).
At the smaller company I was promised the opportunity to participate in all aspects of software development… design, implementation, testing, QA, etc. I was also promised more responsibility and opportunities for leadership. IBM is an excellent company to work for, I later ended up working with them as part of a research grant. But at least in this case, it was clear where the opportunity for growth was, but I was still drawn to IBM given the name recognition… I mean, it’s IBM.
I was pretty stuck on what job to take and so I asked a mentor what would be best, and they told me something I’ll never forget, “When you’re early in your career, go where you’ll grow“. I took the advice and went for the job that would let me grow more. I was able to experience a much larger range of work with more responsibility than I would have at the other position.
In particular I was assigned applied research projects and tasked with teaching the incoming developers how to work on our projects. I found myself way more excited to complete this type of work than any other, and I was able to get some practical experience with both through this job. This influenced my future career direction, and I don’t know where I would’ve ended up if not for this experience.
If you’re earlier in your career, I suggest you follow my mentor’s advice too. Go where you’ll grow. Go where you’ll be given a range of experiences, responsibility, and opportunities to learn. There will always be time for more prestigious and higher paying opportunities later, but those first few years of your career are the best time to put growth first as the experience will pay large dividends for the rest of your career.
I’ve been teaching post-secondary computer science and software development courses for almost 20 years now. Maybe about 10-12 years ago I started having employers regularly tell me things like, “what really sets apart a candidate is if they have a GitHub account with all their projects”. There was an interesting thread on Twitter about this recently: https://twitter.com/jasonalba/status/1405626754098548740.
And in many ways, it makes sense from the employer’s perspective to use this as a differentiator between candidates. If an employer is attempting to hire a co-op student from a college program, and they have 20 students applying, all having taken the same courses, the student with a portfolio of work has done something extra to demonstrate their skills to employers. A portfolio tends to demonstrate those skills in a way that is different than class assignments, in many portfolio projects concepts are applied to solve “real” problems. The presence of a portfolio also communicates things like drive, initiative, independence and soft skill abilities (e.g. ability to market oneself), all things that are attractive to employers.
A portfolio of work can also help job candidates without a traditional academic background (e.g. a software development diploma or computer science degree). Having access to these traditional academic pathways to a job in the tech sector can be seen as a form of privilege, in that not everyone can afford the tuition or time commitment that these pathways require. So in this sense, a portfolio can actually help those without this type of privilege to access better work opportunities.
But eventually many employers started treating a portfolio of work as a requirement for the job rather than one of many possible differentiators between candidates. While personally I’m a big believer in portfolios as a great way for developers to showcase their skills (just look at the name and purpose of this website), I’d really have to caution employers against requiring a portfolio of work.
The big problem is that a portfolio of work takes time to develop and publish. Not everyone has the ability to spend their time outside of work creating portfolio projects. People have family and other life commitments and constraints. Even for those with time, is it really fair and reasonable to ask them to sacrifice this leisure and personal time? And often the paid work that students, learners and professional developers do cannot be made publicly available as part of a portfolio (e.g. it is sold as commercial software).
So if employers are requiringa portfolio of their applicants, they’ll be missing out on excellent candidates who are unable to demonstrate their skills with a portfolio. Missing out on excellent candidates should be enough to spark a re-think. But just as important, it also raises issues of fairness and inclusion, as having time available to build a portfolio is a form of privilege that not everyone can access. For a tech sector that is seeking to improve inclusion, this should also raise an alarm.
While it’s ultimately up to employers to figure out their own processes, I’d strongly suggest that employers do not require portfolio work for this reason. While accepting portfolio work as a means of demonstrating skills is an excellent idea, for example allowing candidates without formal education to showcase their skills, making it a requirement is to the detriment of both the employer and applicants. And arguably the industry itself.
Ideally employers will have application and interview processes that take into account multiple ways to demonstrate proficiency and aptitude for the job. In practice employers may themselves be stretched for time. This is where perhaps new processes and tools/technologies need to be created to assist employers with making better hiring policies.
One of the better developers I know was unable to complete many interviews because they required her to do “homework” solving practice problems. She worked full-time and had to take care of a sick family member during her “off” time. She ended up getting a great job at a web company that used a hands-on technical interview. During the interview she was asked to solve a small technical problem (30 minutes), and the interviewer was just there to see the process she followed. She asked questions. She used Google. Things good developers do every day. She got the job, and she’s now a star at the company.
I don’t think there is an easy answer, but I’d love to hear more stories like this one.
What about Portfolio Courses?
For my part… this entire business is centred on helping students to develop portfolios. I really do feel they are an excellent way to demonstrate a skill set to employers, and that in particular for students and others trying to break into the industry they can make a huge difference. But a big goal of mine with this business is to lower the technical skills and time commitment bar to develop portfolio projects.
I’m hoping that by giving students a hand-holding experience through developing portfolio projects, they’ll be able to develop more projects faster than they would have otherwise. Or maybe even help students to develop projects who before would have developed none at all due to the bar being too high. But I’m going to be doing my best to keep in mind time commitments, with a goal of offering a range of courses able to accommodate different possible time commitments.
Often times we focus on developing our technical skillset, learning the latest framework or technology because it’s on all the job listings. And while this is important as a minimum qualifier for the job, often what differentiatesus from other candidates is our soft skills. In other words, technical skills might get your resume on the short list, but soft skills will get you the job.
Research and surveys of employers over many years has shown this to be the case. For example this paper on Industry Expectations of Soft Skills in IT Graduates out of New Zealand which surveyed IT employers on the importance of soft skills:
“Soft skills contribute significantly to individual learning, team performance, client relations and awareness of the business context. Most employers consider these soft skills to be un-trainable in the work-place, making soft skills the critical hurdle for employment. “
…followed by…
“Technical skills are a prerequisite but the point of difference is soft skills — which are hard to train”
Schools and workplaces often don’t do a great job of developing soft skills. A manger once told a colleague of mine that she was a perfect fit for the job because she had “the things you can’t teach”. Is it really true soft skills can’t be taught and learned? Are people just born to be great communicators, team players and organizers?
As an educator, in my experience soft skills can’t always be taught in the same way that technical skills can be taught, with demonstrations, assignments and testing. You might be able to teach a student how to write a good, effective sentence. But it’s hard to teach a student whether sending a bunch of questions over e-mail to their boss is a good idea or not! Maybe they’ll annoy their boss, maybe the boss will be happy to see the enthusiasm… it probably depends on the situation and questions.
These types of social soft skills are often best taught with experiential learning where we conduct some real-world activity that forces us to grow and learn in ways that can’t be captured by “book learning”. When we work on a project as a team, or try to write a tutorial or make a podcast, we go through a series of decisions around communication and collaboration with others that can’t be captured by “book learning” alone.
So when you think about developing your professional portfolio, I strongly recommend keeping an eye towards experiences that will develop your soft skills too! It’s not just about having a GitHub account with projects, it’s also about your time spent organizing clubs, helping others as a tutor, writing articles, and other soft skill oriented experiences.
Because soft skills are so important, we’ll actually be creating courses to teach you how to build your soft skills and showcase them to potential employers! Our first soft skills course, How To Organize Awesome Meetup Events, has now been published on Udemy: https://www.udemy.com/course/how-to-organize-awesome-meetup-events/?referralCode=D98C0AD909E83C38D696. Organizing meetup events where others get together based on a common topic to learn, have fun and network is an excellent way to build and demonstrate your soft skills!
The age old chicken-and-egg problem of first-time job seekers is that every employer wants to hire someone with experience… but how can you ever get your first work experience if every job opening requires experience? This is where it may be tempting to work for free in some capacity to get that initial experience. But should you work for free? Working for free can be exploitative, it can devalue what you’re really worth, and it sets a bad precedent that employers can expect free work.
In my experience, and from watching the experience of many others… working for free, under some very limited and specific circumstances, can actually have a tremendous benefit to your career by allowing you to learn, to grow, to build confidence, and to demonstrate your experience. Under other circumstances though, like unpaid internships at companies that can well afford to pay you and aren’t teaching you anything valuable, in my opinion you’re very likely being exploited, and it’s just not worth it.
So when to work for free and when to take a pass? Here’s when I suggest working for free may be worth it…
Projects for charities, nonprofit and volunteer organizations
Charities, nonprofits and volunteer organizations that exist due to donations, government grants and volunteer time, may legitimately not have the budget to pay for things that they would like to have done, whether it’s a website, graphic design or social media. People will do things like volunteer at the library every week to teach people how to read, or serve soup to the homeless from a kitchen, in order to help these organizations fulfill their mission. Making a WordPress website or a logo, or performing some other service, can be the digital equivalent of serving soup to the homeless or a lawyer doing “pro bono” work for clients that can’t afford their services.
Mind your hours of course… you can only do so much pro bono work, but whether you’re looking for first time experience or just want to help out, volunteering your services to a charity, nonprofit or volunteer organization can help your community while giving you real-world experience.
Open source contributions
Open source projects involve source code, design documents or content that is freely available to the public, and that generally speaking the public are free to contribute to as well. In software development this means software developers coming together to build everything from operating systems to video games. A common misconception is that open source is something specific to software development, and that only software developers can contribute to open source projects. Even for software projects, contributions ranging from event planning to writing documentation are also required, but there are a range of other industries that use open source.
Contributing to open source projects allows you to help build things that benefit everyone. Not everyone can afford expensive proprietary software that costs thousands of dollars per year, but free solutions can do the job good enough (or better). Making open source contributions allows you to work on real-world projects and get feedback on your contributions from the project leaders. Check out this guide on How to Contribute to Open Source to help get you started!
Hobby projects for yourself
Projects that you work on for yourself can have enough intrinsic value to make them worthwhile. One of my friends setup a Raspberry Pi and sensors to monitor his home wine-making operation, so that he could track and analyze things like temperature over time. It might not be worth it if you measure the worth of your hours in dollars, but if it’s a labour of love than it’s a different story. Hobby projects that you work on out of sheer passion can make for the best experience, because your passion for the work will motivate you and will show up when you talk about the project with others (like potential employers).
A business you own shares in
This one you need to be a little careful with… there’s a never ending list of people that will offer you “sweat equity” in their startup business. It’s difficult for a business to get customers or investment for vapourware, and so often startup businesses will rely on giving equity (i.e. shares in the company) to developers and other early team members in order to build a prototype or minimum viable product.
You’ll need to make a judgement call with this one based on the viability of the business, your interest in the business, and the equity that you would take away. I would also strongly advise getting a lawyer to look over any paperwork you sign regarding equity in the company.
Even if it’s something you’re building for your own business idea, you still need to be mindful of the time you’re investing into something that may not have a payoff. All that said, working on and building something for a new business can be a great way to gain experience… businesses have customers with requirements, and who can provide feedback, which can help you to learn and grow.
What about situations to avoid? Or at the very least, exercise extreme caution?
Unpaid internships
Unpaid internships devalue your work, help set a precedent that companies can expect free labour from new graduates, and unlike side projects done on evenings and weekends, occupy too much of the intern’s time. In some cases, and I’ll admit that not all will agree with me here… unpaid internships might be worth it… for example when the intern is receiving a high-level of very valuable training, or when the intern receives academic credit, or when a job offer is guaranteed after a period of unpaid training. Sadly unpaid internships are common in many industries, and often they aren’t providing the sort of high-value training that is really supposed to justify the unpaid nature of the internship. Be very, very careful with unpaid internships.
Spec work
Spec work is when companies ask you to perform some task for free to see your work, and then they may or may not hire or pay you later. Often times this will come in the form of a contest… a $100 prize to design a website layout for example, that leaves you competing with potentially hundreds of other people for the prize. Some recruitment platforms are even building this type of spec work into their system… they’ll have hundreds of students complete work to demonstrate their skills to an employer, who is then able to pick the top student(s) for the job. Unless you’re OK with doing it “just for fun”, I would advise staying clear of spec work… if you’re doing work that isn’t a hobby passion project (where you are your own customer), one of the key things you want out of the process is customer or user feedback, and/or mentorship, which spec work doesn’t provide.
