The Peterman Pod - Meta Senior Staff (IC7) Eng's Honest Demotion Story

Episode Date: January 23, 2026

In this episode, I talked to Igor, a senior staff engineer who has worked at Meta, Google, and Cruise. We discussed his experience of wanting a demotion at Meta and the challenges he faced in that process.𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀:• YouTube: https://youtu.be/i1iBweuOQI4• Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835• Transcript: https://www.developing.dev/p/meta-senior-staff-ic7-engs-honest𝗘𝗽𝗶𝘀𝗼𝗱𝗲 𝗹𝗶𝗻𝗸𝘀:• Igor's post: https://www.linkedin.com/feed/update/urn:li:activity:7401415295409700864/𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:00:00:00 - Intro00:00:37 - Why he wanted a demotion00:07:32 - Why Senior Staff at Meta was different00:16:01 - Meta vs Google culture00:19:09 - Downleveling at Google00:23:17 - Why he's willing to be transparent00:25:11 - Best quality of life eng level00:30:42 - Senior Staff promo at Google00:42:27 - Mentorship stories00:43:11 - Biggest career regret00:46:46 - Advice for younger self00:49:06 - Outro𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗜𝗴𝗼𝗿:• LinkedIn: https://www.linkedin.com/in/igorts/• ML basics youtube videos he made: https://www.youtube.com/playlist?list=PLVcptlT8D7DgN5FtLMFUdHb5pJXW1g0YL𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpeterman

Then I asked the management, can I actually drop a level? This is Igor, a senior staff engineer at Meta, Google and Cruz who wanted a demotion. You cannot still justify my level with the project being completed. He failed to get the demotion at Meta and going back to Google at a lower level was harder than expected. They don't have a process for bringing people at a level down, but they made it possible for me. We went over that experience and some transparent discussion across levels. engineering level has the best quality of life. There are many things that can go wrong when you share stuff like this.

What makes you willing to share? Here's the full episode. You mentioned in a post, a pretty famous post that I'll link so people can see that meta didn't have a process for demotion and you were looking for demotion. Can you talk about what led you to wanting a demotion at meta? Yeah, so when you join a big company, Meta is not the exception here, but you're joining a big company at a very high level, like senior staff. There are certain expectations from your performance, right? Come performance review, like in Meta, it's called PSC, you're being judged against other senior staff engineers in the organization, right?

And the meta, as of a year ago, they started to lay off people, like, they started doing the Amazon thing, essentially, like, let's lay off the 10% lowest performance. So what it means is that you have at most one year to ramp up to be comparable in performance to other old-timers of the company. And also, what does it even mean to be in, you know, E7 in the company? like this, right? You need to be an expert, a big expert in the field. You need to know a lot of people. You need to understand the infrastructure that you're working with very deeply. You probably need to be easily familiar with like any piece of code that your team is working with. And also you need to know all the surrounding, like what all the surrounding teams are doing. And you need to know all these people, like all poor people around you, and they need to know you and they need to trust you,

right? That's a very difficult thing to achieve within like a relatively short period of time. I initially saw that, okay, when you were, so again, joining Meta day one, I know less than an intern sitting next to me, you know, who spent maybe two weeks, who was hired two weeks prior to me, right? So like, I start from like level zero. then hopefully, like, you be able to get to something that, like, L3 would perform. So, like, you can take some very easy task that under supervision from other folks, you can kind of get, promote yourself to, like, a junior engineer, right? Then you do some more stuff, you learn additional things.

You can get promoted to, like, a less junior engineer, like a E4. And then slowly you ramp up, you know, to more and most of, like, higher levels, essentially like you start from zero and you climb the leather as fast as you can. Yeah, so you ramp up yourself to, you know, the level that you're supposed to achieve. And, you know, the more senior you are, the more levels you need to jump through. And I believe that within this year and two months that I spent in meta, maybe if I'm generous with myself, I maybe achieved like E6. So I don't feel like I reached E7.

