Maybe a gentler way of phrasing what Lee is saying:

Sometimes people dont have all the context for what our work is. And manytimes the feedback they give might seem, or even truly be, totally off the mark. But the people around us are talented and perceptive, and if they're giving feedback, it's because they perceive something about your work or actions that they feel they could help with. So I would look at pieces of feedback, even if they _seem_ incorrect, as gifts - whether its a matter of fundamentally changing your work, or maybe just how you're selling it or communicating is your call.

I would say that its a great idea to follow up if you want advice or clarity on how to improve. Sending a message like "Hey X! Thanks for the feedback on Y action. I'm keen on improving in this area, do you have any tips?" shows maturity and that you're taking their feedback seriously.

Finally, *dont internalize work feedback as reflective on your personal worth.* Its work feedback!! Its just a source for improving at your job. I know it can feel tough to hear, but do remember that it doesnt mean anything about who you are or your personal value. Use it to grow at work, stay positive, and you'll start to even enjoy getting feedback - which is the fastest way to rise.

Good luck!

Senior ML Engineer [E5] at Meta

Anon

- Give feedback to your manager if you felt put down by the senior engineer. That is not normal - their responsibility is to help. Sorry you had to deal with that

- When writing unit tests for a react component, I would break it down into two steps:

- First, get the simplest test you can think of to run. For example, if your component included an element with id #my-component, verify that after mounting that component, container.getElementById(#my-component) returns nonnull. This will get you able to understand how the tests are ran, and the particular nuances of whatever test runner you're dealing with.

- Once youve got a simple test, then you can start looking at the possible test cases to include. I would again start simple here - make sure that the most basic pieces of functionality work, and that all elements are visible. 

In both steps I would look for a lot of help if you're feeling lost. If possible ask other team members besides the engineer who was rude, but ask your manager if no one is able to help. Google and stackoverflow and docs are always your friends.

You're not alone - writing a unit test for a new component is tricky. Good luck for solving the problem

Senior Software Engineer [E5] at Meta

Anish Doshi

Sorry you're struggling with the tough decision. But here's the thing- from what it sounds like, your manager and your team _want_ you to stay, and hence in theory would _want_ you to get promoted. (This is true for most talented E4s)

So if you can come up with a very, very clear plan and expectations with your manager for the next year, I would stay because it'll be a lot easier to execute as an E5 with a team/stack you're familiar with.

You can also use this conversation as a litmus test for if you should stay. If your manager is unwilling to discuss such a plan with you, I would definitely consider leaving. But even then, _only join a team whose manager is able to give you a clear growth plan themselves_. That way, you can have confidence that you'll hit that promo wherever you end up. 

Senior Software Engineer [E5]

In addition to the other answers, I'd add the following notes:

Every team is different. Being an MLE in a research oriented/R&D team will involve implementing and productionizing algorithms, often directly from papers. Being an MLE in an AI inference or edge team will involve a lot of low level code and optimization. Being an MLE in a core ads team might involve a lot of testing, experimentation, and statistics to help evolve a complex system. (In fact, testing/experimentation is probably the most useful skill you can pick up if you're trying to go into an ML role at Meta!) As Rahul mentioned, sitting with an MLE is a great way to find out what their day-to-day life is like. I would also poke around their diffs, public posts, authored docs etc. to see even more specifics about what individuals are doing.

But I wouldn't let that discourage you from *learning* ML or trying side projects for fun. Give it some sort of time box window - like a month - to hack on something you find meaningful. Afterwards, identify the parts of it you enjoyed doing, and the parts you didn't. (For me, the parts I enjoyed were always designing the model architecture + seeing the optimization process happen in my notebook. The parts I hated were always data cleaning :) If there's enough of it that you *did* enjoy, then it's probably a good bet.

Also, it's worth mentioning that being in eng management for both an ML team and an SWE team will become more and more similar the higher you go - less about the specific technical decisions, and more and more about people, process, and culture management overall. I don't know about compensation at higher levels, but I don't think it's so different that it should really be a huge decision factor in the long term. However, MLE at Meta is good in that you are potentially more layoff proof, and can work on some high priority projects like ranking/recommendation.