As a reminder, the two types of engineers I'd hire are:
1. A senior frontend engineer who has focused on design systems before 2. A senior frontend infrastructure engineer
Type 1 is probably slightly easier to hire than Type 2, so let's start with that this morning.
If I were to write a job description for the role, I would emphasize the following skills/experience:
1. Design tokens 2. Experience maintaining a design system 3. Experience with CSS and CSS-in-JS 4. Experience working closely with designers in a design systems context
And a quick reminder...a component library is just a small part of a design system, so you're looking specifically for design systems experience.
In an interview context, I'd probably ask the following types of questions:
1. How flexible should a component library be? 2. How would you encourage designers to organize their Figma files?
3a. What are design tokens?
3b. How are design tokens different from themes?
4. What's a pattern that you commonly invoke when building component library components? 5. How do you ensure that a component is accessible? 6. What percentage test coverage should a component have?
When asking these questions, you're not necessarily looking for a "right" answer. You're looking for a thoughtful answer. You should be able to tell whether these are questions the engineer has ever considered.
If they haven't considered these questions and can't readily explain their answers, they probably don't have the experience you're looking for.
Let's move on to the second type of engineer you should hire on your design systems team: the frontend infrastructure engineer.
If I were to write a job description for this role, I'd emphasize the following skills/experience:
1. Experience with versioning/publishing 2. Experience with monorepos 3. Experience with bundlers like webpack and rollup 4. Great communication skills
In an interview, I'd ask questions like these:
1. If you were starting a component library, would you use a monorepo? 2. How would you let consumers know when new packages are ready? 3. Can you walk me through how you'd implement versioning and publishing new components?
4. If you were tasked with setting up a new bundler in a component library, how would you decide which one to use? 5. If you were setting up a new release strategy, how would consumers know which components are stable?
Again, you're not looking for a specific answer to any of these questions. You're looking for a _thoughtful_ answer. You're also making sure this person can explain relatively complicated topics in simple words.
I'm biased since I'm a frontend infra eng, but I think this role is underlooked role in DS. Without this expert, your current engineers have to cover the slack. They may not do it well in a short amount of time.
Caveat: If you want to give your current engineers the opportunity to learn new skills, go for it. Just know that you're making a tradeoff in speed and quality and hiring an expert will help them learn more quickly.
If you liked this thread, send me a DM, and let's talk! 😊
Or if you just like learning more about design systems, you can always sign up for my newsletter: maecapozzi.com/newsletter
Yesterday, I tweeted about the two first eng hires I would make if I were starting a new #designsystems team.
Today, I want to dive deeper into the type of work each of those engineers does, and how to discover what kind of eng you're talking to in an interview.
1. A senior engineer who specializes in CSS, component architecture, and design tokens.
2. A senior "frontend infrastructure" engineer, who specializes in versioning and publishing, bundlers, and automation.
Let's talk about engineer type 1 first. This is the engineer people think of they hear "design systems". And for good reason, because having this person on your team is invaluable. I've got a list of questions that this person can answer for your team.