What did you see that made you think you weren't living up to the expectations? It's self-judgment, grossly. This scale where we call numbers, it's not like quantum states, right? There are many things in the middle, right? It's a continuous scale. So it's very hard to say where you are on, the ladder but again comparing myself to other senior staff engineers the work that I knew I felt like if if anybody going to be on the chopping board that's going to be me

so that that was one thing about about this you know ramp up process and the second thing I also noticed that I really enjoyed doing like the coding stuff Like just sitting down debugging things. Like that's what I really loved about the job. So during my ramp up, when I was around like E5, E6 territory, that's what I really wanted to do, right? I felt like as a, you know, as someone who was programming from age of 12, I really liked coding, debugging, designing,

mentoring, more junior people. But like a senior staff engineer, it's more than that. It's like a leader who spends most of the time in meetings and design docs and touches much less code. It's a slightly different type of work. And just by going through this process, I realize that actually I want to be in the E5-E6 territory. And then I asked the management, like, the Ked. I actually drop a level.

And I understand that for the company, it's a difficult thing to implement because I already have some granted stock. I have a certain compensation package. And so how do you execute that? It's not a well-polished process. I know that they can switch levels when you go from one title to another. So let's say you were a director and you want to become an IC. So they do have some of that demotion process.

And frankly, I don't know how they do it. But yeah, like staying in the same job category and the dropping level just like they said it's not possible. I see. So when you asked if it's possible for demotion, your manager went to HR and kind of the result was just, it's just an impossible thing to do. You know, I asked a question and I got the answer, no. Maybe if I pushed harder, if I, like, went to talk to the, you know, D.P. or something, they would have made it possible. But at the same time, I, you know, I also felt like I'm too far outside of my comfort zone. And before coming to Meta, I worked a little bit at Cruise.

And before that, I worked at Google for 14 and a half years. and that was my comfort zone. I just had this option that, like, the easy way out, essentially. It's had the recruiter who was contacting me periodically. Like, I already to come back to Google. So this time I just said, yeah, let's talk. When you were at Google and at Cruise, you were at these senior levels as a senior staff engineer.

What's the difference that makes it so that you can perform there, but not at meta? So when I came to Google, I started from the lowest E3, like L3 level, junior software engineer. And slowly over the many years, I raised through promotions many times failing. Like they could promote it and then, you know, a year or two later asking again and then climbing the ladder. My last promotion to senior staff happened because they was able to accomplish something, big in the project that I worked I worked in that project for several years so it was already like an expert I knew everybody right everybody knew me and I was able to build something that I can be

proud of but again coming then then leaving Google and going to cruise it was also very difficult for me to ramp up there because you coming starting from zero and the first year was very difficult for me in cruise but over time I found like a relatively safe like you know my found some comfort zone there until Cruz as a company went bad like they had the accident and then they had layoffs and then like people were just quitting all the time like losing people so I decided that they want to leave as well but before Before the accident at Cruise, I actually was quite happy. I was able to do some coding.

I was able to do mentoring of Asherfox, and I was able to also act as an UberTL a little bit, like, guiding the team on things that they need to do. You successfully ramped up to senior staff at Cruise, and then at Meta it was a bit harder. What were the differences between those two ramp-ups, in your opinion? Chris was a smaller company, so less infrastructure to learn. The team is less crowded space, I would say.

You can easily carve out space for you to grow into. Like, you know, like there is lack of people, and you can say, okay, well, this project needs someone to work on, and you can just go and work on this stuff. At Meta, I felt like it's quite crowded, especially among the Cigiofogs. It felt a little bit like they have too many, frankly. At least in the work where I worked. So I don't know about all of Meta, but it felt like the space is a little bit crowded. You need to find scope for yourself.

