I recently joined Meta as a mid-level SWE and matched with a backend-heavy infra team. I chose it because I wanted to grow. I've been forcing myself to keep doing backend because it always felt harder, and I didn’t want to keep avoiding it. I’m technically full-stack and enjoy frontend/product work more, but this org is very backend-focused, and I don't know how much product work (like internal tools) drives impact here. I'm assuming it doesn't as much as infra, because the whole org is infra.
Now that I’ve been on the team for ~2 months, I’m really struggling. I want to get better at backend, but I genuinely don’t know how to improve. Even small changes feel like editing 20 files. There’s no clear testing strategy, and things are very company-specific, so I can’t Google, build side projects, or learn in public like I could with frontend (React/HTML/JS). Backend here feels like a wall, and it’s hard to build intuition or momentum.
I’ve been reading test plans and tracing code, but it often feels like I’m guessing. I also know I need to hit "meets expectations" to transfer internally, which I understand, but it makes it feel like I have to get good at backend, whether it fits me or not. There is a possible exemption path, but I think I wouldn’t even be eligible to ask until I’m at least 6 months in, and I’m not sure if that’s worth pursuing.
So I have a few questions:
Appreciate any thoughts or advice — I just want to find a path where I can both grow and be effective.
This is one of the painful parts about working at Big Tech, especially Meta. Meta has a huge "build in-house" culture, so almost everything is Meta-specific. I got lucky at Instagram as their Android style is incredibly vanilla, but outside of Instagram, Meta uses their own Android frameworks that don't even feel like Android anymore, making side-projects useless.
Anyways, my biggest piece of advice is to pattern match. There's got to be some E3/E4 engineer on your team who is doing fine. Try to mirror their workflow as much as possible. Try to make them like you as much as possible, so they're willing to explain their workflow to you. If being productive on this team was truly impossible, then it wouldn't exist. At E4, your raw learning power generally isn't very strong yet, which was the case for me. So when I started at Meta, my coding workflow was pretty much this:
If you’re full-stack in a backend org, is it okay to lean into frontend work for delivery — or does that limit your growth and impact?
Talk to your manager. If there's high-impact frontend work within your team's scope, it should be fine as impact is impact. If there's isn't, then you could be seen as being distracted.
Has anyone here ever successfully switched teams before the usual 12-month requirement? Is asking for an exemption ever worth it?
I have seen it, and it is entirely dependent on your relationship with your manager. Having an engineer leave so soon is super thrashy, so your manager needs to like you a lot as a person in order to green light this. On the flip side, if a manager doesn't like you that much and sees you struggling to fit into the team, they will opt for the PIP/early exit route instead. The manager relationship is so, so, so important at Meta.
I don't think I will ask for an exemption. Like you said, it seems incredibly difficult. I think I will do my best to follow your advice and find another E4 engineer and copy what they are doing. But I guess my follow up question here is, do you think it makes sense for me to plan to transfer a year from now? Or do you think I'm overthinking it? I feel like I keep forcing myself to do something I just don't enjoy, but at the same time I don't want to "run away" from the problem.
...do you think it makes sense for me to plan to transfer a year from now?
If you still don't like the team, you should 100% switch. The earlier the better as you need to get to E5 within a certain amount of time.
Thank you Alex I really appreciate your thoughtful straight to the point advice!
Oh I had another question, you mentioned that one issue with Meta is that it’s all internal, but isn’t that kind of the case at other big tech companies too?
Also, I’ve been wondering if my thinking around product vs backend is actually valid, like, even with internal frameworks, product work still feels more “Googleable” and easier to improve at on your own. But with backend or infra, I just feel like there’s no real way to get better outside of work. Do you think that’s true in general, or is that more of a Meta-specific thing?
I think you mentioned in a few of your courses how you can build up your skills outside of work by working on side projects related to the stack that use at work and I feel that that's true for front end development as well as mobile development but I feel like with back development there's really no way to get better at the stack on your own.
Oh I had another question, you mentioned that one issue with Meta is that it’s all internal, but isn’t that kind of the case at other big tech companies too?
Yeah, this is the case for all of FAANG. But I feel like it's particularly bad at Meta. Meta literally forked Mercurial instead of using Git like everyone else. Meta really wants everything to be internal and custom.
...even with internal frameworks, product work still feels more “Googleable” and easier to improve at on your own.
I was a front-end engineer at Meta. I almost never Googled for anything even though Instagram was vanilla Android (despite being vanilla, the codebase was so complicated and the problems so hard that Google was useless). If you work on native Android on Facebook app and use Litho, Google is effectively 100% useless. Side projects were helpful though in that it just boosted my overall coding speed, muscle memory, and understanding of general Android concepts.
If you go to FAANG, Google will almost certainly not be that helpful, especially if you have made it past L3/E3.
...I feel like with back development there's really no way to get better at the stack on your own.
You can build back-end side projects, but it's just harder for them to feel as concrete as front-end. For the most part, a back-end exists to serve a front-end, but if you're only doing back-end, it's rough. It is tough for a back-end only project to find traction.