[website] Move the React Engineer - X role to future roles

[DanailH]

• I have followed (at least) the PR section of the contributing guide.

https://deploy-preview-42532--material-ui.netlify.app/careers/

[mui-bot]

Netlify deploy preview

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

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 746cb55

[oliviertassinari]

I have unlisted the role https://app.ashbyhq.com/jobs/c86e52ce-0f3b-41cd-871b-5a7fd4044238/job-postings/77584e4c-9379-45f3-a294-6e50bf250383/info so it's not visible in https://jobs.ashbyhq.com/MUI and on LinkedIn, etc.

On the hiring priorities, from https://www.notion.so/mui-org/0ea5085349464aefa17a6f56a6e25c2c?v=30c98295e2da46ca90b275ac27996401, if the growth forecast matches the revenues, we could already start to work on the next two X roles. There are roles that will have higher resources availability priorities, e.g. X sales roles > X engineering role at this point. So maybe risky, and instead, we can focus on onboarding of the new members.

For these X engineering roles, what I see:

• A 3rd member on the charts team, give it more weight to bring revenues and be a serious open source option. It might take a while to find this 3rd person. While the charts team is small, every new joiners potential matters a lot, they will be the ones growing the team x10. Here are areas the team might need help on, I don't know how much Alexandre and Jose would want to focus on. Design engineering: bring blocks like tremor. Product leadership: be out there on Twitter to help/incentive Tremor, Mantine, etc to migrate from Recharts, go-to-market focused. The regular product engineering duties: bring more bandwidth. Noted added to the opening on Notion (better place to discuss further)
• A new hire on the eXplore team. There, I could see us clearly playing the Mantine, Shadcn card. Wrap react-upload, full-calendar, slick, window-splitter, tiptap, and bring Material UI design to those. Push all support queries to these libraries if they are not style related. So this would be a very product design engineer role oriented. Otherwise starts a few small components: signature field, window splitter, barcode. I don't see us having bandwidth to start something large and in depth like RichTextEditor, no. A Scheduler/Gantt could almost be within range, but it feels like a too high opportunity cost, we don't know what it takes to do it well, if we are ressources strap, Grid, Charts, small components feels like should take resources propriety. If they do, then we would be left with not enough resources to bridge the gap needed to differentiate with those, so waste our time because we couldn't focus enough. Noted added to the opening on Notion (better place to discuss further).

[oliviertassinari]

Commit cherry-picked to master 8417e42 to clear potential confusions. https://x.com/rmaximedev told me he tried to follow the link on our career page but it lead to a closed Ashby role. We are good now on master: https://master--material-ui.netlify.app/careers/.

[DanailH]

That's why I didn't close the Ashby role initially. I opted to wait until this was released, but thanks for cherry-picking it 🙏

[oliviertassinari]

@DanailH Right, the problem I see with keeping the role open in Ashby is that then people spend time applying for nothing and then we have to spend time rejecting them.

I'm linking this to illustrate as another instance of https://www.notion.so/mui-org/Update-mui-com-careers-to-sync-with-Ashby-6749a5ddbb7e4671b461e5c50d4476ff?pvs=4#66b79b82689a422ba97cfe3136e98f86. This could be the solution long-term. cc @mikailaread also for awareness.

Edit: I have also pushed a commit c890b25 to remove the developer advocate role that we closed number of days ago.