Is there anything that you... have changed in your onboarding process that could have made things different? Probably. Again, I didn't switch companies that many times in my career. I started at Google, spent so many years there, then I only switched like cruiser and then meta. So I'm not very well experienced in switching companies. And essentially, you know, this whole ramp-up process is new to me. And I also felt like the management that meta also doesn't know how to import senior fox because most of the senior fox in the company, they grew within the company to those senior levels.

Even if they came to this specific org, you know, from another org within meta, but at least they already have the meta knowledge, you know, like they know how to run a job. in the cluster, right? I think I spent a lot of time just reading docs and trying to build this foundational knowledge. I think I spent too much time during that. It is much better to just get your hands dirty and just try doing stuff. And then doing those things in parallel. You build something, accomplish some tasks, and also you're learning in

parallel. And I did more of the learning part, less of the building. Yeah. Is there something that you wish was done or maybe something that would have helped you from the manager's side? Just guiding me, right? If they say, like, this other person just ramped up like, you know, three quarters ago and here's what they did, I would have followed that recipe. We just didn't have the recipe. Like, I'm not, I don't have any complaints against my management. Like, they, you know, they try to support me the best. They just also let this expertise of like, you're ramping up with senior folks, you know. So it was a learning experience for all of us. I've heard in conversations on other people as well that, I guess, job mobility as a senior

I see actually becomes progressive. riskier or maybe scarier, I guess, because you get so used to your existing org and all of that. Is that something that you've seen in other people or like peers as well in that senior IEC job ability is a lot tougher? I've seen Fox at Google that left Google and then came back a year or two later saying that it didn't work out well for them. I yeah it's you know people don't share things like that openly usually it's it's much harder to to hear those stories you hear the success stories you don't hear the failures also I think that if I

kept trying like instead of going back to Google I went to I don't know some other company I would be much like you know more experienced in ramping up and then maybe Maybe if you do this often enough, it becomes a habit. And then you can do it easily. You mentioned that you thought you weren't meeting expectations based on your own judgments. I'm curious, did you ever get any feedback from your manager or anyone saying, hey, you need to do more for your level's expectations? Yeah, I did get feedback.

I just don't necessarily want to openly share all of that. But yeah, I was, so in the part, like just the few months leading to my living meta, I was working on a project that initially I thought it would take me like two weeks to accomplish. It was like a small thing that I thought would be easy to do and turn out to be actually a lot more involved and a lot more complicated. And I felt like even if I finish it, which I almost did, I almost brought it to completion. Even if I finish it and launch it, everything's successful. It is still not an E7 level project.

You cannot still justify my level with that project being completed. Probably it's my fault in which projects I pick, you know, or how I underestimated the complexity of the thing. Because you're going back to Google, are you going back to an org where you have all the existing context and relationships and all of that? No, no, everything will be new to me, new people, new infrastructure, new everything. But at least I know, you know, I know how Google operates. I know the culture.

There are differences in cultures also between the companies. And I think that meta, also like in terms of internal culture, meta, I didn't feel like it fits me the best. What's the biggest cultural differences between Meta and Google? Meta tends to set up very ambitious goals. They give you, like, oftentimes they will give you a very arbitrary deadline saying like, okay, this project, you need to finish it within like, you know, by September. 15th, whatever, like one month from now.

And then everybody works hard, like, there is a lot of pressure. Like, you need to constantly send the updates to the leadership, how the project progresses. Comes the date, the deadline, the project is still unfinished and it just keeps dragging on. And so like what, and everybody is fine with that. Again, I don't know, I haven't seen all of Met. I've seen the specific work where I work. And it feels like, so then what was the purpose of setting this aggressive that line, right? Then, like, you know, are we, like, you know, you can do it once, but like, after five times going through this project, through this, like, artificial pressure with, like,

