Return to blog

Building Personas for the Job Market

By Josh Ferrell
Two people talking during an interview

In development, it's a common practice to build personas to help designers and product owners think about the person that will be using the product. Developing a persona helps tailor an experience focused on what the end user will be doing with the product.

An example Persona for a Streaming Service

With this persona, a product owner or designer might think about possible solutions for promoting specific comedy shows or sci-fi shows to Josh, or maybe they are building an app that allows for different content to be discovered across multiple platforms.

Thinking about the position you want

Bringing the same type of thinking as designing a product into applying for a position makes sense as you're trying to advertise yourself to others. When looking at a position, think about what a hiring manager may look for. What are their current frustrations? Are they a large enterprise company or a new startup looking for a founding engineer? These two personas are very different.

A growing company wants someone with experience documenting processes as they go, training developers in best practices, and navigating the politics of a large organization. A founding engineer needs to move fast, and know how to build a solid foundation while filtering out nice-to-have features and focusing on product market fit.

Before sending out a resume or messaging a company, think about the things that companies are looking for and create a cohesive story about your background that fits that need.

Design Systems Job Persona

Let's take a design systems job posting. You read in the posting that they want a developer to build a new design system. The company is rather large and needs to have current best practices defined.

Now I know what to tailor my resume and cover letter for. I need to focus on my experiences with accessibility and times when I've maybe built a new design system. I need to talk about how I think about developer experiences or perhaps improve collaboration with designers and developers.

When I interview, I want to outline stories where I've succeeded in building these systems and talk about outcomes where developers improved productivity. In my recommendations, I include an engineer that's used a system I made and also include designers who have worked with me.

I also would want to talk about how I've defined why a design system was necessary during past roles by documenting multiple button implementations in use or presentations I gave in previous roles on why they needed a design system.

This way of thinking can be helpful because if the company has an existing design system, I may want to talk about how I have worked previously in maintaining large design systems. Maybe some pre-existing components weren't accessible, and I fixed the issues. Perhaps I did a refactor of a component and came up with migration guides for engineers on how they could move to the new component.


Coming up with different personas for roles you may want will help tailor a good resume that allows the manager to understand just how you're going to fix their problems. It helps you focus on what they need rather than giving a bunch of generic information that is scattered.

Remember that people are skimming when they read these resumes, so if you have some design system work in your resume but most of your resume focuses on the time you built an API, they may think that you're just a back-end developer.

If you're curious for examples, I have written out a few for my job search.