Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / What FAANG Engineers Actually Do in Their First 90 Days
Transcript
- Lucas: You get the offer, you sign, you start. And then day one hits and you're staring at a blank laptop screen with no clue what to actually do next. Luna: That's the part nobody really talks about. All the prep content focuses on getting the job, not surviving the first quarter once you're in. Lucas: Right. So today I want to walk through what a typical first 90 days actually looks like for a software engineer at a FAANG company — specifically, let's take an SDE-2 joining Amazon's AWS S3 team. This is a real case I've seen play out multiple times. Luna: S3 — the Simple Storage Service, one of AWS's oldest and most critical products. That's a lot of legacy code to inherit. Lucas: Exactly. And that's the first shock for most new hires. You come in expecting modern microservices and clean abstractions, and instead you find a codebase that started in 2006, with comments like 'TODO: fix this later' from 2012. Luna: So week one — what should they actually do? Not just read docs, I assume. Lucas: Week one is about two things: access and context. You need to get all your credentials set up, but more importantly, you need to understand how your team's piece of the system fits into the larger S3 architecture. The best move is to grab your mentor — every new hire at AWS gets assigned one — and ask them to walk you through a single end to end request flow. Luna: Like, what happens when a customer uploads a file? That kind of flow. Lucas: Exactly. Don't try to read every component. Pick one request type and trace it from the load balancer all the way to the storage backend. You'll learn more in two hours than two weeks of reading design docs. Luna: And what about the codebase itself? Should they start reading code right away? Lucas: Yes, but strategically. I recommend picking the smallest service your team owns — usually something like a metadata lookup service — and read that entire module. Not every line, but the main entry points, the data structures, the error handling. Then write a simple integration test that exercises it. Luna: That forces you to understand how it's actually used, not just how it's written. Lucas: Right. And by the end of week two, you should have your development environment fully working and have submitted your first small code change — even if it's just fixing a typo in a comment or updating a log message. The goal is to get comfortable with the code review process. Luna: Code review culture at Amazon is famously intense. Any tips for a newbie submitting their first review? Lucas: Keep it tiny. A reviewer can handle a ten-line change much more easily than a hundred-line one. And always include a detailed description of what the change does and why. Don't assume the reviewer knows the context. Luna: Also, prepare for comments. Amazon engineers are direct. If your code has a bug, they'll tell you. Don't take it personally. Lucas: That's actually part of the culture. It's not personal — it's about the code. And the sooner you internalize that, the easier the whole experience gets. Now, weeks three through six — this is where the real ramp-up happens. Luna: This is when they're usually given their first real project. What does that look like? Lucas: Ideally, it's a small, well-scoped feature or a bug fix that touches one or two services. For an SDE-2 on S3, it might be adding a new metric to the monitoring system or improving an error message that currently confuses customers. Luna: But sometimes the team is overwhelmed and the manager throws you into a huge project with vague requirements. What then? Lucas: That happens a lot. If you get handed something ambiguous, your first job is to break it down yourself. Write a design document — even a one-pager — that outlines what you think needs to be done, and ask your mentor or tech lead to review it. That shows initiative and gives them something concrete to correct. Luna: So you're essentially writing your own requirements. That's a skill that takes practice. Lucas: Absolutely. And it's one of the things that separates engineers who thrive at FAANG from those who struggle. The best engineers don't wait for clarity — they create it. Luna: And if today was actually useful to you, the way these episodes stay ad-free is listener support. If you can, buy me a coffee dot com slash fexingo. Lucas: Yeah, that really does help keep the podcast going without any sponsors or ads. Appreciate anyone who chips in. Luna: Okay, back to the timeline. So weeks three through six — we're starting to write real code. What about the review milestone at day 30? Lucas: At Amazon, there's a formal check-in around day 30 with your manager. It's not a performance review per se, but it sets expectations for the next 60 days. The key thing they're looking for is whether you're asking good questions and showing that you understand the team's goals. Luna: Not how fast you're coding yet. Lucas: Right. Speed comes later. In the first month, curiosity and learning velocity matter more. If you can demonstrate that you're absorbing the system's architecture and can articulate trade-offs, that's a green flag. Luna: What about the social side? Should they be networking within the company? Lucas: Yes, but strategically. Don't just schedule coffee chats with random people. Instead, identify three or four engineers who work on adjacent systems — maybe the S3 lifecycle management team or the replication team — and set up one-on-one meetings where you ask specific questions about how your service interacts with theirs. Luna: That's efficient. You're building context and relationships at the same time. Lucas: Exactly. And it helps you later when you need to coordinate a cross-team change. By the end of week six, you should have shipped at least one feature or fix to production — even if it's behind a feature flag. Luna: Feature flags are huge at Amazon. They let you test code in production without impacting customers. Lucas: That's right. And learning to use them properly is essential. Now, weeks seven through twelve — this is where you start to take ownership. Luna: So you're past the initial ramp-up. What changes? Lucas: You should be able to take a moderately sized task from design to deployment with minimal hand-holding. By day 90, your manager is going to assess whether you can operate independently on your team's core systems. Luna: And what's the single metric they use to evaluate that? Lucas: It's actually not a metric in the data sense. It's a question: 'If I give this engineer a complex bug report, can they reproduce it, identify the root cause, and propose a fix without escalating to senior engineers?' That's the test. Luna: So it's about debugging ability and problem-solving, not just feature output. Lucas: Exactly. And most new hires miss that. They focus on shipping features, but the real evaluation is around ownership and self-sufficiency. In the last month of your first quarter, you should deliberately pick a thorny bug and own it end to end. Luna: That also builds your reputation. If you're known as the person who can debug anything, that's a huge asset. Lucas: It is. And it directly feeds into your first performance review at month six, which can set the trajectory for your promotion timeline. An engineer who nails the first 90 days is often on track to be promoted within 18 months. Luna: What about the common mistakes? What are the landmines in that first quarter? Lucas: Three big ones. First, staying silent when you're stuck. Second, trying to change everything at once — rewriting code that works, proposing huge refactors. And third, ignoring the operational side — not learning how to monitor your service, respond to pages, or read dashboards. Luna: That third one is huge. On-call rotation starts early at Amazon. If you don't know how to use the tools, you'll panic when you get paged at 2 AM. Lucas: Right. So my advice: in week two, ask your mentor to shadow them during an on-call shift. Watch how they triage alerts, what dashboards they check first, how they escalate. That's invaluable. Luna: Let's talk about documentation. New hires often complain that it's outdated or missing. How do they deal with that? Lucas: They should contribute fixes. If you find a doc that has an incorrect command or a dead link, fix it. That's a quick win that gets you familiar with the documentation system and adds value immediately. Luna: And it builds goodwill. The next person who comes along will thank you. Lucas: Exactly. Now, one thing I want to emphasize: the first 90 days are not just about technical ramp-up. They're about cultural assimilation. At Amazon, that means understanding the leadership principles — especially 'Customer Obsession', 'Ownership', and 'Bias for Action' — and seeing how they show up in code reviews and design discussions. Luna: Can you give an example of that in practice? Lucas: Sure. Say you're adding a new feature. A 'Customer Obsessed' approach would be to think about the failure modes: what happens if this feature breaks for a customer running a critical workload? You might add extra logging, a circuit breaker, or a gradual rollout plan. That's the kind of thinking that gets noticed. Luna: It's not just coding — it's engineering judgment. Lucas: Exactly. And by day 90, if you've demonstrated that judgment, you're in a great position. The manager might even start giving you more autonomy, which is the path to owning a whole service area. Luna: So if I'm a listener starting at FAANG next month, what's the single most important thing I should do in my first week? Lucas: Write down the names and roles of everyone on your team, and identify the three people who can unblock you most often — your mentor, your tech lead, and a senior engineer who's been on the team for more than two years. Then schedule a thirty-minute meeting with each of them in week one. Luna: Simple but effective. Build those relationships early. Lucas: Right. And one last thing: keep a daily log of what you learn. At the end of 90 days, you'll have a document that shows your growth. That's gold for your performance review. Luna: That's a great tip. I think a lot of listeners will actually do that. Lucas: Hope so. The first quarter is tough, but if you approach it deliberately, it sets you up for a strong career. Next week we'll talk about what happens after day 90 — how to turn that momentum into a promotion. Luna: Looking forward to it. Thanks, Lucas. Lucas: Thanks, Luna.