non-realistic goals, then people just say, like, okay, you know what? Five p.m. I'm going home. Like, I'm not, I'm not going to try to, to work hard because I know that there is, like, this, this whole pressure is artificial. Right. I think at Google is much. more reasonable in that regard. If there is a deadline, it's probably for good reasons and people would work hard, but usually they will not be pressure. Again, talking about Google, like, as of 10 years ago, I'm not sure that it's still true today, but you would be pressured to fix something or to accomplish something when there is really, you know, exceptional case for that. You wouldn't be pressure to work on the pressure for years.

Yeah, I mean, I get the sense that the industry as a whole is kind of becoming a little bit more intense when it comes to execution and deadlines. I've heard some people saying that Google as well has felt a little bit of pressure too, but hard to say. It depends on the org, I'm sure. Yeah, could be. And again, I didn't feel personally much pressure at Meta, but just talking to other folks, seeing how they work and operate.

As I said, there is this cultural thing where the leadership wants updates and everything, and then the people on the ground, they actually kind of dismiss it, essentially. It's like it almost feels like elementary school, like where the teacher is yelling, but kids are still playing. If you're yelling too much, it's like, it stops working. If you constantly put pressure on your people,

it just doesn't work anymore. So what do you do next? You start laying off people. Yeah, it might work to some degree, but again, people adjust to everything. That's crazy. You mentioned that when you reached out to Google too, you explicitly asked for kind of a demotion

or going back as a L6 when before you were in L7, was that a challenge or was that just a very straightforward process with the recruiter? It was a challenge for the recruiter to also make this happen because they have a process for bringing people in back at the same level or even like level up. They don't have a process for bringing people at a level down, but they made it possible for me. Again, I can totally see how a person comes back and says,

I want to be a level down. It's like there might be some red flags. There may be, you know, things that I'm not telling. You know, it's a gamble for a manager to hire a person like that. Also, just by giving me offer at the level down, they understand that it will be, they will not be able to match my compensation, you know, the previous place. So, so like, would they even accept it?

Right. And so I had to assure my recruiter that, yes, I'm happy to accept the offer at the lower compensation. Like, you know, a lot of people will not do something like I did because it's like a significant drop in compensation. You mentioned stuff that people might be hiding from the recruiter. What comes to mind when you mentioned that? I don't know, maybe you did something in the company that, you know, you like a fire bullet offense or something like, I don't know, like if you're a manager and somebody comes to you with like, you know, saying like, yeah, previously I was this level. Now I want to be level below. Please hire me. It does sound fissure. Like, why don't you like, what's wrong with you? Like, you know, there are so much. many companies out there, like, why would you come back to do this company? Like, why don't you try something else? I don't know what questions popped up in my hiring managers had when he saw this. Google's current process, do they do host matching? Or what was the, like,

did you meet up with the hiring manager beforehand or just through the recruiter? The recruiter sent me a few openings and asked me which one sound interesting. I spoke to a few hiring managers. One was sound like sounded like the best match for me and then I spoke to a few engineers on the team then I spoke to the manager's manager and that was it. Another nice thing for me is that they didn't require me to interview. Oh interesting but it had been like three years maybe? Over, yeah, three and a half years. So, yeah, they didn't ask me to re-interview.

Actually, that was another interesting thing that they said, like, if you're coming back as E7, you definitely don't need an interview because you were already L7. But if you're going to be like L6, then you might need to do a coding interview because who knows if you wrote code while you were out. That's kind of funny. Yeah, I got an exception from coding.

I see. That's funny. You got promoted out of competence in the lower levels. Yes, but it's understandable when people, like, go to higher levels, they write less code. And maybe they get rusty, who knows. It's kind of crazy that you could boomerang after it had been three years or more. Yeah, to be fair, I don't know if that's general Google's policy, or it was just a special case for me. I don't have any friends that did this recently to understand if they did it for anybody else. You mentioned earlier that a lot of people don't share this kind of stuff about emotions and these types of things. And I'm curious what makes you willing to share?

