This will be at two-part series in which I discuss my take on how
to approach building a portfolio for new developers, and then suggest a project idea.
The discussion mostly concerns full-stack development. Portfolios differ drastically across the different specializations of software engineering, so for this discussion to be of any use, we focus on one sector.
TL;DR
Skip down to the Summary :)
Introduction
The importance of your portfolio varies from individual to another depending on several factors. However, it is accepted wisdom that if you plan to enter the software industry, you should have some number of projects built, even if only to showcase your knowledge.
For career switchers, this is absolutely a must. So, being one myself, I spent a considerable amount of time researching the topic and looking for ideas to build projects.
The Main Takeaway
If I can state one conclusion from all of the different blog posts and videos I went through on the topic, it would be this:
The idea itself doesn't really matter. The execution, and the motivation behind, it absolutely does.
By execution I obviously mean the implementation of the project. By motivation, I mean the reasons that made you believe this is a good project to showcase your ability as a full-stack candidate.
This is not to say that simply listing project ideas is a bad approach. What I am saying is that developers trying to build a portfolio should understand what makes up a good project, because there might be a good idea lurking around in their own environment—one which cannot be found in lists of common topics.
What to Consider in a Project
Now that we have established that the topic itself is not necessarily the property that gives the project its value, we should try to point out the ones that do.
There a few components that you should look to have in your project when selecting a topic.
1. A problem statement
You want your project to show that you have made some effort to find a real-world problem and tried to solve it.
Side note:
A todo list is not a good candidate because it lacks creativity. You haven't looked hard enough if all you have found is an idea for a simple todo list.
Be careful here, though. This isn't a PhD thesis. You probably won't be able to find an unsolved problem, so don't spend your days looking instead of coding. Your goal is not to find the perfect problem, but to find something you can justify the time spent solving.
2. Data persistence
Unless your goal is to showcase ninja CSS skills, static pages won't cut it. The same goes for simple calculators. Just don't showcase a calculator. Please.
Side note:
If you do want to showcase ninja CSS skills, then by all means create such a project. Just don't make it your only one.
A full-stack engineer deals with data, and your project should too. You need to show a project that efficiently deals with CRUD operations and not-so-trivial queries.
Now, for the database used for said persistence, perhaps relational databases are not a must—with the popularity of the MEAN & MERN stacks and all. But in my opinion, the better candidate is the one that can justify the tools of choice. If you are not going to use a relational database, have reasons to back your decision.
Regardless of the database system of choice, your database should be well designed, and your data manipulation should be efficient.
3. Decent scope
This more concerned with your implementation than the topic. The problem statement does not need to be huge, but your implementation should not be limited.
You should aim to mimic an actual product. Do not cut corners with features complementary to the core feature solving the problem.
A web app without authentication and authorization, for example, is usually incomplete. If your app processes large amount of data, you should consider having import/export features and not just displaying data on your UI.
4. Clean architecture
Again, a property concerned with your implementation.
You need to have properly applied good software engineering practices and good practices of the tech stack you chose.
Encapsulation and separation of concerns are the key factors here.
You do not want an architecture with global variables everywhere being affected from multiple places in your code. You also do not want your data-handling logic jumbled up with your data-rendering logic.
5. Some form of an API consumption
This may not be a must have, but I think it's worth considering.
If your backend is not an API itself, it may be a good idea to pick a project that requires communicating with a third party API in your project; if only for the sake of demonstrating your skills and familiarity with the concept of asynchronous data fetching and (de)serialization of objects.
Conclusion
In this article, I tried to articulate the key components that make up a good project based on my own research on the topic trying to build the resume that got me my first job. The five components listed may not be the only, or the most important, ones to look for in a full-stack app, but they are what I stood out to me.
These are also the components I included in my own project before applying to the company that offered me my first job as a junior full-stack developer.
In the next article, I will be suggesting an idea for a project that I have not come across often, and I will be detailing why I think it is a good choice when building your portfolio.
Till then, please use the comments section to share your thoughts on the matter.
Summary
When looking for projects to build, you need a project that:
Has a problem statement:
That is, the project solves a problem you can articulate to your audience.Requires data persistence:
If the topic does not require a backend with a well-designed database, it is not a good fit for a full-stack applicationA scope beyond the feature that solves the problem:
You need to show that you understand typical business requirements, and can develop a program with complementary features coherently implemented within the scope of your project.Clean architecture:
Your project should demonstrate your grasp of the principle of "Separation of Concerns". You must demonstrate that you can develop with maintainability in mind.Consumes some API:
A preferred feature that will show your comfort with dealing with APIs and asynchronous data fetching.
Top comments (0)