Thread by @MCapoz

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.

https://twitter.com/MCapoz/status/1356982047085101061

The two types of engineers are:

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.

I'm going to link out to my blog whenever I reference I topic I've written about in case you want to dive deeper or you're unfamiliar.

1. How flexible should our system be? How can we let consumers opt-in to more flexibility? (maecapozzi.com/progressive-di…)
2. What are the layers of our design system? (maecapozzi.com/layers-of-abst…)
3. How should we structure our design tokens? (maecapozzi.com/design-tokens/)

4. How should we approach styling our components? Plain CSS, CSS-in-JS?
5. What kind of patterns should we use for component overrides? (maecapozzi.com/override-style…)
6. How will we ensure that our design system is accessible?
7. What JavaScript framework will you use?

And finally... this person is going to build the bulk of your early components. They are the difference between having 3 components and 30 components in your first 6 months.

Now let's talk about the second type of engineer, the #frontendinfrastructure type. They are less obvious when you're thinking about design systems, but they are just as important, imo. Here are the types of problems this engineer can solve for your team.

1. How to version and publish components
2. Should you store your components in a monorepo? (maecapozzi.com/monorepo-or-mu…)
3. Should you use a tool like lerna? (maecapozzi.com/what-is-lerna/)

4. What should your release process look like?
5. How can you automate versioning/publishing in your CI flow?
6. How can you automate setting up new components? (maecapozzi.com/generate-packa…)

7. What are your bundle size budgets?
8. What bundlers should you use?
9. How do you configure a bundler?
10. How do you make sure that your library isn't causing negative perf implications for your consumers?
11. How do automatically let consumers know a new release is ready?

This thread is getting really long, so I'll stop here. Let me know if you want to talk more about how to evaluate which type of engineer you're talking to in an interview!