I'm a generally very open person. I like sharing my life experience is positive and negative with friends and, you know, yeah, I'm generally quite open. And also I'm quite confident. That's another thing. Like, you wouldn't share if you worried about your career, if you're worried about, you know, there are many things that can go wrong when you share stuff like this, right? So I'm very privileged, essentially. I don't need the work visa. So, I can live in this country without being attached to a certain employer. My spouse has health insurance. My kids are already grown up and off to college and I don't have mortgage on my house.

So, like, I can afford not to work for a few years. I can, you know, I don't. I'm fine with, like, let's say I said something in this chat, now and Google says we don't want you for some reason. I'm totally fine. I will just... So that's a position of privilege, right? Definitely.

I mean, you're free. Yeah, you're entirely free. You're your own person, which is awesome. Yeah, so that's a position of privilege that many other people wouldn't have. So if another person asked me, like, should I post about my challenges at work, I would be probably say no, unless you feel it's so safe and secure. And you mentioned that Google, you were asking for promos. You went from their lowest level up, and you were pushing and pushing for promos.

And that's a very different mindset from now, which you were kind of pushing for the motion. I'm curious, is there, did something major change that made you not motivated to go for promos anymore in your career. Essentially, if you are a senior engineer, right, of E5 or E4, you don't even know, like, what's the life of like two levels above you looks like. You probably, you can imagine what happens with like one level above you, but it's very hard to see like what does a principal engineer do? Like most people don't know.

And I don't know. By going through this, I realized that my happiest time was when I was working in a relatively small team, doing a lot of coding, debugging, designing, mentoring, more junior folks. That's where I felt the happiest. Let's say money is not a constraint at all. And it was just which engineering level has the best quality. of life, in your opinion. Which one would you say?

Senior engineer, like E5, L5. Yeah, that's probably missed pressure. You're still shielded by, you know, probably, like, if you're working on a team, you probably have an E.L who is E6 on the team, who, you know, sends all the updates to the upper levels, like, and shields the... the team from all this stuff, you have the management, also like the lower level managers who shield you from all this stuff. So you can just do the stuff that hopefully you enjoy what you're doing.

Like not everybody enjoys doing work. Like a lot of people do it just for money. But I personally, I was programming since I was 12 years old. So I really like this stuff. I got into this job because I love it. and it happens to pay well. But I would do it even if it wasn't paying well. A lot of people come to software engineering

just because that's the money thing. So then if it was as easy to do, would your ideal situation be two levels of the motion? That's too extreme. I think I can still enjoy being like E6 I quite comfortable with. And maybe I haven't been, E7 long enough to get comfortable in the role.

Maybe if I just kept doing it for some time longer, I would have started enjoying it. Yeah. Like, you know, one thing is like, was I really, like, you know, imposter syndrome is something that everybody has, regardless of what you'll ever list. I'm sure Elon Musk has imposter syndrome. So, you know, I'm questioning myself, like, was I really, you know, qualified to be E7?

And my answer is like partially, yes, but not fully. It's like a multi-dimensional thing. And in some dimensions, I probably was good. And in some dimensions was not as big. You mentioned working with other peer ICs that were also a really high level. Is there skills that you saw that they had, which would have closed the goal? got for you personally or something that you thought made them so strong? It's often a mistake to compare yourself against a group of people.

That's what gives you a lot of imposter syndrome, where you're saying, like, oh, those people around me, they're so smart. They are so good at talking. They're so good at doing presentations. They're so good at communicating. They're so good at leading. But it turns out that it's like one person is good at this. the other person is good at this, and you're comparing yourself against a team of people.

And so that's always, you need to be careful not to make that mistake. So, yeah, I think I, you know, given enough ramp up time, I would have been able to reach full productivity and being useful to the company at E7. I just felt like I was not enjoying the right, essentially. and I didn't have to. And I debated a lot before making the decision to leave. I was talking to friends, I was talking to family, and pretty much everybody was telling me, like, are you crazy?

