[website] React Engineer - xCharts role

[DanailH]

• Preview https://deploy-preview-38976--material-ui.netlify.app/careers/react-engineer-x-charts/
• Role opening: https://www.notion.so/mui-org/React-Engineer-xCharts-327a52135553432fb680c4788b18067d

To do:

• Once this PR is merged make the role on Ashby active

[DanailH]

Do we want to have a more detailed explanation of what the targets for the charts are?

[oliviertassinari]

We could maybe add a paragraph about our vision and plan. The person might join us on a long journey, so drawing a picture of it could be great.

In terms of differentiation, I see 4 phases of growth:

1. Tight integration with the rest of the MUI libraries. This tight integration is both about Material UI and about the data grid for plotting data. We can likely reach 30% of the downloads of alternative React libraries, like recharts, considering benchmark data. Developers value having a single touch point, but also one they trust, and one that integrates well in the rest of their app.
2. The most popular open-source libraries' development feels like they aren't moving as fast as it would be possible. Check chart.js, recharts, and others. With an open-core model, we will be able to allocate more resources (having more maintainers, so they can themselves engage more community contributors) to solve bolder challenges, providing more in the open-source version.
3. The paid actors in the space capture over >$10M/year, e.g. Highchart (~$7M/year), FusionChart, Kendo UI, etc. So enough to sustain this initiative, and more importantly, we see nobody in the space betting on an open-core model. Existing paid actors can't justify losing revenues in the short-mid term (4-year cycle), exiting open-source actors don't want to risk a big culture change or can't solve the governance problem.
4. Distribution channel toward low-code and AI. Plotly, Metabase, Observable, Cube.dev. This is long-term, but having a foothold in developers' tools will allow us to distribute and enhance charts with their primitives.

[DanailH]

I've extended the description a bit.

[mui-bot]

Netlify deploy preview

https://deploy-preview-38976--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 844943f

[oliviertassinari]

Alexandre is the PO on the charts today: https://www.notion.so/mui-org/Charts-ba435669d56f450ea5b8bd0bfb18d5de.

What's the plan for the product ownership of the charts going forward? I mean, how do we see it scale, e.g. to 3 people?

[oliviertassinari]

We could maybe add a paragraph about our vision and plan. The person might join us on a long journey, so drawing a picture of it could be great.

In terms of differentiation, I see 4 phases of growth:

1. Tight integration with the rest of the MUI libraries. This tight integration is both about Material UI and about the data grid for plotting data. We can likely reach 30% of the downloads of alternative React libraries, like recharts, considering benchmark data. Developers value having a single touch point, but also one they trust, and one that integrates well in the rest of their app.
2. The most popular open-source libraries' development feels like they aren't moving as fast as it would be possible. Check chart.js, recharts, and others. With an open-core model, we will be able to allocate more resources (having more maintainers, so they can themselves engage more community contributors) to solve bolder challenges, providing more in the open-source version.
3. The paid actors in the space capture over >$10M/year, e.g. Highchart (~$7M/year), FusionChart, Kendo UI, etc. So enough to sustain this initiative, and more importantly, we see nobody in the space betting on an open-core model. Existing paid actors can't justify losing revenues in the short-mid term (4-year cycle), exiting open-source actors don't want to risk a big culture change or can't solve the governance problem.
4. Distribution channel toward low-code and AI. Plotly, Metabase, Observable, Cube.dev. This is long-term, but having a foothold in developers' tools will allow us to distribute and enhance charts with their primitives.

[oliviertassinari]

@DanailH Nice, thanks for opening this PR 👍

I have created an opening https://www.notion.so/mui-org/React-Engineer-xCharts-327a52135553432fb680c4788b18067d and added a few ideas on the page on how we could try to find candidates (looking at existing open-source projects, trying to find people who where invested in this in the past).

[joserodolfofreitas]

Excited to see the candidates this post will gather!
But I'm struggling to understand how the xCharts candidates should differ from the usual engineering role. I think we need to define some of the requirements of what we're looking for (which may be listed as optional). For instance, should the candidate have Graphics/WebGL/Canvas experience?
Maybe @alexfauquette has some ideas on interesting criteria we could adopt.

[DanailH]

