Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Make Meaningful Technical Contributions as New Hires
Transcript
- Lucas: You join a FAANG company — the first few weeks are a fire hose of setup, onboarding talks, and a to-do list that feels infinite. But there's one thing that separates engineers who accelerate from those who tread water: landing a meaningful technical contribution, or MTC, in the first 90 days. Luna: MTC — I haven't heard that acronym before. Is that something formal, like an internal performance metric? Lucas: It's not official, but it's deeply embedded in the culture. Think of it as the first project where your work is visible, impactful, and defensible at performance review time. I watched a colleague at Google — let's call her Priya — do this brilliantly. She joined a team working on video transcoding latency. Her first eight weeks, she didn't try to build a new feature. She just read dashboards. Luna: Read dashboards? That sounds almost passive. What was she looking for? Lucas: She was looking for discrepancies — metrics that were monitored but never acted on. One dashboard showed that a certain encoding step had a high p99 latency but zero alerts configured. She dug into the code, found a thread-contention bottleneck, and fixed it with a lock refactor. The fix took her four days to implement. The latency dropped by 40 percent. Luna: Wow. And that counted as her MTC? Lucas: Exactly. It wasn't a glamorous feature launch. It was a reliability improvement with a clear before and after. She presented it at the team's weekly review, got a shout-out from the engineering director, and that single piece of work became the cornerstone of her first half review. Luna: So the key is not to aim for something huge right away. It's about finding a specific, observable problem that nobody has prioritized. Lucas: Right. And there's a framework that maps to this. I think of it in three phases. Phase one: orientation. You spend the first two weeks purely learning — reading design docs, setting up your environment, understanding the on-call rotation. Phase two: targeted exploration. Weeks three through six, you pick one area — maybe a service you noticed has high error rates or a build that's slow — and you propose a small fix. Phase three: controlled delivery. You execute that fix with testing, documentation, and a clear rollback plan. Luna: That last part — controlled delivery — is interesting. I've seen new hires rush to ship something big and break production. Then they spend the next month in damage control. Lucas: Exactly. The goal isn't to ship fast. It's to ship safely and visibly. When you have a clear rollback plan, you signal that you understand operational risk. That builds trust way faster than any feature could. Luna: I remember an internal study at Amazon — this was around 2020, I think — that looked at promotion rates for new engineers. They found that engineers who completed at least two small bug fixes before proposing their own project were 40 percent more likely to get promoted in their first year. Lucas: Forty percent — that's huge. And it aligns with what I've seen. Bug fixes are low-risk, they demonstrate code familiarity, and they show you can operate within the team's existing workflow. Once you've proven that, people are much more willing to trust you with a bigger project. Luna: So the MTC doesn't have to be a bug fix. It could be a test improvement, a documentation update, a monitoring dashboard. As long as it's visible and defensible. Lucas: Exactly. I had a friend at Facebook who spent his first month writing integration tests for an API that had none. No one had prioritized it because it wasn't 'shipping a feature.' But when he presented the test coverage report at the quarterly review, his manager used it as evidence of technical excellence. That counted as his MTC. Luna: And how do you choose the right area to focus on? Is there a heuristic? Lucas: I like to ask two questions. First: is this problem already on someone's radar? If it is, you might step on toes. Second: can I fix this with existing tools and without deep domain knowledge? If the answer to both is no, move on. Priya's latency fix — that was off the radar completely. The dashboard had been collecting dust for two years. Luna: So you're looking for orphan problems. Things everyone assumes someone else will handle. Lucas: Exactly. And those exist in every codebase. The build that takes 45 minutes for no good reason. The flaky test that everyone ignores. The error log that's full of warnings but nobody reads. These are gold mines for a new hire. Luna: What about the social side? I've seen new engineers hesitate to claim ownership of an orphan problem because they're afraid of offending the person who might have created it. Lucas: That's real. The trick is to frame it as curiosity, not criticism. Instead of saying 'this code is bad,' you say 'I was exploring the dashboard and noticed this spike — can you help me understand the context?' Then you ask if you can take a stab at a fix. Most senior engineers will be happy to mentor you. Luna: And if they say no? Or if the fix is already planned? Lucas: Then you find another orphan problem. There's never a shortage. But if you get resistance, it's also a signal about the team culture. A healthy team welcomes contributions from new hires. A toxic one hoards ownership. Luna: That's a good point. Your MTC is not just a technical milestone — it's also a way to test the waters of the team's collaboration norms. Lucas: Exactly. And once you land that first MTC, the trajectory changes. You become the person who 'hit the ground running.' That label sticks. It makes it easier to get assigned to high-visibility projects later. Luna: So the real value of the MTC is compound. It builds momentum. Lucas: That's the best way to describe it. And I think it's something every engineer can do, regardless of their starting skill level. It's about strategy, not raw talent. Luna: Before we go deeper — I want to tie this back to something you said about building trust. That resonates because, honestly, a lot of what we talk about on this show is about giving listeners practical, usable advice. And if today's conversation gave you something you can actually apply, that's the whole point. Lucas: Yeah, and the reason we can keep having these conversations without ads or sponsors is that listeners who find value sometimes choose to support us. It's a small thing that makes a big difference. Luna: Exactly. If you'd like to help keep the show going, you can do that at buy me a coffee dot com slash fexingo. No pressure, no perks — just a way to say this content matters to you. Lucas: And we appreciate it. Now, back to the MTC — I want to talk about what happens if you don't land one in the first 90 days. Is it catastrophic? Luna: I'm guessing the answer is no, but it does set you back. Lucas: It's not catastrophic, but it's a missed opportunity. The first review cycle — usually at six months — is heavily influenced by that early work. If you don't have an MTC, you're relying on your manager's memory of your 'potential.' And potential is much harder to defend than a shipped fix. Luna: So you're essentially leaving your performance review to chance. Lucas: Exactly. And the window for the MTC is real. After about 90 days, expectations shift. You're no longer the new hire who's learning. You're expected to be contributing. So if you haven't defined your own narrative by then, someone else will define it for you. Luna: That's a strong closing thought. For anyone starting a new role in big tech this summer — June 2026 — the clock is ticking, but the strategy is clear. Lucas: Find your orphan problem. Fix it safely. Let that momentum carry you. It's the single best investment you can make in your first quarter.