Like, you're not laid off yet. Nobody showed you the door. Why would you do something crazy like that? And even if you're leaving, like, you don't enjoy it, why won't you try E7 elsewhere? Like, why do you need to go level down? There is a lot of peer pressure. And my answer to that was just like, yes, I can try that.

I can do that. But I don't want that. It's like, why I'm capable of running a marathon, but I don't like running a marathon. I don't like running. Why would I do that? You mentioned that you kind of rose through the ranks at Google. I'm kind of curious, what was the project that got you promoted to senior staff at Google? It was a project in ads.

Ads builds a lot of machine learning infrastructure because the ranking of ads is essentially a recommendation system. I was working on this machine learning infra and when I came to the team, they were doing training on CPUs, not on GPUs, but on CPUs. And TPU was a new thing, new hardware that Google was developed. developing, it was about to be released like maybe a year or two before, you know, when I joined the team. And my role was to make sure that this adds training infrastructure can run on those TPUs. And additionally, when you train machine learning models, the scale matters and the utilization matters, and there are lots of nuances that can like you know your model may be training but things go wrong

it's online training which is also like something that most people don't know like LLMs don't usually train in online training mode so there are lots of experience on the team like the whole infrastructure that existed there was in that team was built for this CPU training and it was polished over, I don't know, over 10 years. It was polished to be super reliable, super like you've well monitored, the unit tested. Everything is like very rigid, very polished, right? And here I am coming and building a completely new piece of infrastructure to run on TPUs. And it has to be as good as the old, you know, as polished as, as the one of the,

has tested and it's reliable. So it was a big project and, you know, it succeeded. Yeah, it's something to be, like, I was proud of what I built. So that got me promoted. What was the operating model of that project? Were you TL or were you kind of writing a lot of it yourself? Or how would you describe the execution? Yeah.

Initially, it was like a quite exploratory project. So it was just two people. I was the TL plus one person to building like a prototype. Plus a lot of people from other teams helping, like the QPU team, the compiler team, there are lots of other people who were helping us succeed. Like the TensorFlow team, we were writing TensorFlow back then. So it's also like where you need credibility. That's why knowing people and them knowing you is,

very important, like trusting you. If you don't have that, you cannot succeed. So it's a really cross-team collaboration, a very big project. And again, hardware like this, you need to decide how many of these chips you want to order, and they will be delivered like 18 months from now. And right now, you don't have any.

It's not like you can try out and see. And those chips are super expensive, right? So it's a very risky thing to do for the company. And yeah, it's like a lot of risk-taking, a lot of leadership skills that they needed for doing stuff like that. So you were on the, well, well, kind of the product team, not actually product, you were machine learning info for the ads, org and then all the underlying infrared teams were helping collaborate with you.

You mentioned compilers, maybe some training infra, other infrastructure teams. Yeah, and once the things started working a little bit, the team grew quite a bit more. A lot more people joined the effort and started working, polishing. And then again, like your first generation TPUs comes in, and then they already tell you, like we already designed the next generation who will be coming next year. So you're already rushing to adjust your infrastructure to the next thing. And that's like pretty much every year you're upgrading your infrastructure. How did you test the initial builds of this infrastructure if you didn't have the chips to begin with?

A lot of things were just about like input reading and processing, which you can do without having the chips. Like the difference between CPU training where you have the CPU and Intel CPU, they can do floating point arithmetic and integer arithmetic in parallel. So, and the floating point arithmetic is relatively slow. So input reading and processing was free on the same CPU. Going from that mode of operation to you have a relatively weak computer with eight TPU chips, each one of those TPU chips is like order of magnitude faster than the CPU that you had before. I have several orders. I think it's like two orders of magnitude faster.