Excited to see the candidates this post will gather! But I'm struggling to understand how the xCharts candidates should differ from the usual engineering role. I think we need to define some of the requirements of what we're looking for (which may be listed as optional). For instance, should the candidate have Graphics/WebGL/Canvas experience? Maybe @alexfauquette has some ideas on interesting criteria we could adopt.

@joserodolfofreitas Olivier did a similar thing when the grid was started. The person who initially worked on the grid has previous experience with developing that component. We can look for people who have past experience with working with charts or even better - working on open-source (and paid as well) chart projects. If we find a good candidate like that they can help us move even faster.

[alexfauquette]

Working on charts is not exactly as other components for two reasons

• First the technology itself. We manipulate SVG or canvas instead of HTML. For example, see how hard it is to set text at the right place. So it's nice to get dev that know at least a bit of those technologies and are interested in them.
• Second is the math aspect: In web dev, the math level you use on a daily basis is close to what children do (+, *, and %). In charts, you need to work with coordinate, so you better enjoy playing with interpolation, unit conversion, and trigonometry

So I think engineers applying for charts could be redirected to other components if they want, but you could get people interested in usual components that would not like working on charts.

[mnajdova]

It may be a bit hard for people to differentiate between the X and xChart open roles. Maybe we should mention the project with are targeting with with the X role, so it's more about choosing the project inside the team that you would like to work on.

[DanailH]

Working on charts is not exactly as other components for two reasons

• First the technology itself. We manipulate SVG or canvas instead of HTML. For example, see how hard it is to set text at the right place. So it's nice to get devs that know at least a bit of those technologies and are interested in them.
• Second is the math aspect: In web dev, the math level you use on a daily basis is close to what children do (+, *, and %). In charts, you need to work with coordinate, so you better enjoy playing with interpolation, unit conversion, and trigonometry

So I think engineers applying for charts could be redirected to other components if they want, but you could get people interested in usual components that would not like working on charts.

Good point @alexfauquette . To solve that we are also going to open the regular React Engineer - X role. Regarding the difference of interest and skill - if you can put a line or 2 together so we can add it to the description that would be great, that is if you already have something in mind. If not I will do it.

It may be a bit hard for people to differentiate between the X and xChart open roles. Maybe we should mention the project with are targeting with with the X role, so it's more about choosing the project inside the team that you would like to work on.

@mnajdova I know what you mean. We had a similar issue with the tech lead role we were looking to fill for the data grid. In the end, I think what most people look is the title and the requirements. I think people really read the full description before applying.

[oliviertassinari]

Rebased on HEAD to avoid the annoying Argos diff at each commit.

I can't identify anything else to improve on this PR. It looks nice.

[DanailH]

@oliviertassinari @mnajdova If possible I would like to include this in this week's release. One thing that popped up since last Friday is that we are now entertaining the idea of opening up a Design Engineer role for the xGrid. Do we keep the React Engineer - X role or have the Design Engineer - xGrid role? I would be in favor of the second one. @oliviertassinari what do you think?

[oliviertassinari]

Do we keep the React Engineer - X role or have the Design Engineer - xGrid role? I would be in favor of the second one. @oliviertassinari what do you think?

@DanailH It needs to be a different role in Ashby because the hiring steps are different.
I think it should be a different role on our career page because what we are looking for is not the same.

[DanailH]

Do we keep the React Engineer - X role or have the Design Engineer - xGrid role? I would be in favor of the second one. @oliviertassinari what do you think?

@DanailH It needs to be a different role in Ashby because the hiring steps are different. I think it should be a different role on our career page because what we are looking for is not the same.

Yes, I agree, I was thinking the same. My question was more related to do we have the green light to look for that person. If yes then I will set it up both here and Ashby.

[oliviertassinari]

My question was more related to do we have the green light to look for that person. If yes then I will set it up both here and Ashby.

@DanailH I think better to handle this in a different PR. I think first to fill in https://www.notion.so/mui-org/Design-Engineer-X-b4c69cc6dd5e4b19b94943fc91af5ddf. Per https://www.notion.so/mui-org/X-General-Meeting-2023-09-22-ff17cb82865f48f89ac239e30b64c866?pvs=4#c95b50aa6fca4d7d971d8f35697b21c4 I think we can take it iteratively.