Search for a command to run...
How I used my experience in tech to build a strong portfolio
I am a developer currently living in Greenville, SC, USA. When I'm not coding, or writing about coding, I enjoy playing tennis and chess competitively.
This is so true. I recall when I started taking on clients I used to just want to jump into writing code without gathering enough info from the clients and without enough research on user experience and so I used to find myself wanting so I’d always have to go back to the client to getting info that I was supposed to to get even before writing any code. But since I took the planning stage more seriously things have been really going well for me.
Last summer, I built an MVP called Unison for a friend of mine. The app is an online community for women to share health-related experiences and connect with others. I was honored to be asked to build
Svelte 5 is out! It's packed with new features and I've heard good reviews so far, but I hadn’t had a chance to dive in until now. I've spent the last year building a SvelteKit web app using Svelte 4 (racquetrivals.com, come play). For comparison, th...
Hello JavaScript Back in 2016, I started my career as a software consultant for a healthcare tech company. I worked with customers to learn about their needs and then configured their business logic into our product. We used a browser-based interface...
An overview with code samples
I had a big advantage during and after the coding bootcamp I attended - I already had over 5 years of experience in tech. I was not able to pursue software development at my previous company, so I quit and enrolled in a full-time coding bootcamp. Afterward, I knew exactly how my target development role fit into the broader scope of the software development lifecycle. I pulled from my previous jobs collaborating with developers, product management, QA, UX, sales, and customers to build a portfolio that I was confident in.
As a budding developer building a portfolio of work, you won't have the luxury of having a product analyst to determine requirements or a sales team to sell your app. On top of learning new tech and learning how to code, right now you are also in charge of every other business role at your one-person software shop. The more familiar you are with each role, the more professional and competitive your portfolio will be.
In this article, I'm going to share some context about typical development-adjacent departments, and practical tips to make you stand out.
I realize it is incredibly arrogant to reduce all of the following fields to fit into the rest of this blog post, and that is what I'm about to attempt to do. Each one is deep enough to dedicate your entire career to, and I encourage you to explore each of them in more detail. Here are some starting points for you to incorporate them into your projects.
The product management team is responsible for defining what features the product should have. I previously worked as a product analyst, so I have a bit more to say about this section than others. It is closely linked with development, and there is a lot to be gained by having an understanding of the product team. Day to day, it boils down to a few things.
Code is just a tool to solve problems, and the first step in the lifecycle of a software project is the problem itself. It can be difficult for a company to know exactly what the right problem to solve is, so it is common to have discussions with customers experiencing the problem regularly. Steve Jobs famously stated that you must start with the customer experience, and then work backwards.
Large features are organized into epics like "Create a user authentication workflow", which are comprised of smaller stories such as "Build a login page", "Build a registration page", and "Build a Forgot Password workflow". These stories are broken down into acceptance criteria like "Ensure a login with correct credentials is successful" and "Do not allow passwords of less than 10 characters during registration." Together, all of these stores and AC make up the requirements for the feature, which development will later use as a blueprint to build the product.
...and maybe more importantly, what features to forget. Saying "No" is one of the most powerful tools in the product team's toolbox, because there are simply too many possible features to build with the the team's finite resources (people and time). Product teams use a backlog, which is just a list of all the stories and bugs they are responsible for, ordered by importance. They constantly reprioritize the backlog based on the current demand for each item to make sure the most important ones are being handled.
When building a portfolio project, think about your hypothetical customer/user before you start writing any code. What is the main problem they would need to solve? What is the simplest way you can solve it?
During your planning phase, write out some user stories for the most important features. They are from the perspective of a typical user and commonly take the form "As ___, I want to ___ so that I can ___." It's a good exercise to get you thinking about your project from the perspective of someone using it, who in real life could be someone who hires you!
Create a backlog and any time you have an idea for a new feature or find a bug that needs to be fixed, add it to the list. If it is the most important, put it on top. If it isn't critical, put it lower. Determine what is absolutely necessary for your MVP (minimum viable product) and deprioritize the rest. Once your MVP is finished, feel free to polish it up with the remaining items from the top of your backlog.
The UX team focuses on enhancing user satisfaction using the product. They design interfaces that focus on solving the users' problems in a way that would be most natural. They research market trends to find what would make their product more engaging. Usability, accessibility, visual design, and many other factors go into building high-fidelity mocks of user interfaces. They share these mocks with the product and development teams, then iterate upon them before development brings them to life.
Make mocks of your screens before coding. They can be hand-drawn wireframes, basic shapes in a tool like draw.io, or something higher fidelity like Figma. It saves a lot of time in the long run to figure out the layout and flow of your app before starting to code.
Make your app mobile responsive, and actually test it out on a real device. People scrolling on LinkedIn may pop it open on their phone, so it should look good! Most UI libraries provide tools to make responsiveness easier than raw media queries.
Be intentional with the visual design. Spending a little time learning about color theory, typography, negative space, and other UI concepts can go a long way. Pick a color palette and a font, and find a UI library to handle basic components.
Make the app as easy to use as possible. Reduce clicks, offer some functionality without a login if possible, and group related components near each other.
Develop an eye for "jank", and remove it. If your app has components moving around that shouldn't, requiring more clicks than expected, or generally doing things that might raise an eyebrow, find out why and resolve it. If your app doesn't have any noticeable flaws, the important parts will shine.
The QA team is responsible for ensuring that the product meets the requirements set forth by the product team, and is free of bugs. They are the final human check before the product is released into the wild. QA conducts both manual and automated testing to simulate typical user behavior as well as more unlikely edge cases to give the company confidence in all code changes. In a larger codebase, a code change can affect something in a seemingly unrelated area, so the more automated testing you have, the more likely these sneaky bugs will be caught.
Unit tests are technically a developer's responsibility since they are part of the code, but I've included it in this section because it's another tool that professional teams use to test code. Unit tests allow you to test the behavior of a single "unit" of code against predefined test cases by simply running a test command.
Instead of preparing a fake scenario and manually calling an API endpoint to test something, you could write a unit test loaded with mock data, see its response to that data, and assert that its output equals the value you expect. If anything in the codebase changes that affects the API endpoint, the unit test will fail when you run it and you've now located a bug that you may not have known to check for. It's important to test the behavior of your code as a user might interact with it, rather than internal implementation details.
There is a lot of debate about how much unit test coverage is sufficient, as it may not be practical to write a unit test for every single thing. A common number I've seen to strive for is 80% coverage. Having a high coverage allows you to be more confident in your code changes and adapt to changing requirements. Test-driven development (TDD) takes this to the next level and recommends that you write unit tests before you write any code, watch them fail, and then write the code to make them pass. TDD is beyond the scope of this article, but it's definitely something to look into.
Be your own QA team. After you add a new feature, check other related features to ensure they behave as expected. Confirm that they fulfill the requirements you created previously when you had your "Product" hat on.
Think of edge cases and try to break your app through user interactions. What happens when you add letters to a field expecting a number? What happens if you click a button very quickly many times?
Write some unit tests. While they aren't quite as critical as in a professional app, having a few unit tests on API endpoints and key frontend behavior will give you confidence in your code and in your ability to speak about testing in interviews.
Sales and marketing are typically two closely related departments. The sales team is responsible for selling the product to customers and generating new revenue for the business. The marketing team drives product awareness, interest, and brand reputation. Their goal is to get prospective customers thinking about the product and connecting them with the sales team.
As you are developing your portfolio apps, always think about who you are serving and how you would reach them. An excellent portfolio project would have real users you can market to and maybe turn into a business, but that is not necessary to demonstrate your skills. You will, however, need to market your projects online at least via LinkedIn and Github so that someone looking at your profile can see what you have to offer.
HOST. HOST. HOST. If at all possible for your app, get it hosted somewhere online so that anyone who wants to check it out can. Nobody is going to clone your repo locally and run it on their machine.
Write good README's for your GitHub repos. You've done all the hard work, now let the world in on what you've been up to. Without a README.md file, your repo is just a folder with some code. In your README, add an overview of the project, tell people how to use it, list what technologies you used, and add any other relevant details.
Post about your project on LinkedIn. You can post updates as you go, or just when it is completed and hosted.
Bonus points - make a video walkthrough of the project and share it. It's an easy way to demonstrate two of the most important things interviewers are looking for.
You have the skills
You can communicate with other humans
You can use Loom to record your screen and face easily, here is mine as an example.
No, I'm not talking about selling your soul to the devil or selling out to The Man. The bigger picture of marketing your portfolio projects is to make a strong showing for yourself on the job market. When you are job searching, you are selling your skills and experience to buyers - companies, startups, freelance clients, etc.
Build a network so that people can find you. Connect with people on LinkedIn including other developers, people in related fields, or anyone who seems interesting. Go to in-person meetups to make local connections with other developers and techies in these adjacent fields.
Post regularly on LinkedIn. It lets your audience know that you are on the market and that you're continuing to sharpen your skills. Share updates about what you're learning, or when your project is ready to check out.
Before an interview, think about what salary you could realistically ask for based on your skills, the position, and the market. Also know what number you'd be happy with if they negotiate, and know what your minimum is.
There are several other departments at tech companies like Site Reliability Engineering (SRE), Data Engineering/Analysis, and Customer Success, but I find that the ones listed are the most applicable to your journey. I know this is a lot on top of your normal studies, but the job market is full of junior developers who want the same thing that you do. Leveraging these tips is something within your control to give you an edge. As a side note, many people assume that they must be a developer to get into tech, but you can target one of these other fields instead if they seem like a better fit. Good luck!