Now there is no chance you can do the input reading on the host of those TPU, those TPUs. So you need to build the input processing pipelines and everything. But that's something you can test outside of, like without having TPUs. Actually, we did many times we did this test where people say next TPU will be like two times more performance than the previous one. And a nice test to test your infrastructure is to say like, okay, we will just remove all computation from our models. Just let's see how fast we can, you know, feed the data in, take the outputs out, and process this whole thing, like how fast your system can run if the CPU was infinitely fast. And that's a nice test to do, to see that, you know, you don't have bottlenecks. And you do find

a lot of bottlenecks all the time. Like things that previously were like, like, you know, thing that schedules which data to train on, it's, you know, previously was never like an issue, and then suddenly this is your bottleneck in this model. And many things like that. So if I'm understanding correctly, the TPU consumes data orders of magnitude faster than the CPU one. So everything around the processing unit, like the data loading and maybe, I don't know, the scheduling and all the other things that are around the TPU needed to be scaled and tested. And that's a lot of what you did to get promoted. Is that right? Yeah. Plus, you know, there are always like funn these things that you get where like certain

resources are more available than other resources. For example, so you, you know, you're training on some insane amount of data, petabytes of data. This data is stored on spinning disks because there is not enough SSDs in the world. So spinning disks, if you look at the history of spinning disks, they're getting bigger in terms of storage space,

but the speed at which they rotate is staying constant. And the speed at which the head moves is staying constant. So if I gave you previously, let's say we go back in year, 2010. A typical disk would be like maybe 200 gigabytes. And it has a certain throughput of how much it can read. Now fast forward to today is the typical disk is like 6 terabytes. So your data center has a lot of fewer disks to store the same amount of data. But this throughput is like an order of magnitude less. So and you can, and you can. coming to people responsible, like on building data centers, and you say, I need more disks, not for storage, I need more disks for throughput.

And you usually would hear an absurd thing that says, disks are very cheap. Like compared to everything else in the data center, super cheap, but you cannot get them. You know, you cannot easily go and buy like a few thousand disks and easily install them. Like, you need racks, you need power, you need, you know. It's similar to how, like, during COVID, we all ran out of toilet paper, right?

Like, the stores just couldn't, like, why would you run out of toilet paper? Right. It's just because it's bulky item that stores cannot easily store on the shelves. So that's roughly it. You mentioned having to predict 18 months out how many TPUs you'd need. And I'm curious, when you look back on that prediction of how many you needed, did you over-order or under-order? Usually under.

We try to be relatively conservative because your main goal is to make money. With LLMs, if you look at this current world of LLMs, they just order more like we want more gigawatts of data centers. They don't even really

none of this company is profitable with LLMs, right? They're losing money and they all fine with that. But when you have a your business like ads, you need to be making one day on that. So if you wasted, you know, if you're over-provisioned and this goes to waste, then it's not good. But then it constraints what kind of models you can train. Like also like models don't stay the same. So when you're saying 18 months from now, we'll not be training what we're training today. But you don't know

what you're going to be training. Like, you know, the attention mechanism wasn't in use 10 years ago, and suddenly it's needed. So your chip might not be even capable of doing that. So TPUs are quite specialized hardware. So they are not as generic as GPUs. And there were certain things that we had to work around a lot of times where certain functionality was very difficult to implement. Like what?

Embedding lookups in certain types of embeddings where essentially the chip is very good at doing matrix multiplication. And accessing memory by big chunks of memory. Embeddings are things where you need sparse access, like random access, essentially. And that's difficult to do in the chip. Yeah, one thing I want to ask, because you said you enjoy mentoring. others and I was curious, do you have favorite, maybe stories of mentorship or favorite advice that you like to give when you're mentoring other people? Well, I once had an intern on the team.

I was also not very senior back then. I was like L4 maybe. And I had an intern that I hosted. And then later that intern converted to full-timer. And a few years later, he became the manager of the team that he interned. That's funny. Were you reporting to him eventually? No, by the time I already switched projects, but don't underestimate your interns. They can be really, really good.

