Last year, Josh Como, author of developer tutorials and tutorials, volunteered on his Twitter account to view and criticize everyone's portfolio sites. During the event, he noticed an interesting thing: the feedback was not very diverse, the shortcomings in the design of the portfolio for most of the beginning programmers turned out to be about the same. Then Como had the idea that it would be nice to collect frequently repeated comments into one list. As a result, he got quite extensive material, which was formatted into an electronic book - it is available on the author's website for free. Under the cut you will find the main theses, recommendations and sources that are given in it.
General issues
What is meant by a developer portfolio?
In most cases, we are talking about a site where personal projects are presented, by which one can judge his experience and skills.
It is necessary?
Not. Not all developers include a portfolio in their resume, and not all employers expect such information. Moreover, there are those who will not even open the link. The portfolio is optional, but it can give a good advantage over the competition and show what you can do as clearly as possible.
Aren't there other ways to showcase your work?
There is. Nowadays, resumes often include, for example, links to LinkedIn or Github - resources that can also be used to highlight your activities. The advantage of a portfolio site is that it allows you to tell about yourself in a way that is convenient and beneficial for you. There is no need to follow a predetermined format, you can give as much context to each project as you see fit.
Who are these tips for?
For junior developers who, on the one hand, already have something to show, and on the other, want to compensate for the lack of work experience in the eyes of the employer and stand out from the crowd. The author focuses primarily on the front-end and full-stack, but most of the recommendations will also be useful for those who are engaged in backend or mobile development.
How many projects should the site have?
The optimal amount is from two to five. The “the more the better” approach does not work here - the portfolio is designed to showcase the best examples of work, and not to cover the entire chronology. If you really want to show more, at least rank them - let the best ones hang on the main page, and the rest are opened by clicking on the "Show more" cat or the archive tab.
If there is only one project, but its scale and quality are decent, it is permissible to add the quantity at the expense of something less impressive: to make a simple product purely for the portfolio or a small variation on the main theme (for example, an extension based on a mobile application), indicate the current project with with the mark "In progress", tell about some activity that is not directly related to the code (documentation, organizing events for developers).
What projects cannot be included?
There are several categories of projects that should be used with great care:
- , – , . , , , . . , ( 50% ) .
- . – . , .
- -. – . , - . , , , .
- , . « ». , . , , . , , .
Which projects should you include first?
In addition to the obvious (good and interesting), there are several characteristics that employers tend to value especially highly:
- Target projects that were created to solve a specific particular problem. They show that you know how to translate technical skills into practice and allow you to evaluate your approach to all aspects of the project, from start to finish.
- Live projects that have real users, even a little, tend to generate more interest than demo versions of products that were made for the sake of the process itself.
- Large-scale, complex projects that took a lot of time and effort. Not every junior, in principle, is able to bring something like this to the end, so the very fact of existence will speak in your favor.
- . , , , . , , , .
In general, you can add a variety of products of your activity to your portfolio: educational projects, trophies from hackathons, small programs that you wrote for your own needs. Juniors are often worried that their projects are not special, they are not overwhelmed by the complexity and will be miserable to look at in the portfolio. Don't raise the bar too high. If you have something to tell about the project (how you fought over the implementation of the function, how you chose one solution, and then abandoned it in favor of another), most likely, it has enough hidden complexity and it adequately reflects your current level.
Site structure and content
Portfolio sites usually don't have a very extensive structure. In fact, it boils down to a set of the following semantic blocks: section "About me", a list / grid of projects, with detailed descriptions for each, contacts. Below we will look at each of them separately.
About me The
audience of portfolio sites consists of two groups: hiring specialists and developers. At different stages of employment, your site is likely to be viewed by both. Accordingly, you need to maneuver so as to impress both groups at once.
The section "About Me" is intended mostly for personnel officers. Its main task is to make your "personal business" at least a little memorable against the background of others. In the author's opinion, the main scourge of portfolio sites now is complete impersonality, the desire to fit into a corporate style that uses the same structural backbone (graduated from such and such a university, worked or work there, I own such and such technologies) and recruitment speech cliches.
If you undertake to write a detailed text for this block, try to add something original to it - even as you came into development, at least what kind of philosophy of life and programming you have. The lowest bar for assessing originality is the following: if you see your text on someone else's site, will you immediately recognize plagiarism, or will you think at the first moment that someone just told about himself in the same terms?
Developers rarely show interest in this section, so it's best for them to bring the list of languages and technologies you work with somewhere prominent.
There is one other point to keep in mind when choosing your tone for your story: HR and developers look at your soft junior skills through different lenses. Personnel officers are more likely to appreciate the enthusiasm and dedication to their work. For developers, first of all, adequate self-esteem is important - they still have to teach you. Therefore, when describing your love for the code, try not to fall into excessive aplomb. If you picture yourself as an established specialist and development ace, HR may be imbued with your confidence, but future mentors are likely to think that it will be difficult to work with you.
Projects and their descriptions
The story about the projects is the central semantic block in the structure of the site. Usually, the main page contains a grid or a list of projects with a brief presentation of each: title, screenshot, a couple of description lines, technological stack, link to the demo version.
Each such card must necessarily translate to a page with a detailed description. If the information is limited to the listed items, the meaning of the portfolio site, in fact, is lost.
Expecting a product to speak for itself is a serious mistake many developers make. “Selling” your work is considered inappropriate, so the matter is limited to linking to the demo version and, in an ideal scenario, the code base - the employer is given the opportunity to form an opinion.
There are two critical drawbacks to this approach. Firstly, without your supervision, the interaction of the site visitor with the product becomes unpredictable. It will be very difficult for you to guess in advance how the user journey will go and at what point it will interrupt, especially if you have never done UX design. The person may simply not get to the very things that you are most proud of and on which you bet.
The same is the case with the code. It's no secret that in terms of quality, codebases are usually heterogeneous: some parts are smartly and gracefully made, some are held on to electrical tape. By chance, the beholder may well be struck by the second, and not the first.
The second drawback is that this approach, in principle, does not work well for the end goal. The portfolio serves to tell about you as a specialist. A standalone product does not give much information about who made it, especially when you consider that acquaintance with the demo version or the code in nine cases out of ten will be very cursory. At the beginning of the article, we talked about the fact that a personal site, unlike other platforms, makes it possible to bring more context. It is about looking at the project from the inside, about how the design and development took place. It is this information that is useful for the employer and best illuminates your professional qualities.
Como provides a blueprint to build on when writing about a project. You don't have to cover all the points, focus on the ones that really have something to say about.
Introduction
- General overview, essence of the project
- List of main functions and distinguishing features
- Your role in the project: did you work alone or in a group, what kind of things did you implement?
- Technologies used
- Link to demo and codebase (if possible)
Purposes and reasons
- Why did you undertake this project, what is its significance for you personally?
- What was expected at the start, what was the product like at the design stage?
- Any other comments regarding the planning stage.
Key points
- ? – , , .
- , .
- , , . , , , .
- ? - , , - .
- , , ? ? ?
- Has the experience gained influenced your future work? If you can link the two projects, showing how the knowledge gained in one has come in handy in the other, it will be just fine.
Current status is optional section. It makes sense to include it if the product is actually used by someone; then you can mention what kind of audience he has and what people are saying. If the project was made specifically for the portfolio, you shouldn't dwell on it.
Most likely, there will be a lot of text - a description of one project can take two or three pages. To increase the chances of the reader reaching the end, adapt it to read diagonally: short paragraphs, headings, lists.
Contacts
As a rule, this block contains a feedback form. If it is more convenient for you to communicate by e-mail, you can limit yourself to the direct mailto link. Links to pages in social networks and a professional blog, if you run one, are also taken out here. Now there is a tendency to embed a blog directly into a portfolio site, but the author is skeptical about this idea. The portfolio is designed primarily for communication with the employer - the likelihood that he will find time to read posts is extremely small. In addition, you will have to especially closely monitor the frequency of updates and the quality of the content.
Technical implementation
Design
Bad things first: design has a lot of weight. Content is content, but the features of visual perception work without interruption, therefore, the more beautiful ( not even more convenient, it is more beautiful ) the site, the more professional you will look in the eyes of visitors.
Not all developers are strong in design or can afford custom design, so the use of ready-made templates seems to be the optimal resource-intensive option for the result. The best thing is to select a few and mix them together to make the interface look more or less fresh.
Como notes that in the course of his massive portfolio browsing, he repeatedly came across the same popular design, simply copied pixel for pixel:
This is definitely not necessary. Even if the design is in the public domain, it leaves an unpleasant feeling of secondary and raises questions about the legality of borrowing.
Here are a number of templates that you can rely on when creating a design:
Portfolio Starter
Craig Portfolio
Alex Portfolio
Dexter Portfolio
Novo
Kester
Art Director
Website development
If you are applying for a front-end or full-stack developer position, you need to create a website on your own, without nocode solutions - the position obliges ... You can use any tools, best of all those with which you are familiar, so as not to waste extra time. Options to consider: vanilla HTML / CSS / JS, 11ty, Gatsby , Next , Jekyll . On my own behalf, the author recommends Gatsby, not least for the fact that many themes and plugins have been made for it, which greatly save effort.
Interactive elements, small animations and other visual bonuses that make browsing liven up look very advantageous on sites. Don't be afraid to add something funny or unexpected from yourself.
Domain Name
Ideally, it should be something like firstnamelastnamelatinice.com. If necessary (for example, if the name is already taken), you can insert a code or dev element. Nicky is not advisable to use unless you are a prominent person in the online community.
Top-level domains can be chosen according to your taste (co, io, specific domains of different countries). The only point: you should avoid .info, which many associate with spam and scammers.
Hosting
Portfolio sites are usually static, so they do not create problems with the servers. There are a number of services for hosting static sites, among which Como highlights Vercel , Netlify , Github Pages , Surge .
*
In addition to theory for clarity, Como gives two examples of portfolios with detailed analysis. The first is the Charlie Smith site, a fictional person that the author made himself, focusing on a typical, average sample from the Web. The second is the site of Julia Johnson , an IBM student and intern, which made the most pleasant impression on him against the background of others sent by subscribers. By comparing one to the other, it's easy to see how they compare with the recommendations.
Charlie's site - an inexpressive design without twists, a stereotyped story about yourself, a short and superficial description of projects
Julia's site - a more effective design, a successful structure, a restrained but not faceless story about yourself, many elements that animate the page, detailed descriptions for each project