When you look back on your career, is there any regret that you have that some people could learn from or could help people avoid? Not everything was very smooth in my career, but I think it was still a learning experience. I wouldn't be who I am today if I didn't go through those periods of time. I was very idealistic when I was younger. I believe that Google is a really positive force in the world. It's really like, you know, I would work here just because it's Google, not because it pays more, like, you know. Not because of some, like, you know.

I really wanted to be in Google because of my personal values. and how the company operated. And then I got disillusioned over the years that, yes, it's just a corporate. Like maybe as of 17 years ago, it was really a more different company. But today it is a corporation, just like any other corporation. It has positive things. It has negative things. But what matters to the company at the end of the day is the bottom line on the financial reports.

and they will do whatever it takes to get there, to increase that number. Is there something that led to that disillusionment? Google had a lot of remote offices, for example. And I was working in the Pittsburgh office, which was a relatively remote office, and at the same time they shut down an office in Atlanta. and it was roughly the same size and it was quite shocking to everybody like why would you shut down an office

with a few hundred people working there and the answer we got from the leadership they said well we have those big senior vice presidents of the company who decide how to allocate the headcount and where to invest like you know I want to hire in Bay Area I want to hire in Seattle

I want to hire in this point And just as so happened that the big lead who was sponsoring that Atlanta office decided to pull out and nobody else was willing to take over the headcount of that office. So it was just like you feel like, yeah, at the end of the day, I'm just a cell in the spreadsheet. You know, it's like there was very little empathy that company showed to those people. They said, yeah, we can help you relocate if you want to other places. But if not, here, if you exit package, and good luck. And that was like many, many years ago, before all the layoffs that happened after COVID. You know, nowadays, people are much less.

It's much more understandable that the company can lay off anybody just because this project here doesn't make sense anymore. we'll just like shut it down and let people go. Like this is now a common scene. It was not the case as of 10 years ago. Yeah, I remember I think when Google was a lot earlier, it was don't be evil and the culture was very, very set on that. Yeah. I think they still like they're still trying not to be evil,

but again, the bottom line often drives, they overrides that decision. I guess it's true for all public companies. Yeah, and then the last question I'd like to ask is if you could go back to when you just entered the industry or you were working at Google and give yourself some advice knowing everything you know now. What would you say? I worked on some projects that didn't make sense to me. Essentially when I was especially when I was a more junior. Like I was working on some projects that like why are we building this in the first place?

Who needs this? And then a year later, the leadership realizes the same thing and they just shut down the project. So maybe work on what matters. Ask yourself, like, does my company really benefit from what I'm doing? And if not, then maybe you shouldn't be there. that situation, let's say you recognized it, and then your org's going in that direction, you think it's useless. But you're a junior engineer. What could you do to kind of adjust your direction? Talk to other managers. I find another project. There are different companies

have different treatment of people who want to switch projects. Before Google, I actually briefly worked at Intel. They're switching projects. was almost impossible. It's much easier to just quit and then reapply. Versus Google was very fluid. You could easily switch projects within Google. So this advice doesn't work for any company. I know some companies like IBM is another example I've heard where switching projects is impossible. Yeah, some companies have certain reputations. I don't know. I've never worked at IBM, so I don't know, but that's the reputation. Within Google, it was easy. to switch projects. It was in meta, I believe it's easy to switch projects. Yeah, I don't know

about other companies. Yeah, I think most modern-day or Silicon Valley companies are inspired by Google meta, those types of companies. So similar culture on team switches. So awesome. Well, yeah, thanks so much for your time, Igor. I really appreciate it. Yeah, thank you very much. And I hope somebody finds it useful. Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify if you want to drop a review. That'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior I sees. There's no well-studied list out there on Google that I can just search this up. So if there's

someone in your org or at your company who you really look up to and you want to hear their career story, Let me know and I'll reach out to them.