New Grad to Principal Engineer (IC8) at Meta (Career Story)

12 Jan 2026 · 56 min · 33 chapters

Ask about this episode

Ask anything about it. ChatGPT or Claude reads this page and answers with the times it was said.

Connect VO and ask about every podcast you hear, including the moments you saved. Add to ChatGPT · Add to Claude

In short

Adrien’s career story from Meta new grad to Principal Engineer (IC8), spanning early Facebook data science/A-B testing, building A-B testing at Instagram, creating Bento (Jupyter-based notebook platform), taking calculated performance/tooling risks, and later leading “experiences” across Meta smart glasses/Ray-Ban Stories to deliver device milestones.

Guests

None. The episode is a single-speaker career story by Adrien (interview format, but no other guest is identified).

Guest background

Adrien has a PhD and worked at Meta/Facebook across multiple eras: early data science team (A/B testing platform, measurement pipelines), rumor-spread research affecting Newsfeed reshare weighting; later helped Instagram Explore personalization and implemented server-side A/B testing by integrating with Facebook’s A/B infrastructure; then built tooling libraries and Bento; later worked on Clubhouse data/ML systems; returned to Meta for Ray-Ban Stories experiences and achieved IC8.

Key claims

Software engineers “have power” at Meta; promotions require both impact and consensus; risk-taking works when aligned with managers and over-communicated; adoption can be driven by onboarding/network effects plus supporting legacy users.

Notable examples

false rumors spreading faster than true ones; adding custom Facebook API endpoints to log Instagram exposures and hashing users into buckets; Bento reducing pipeline setup from ~300 lines to ~20 and targeting Datacamp/Bootcamp for rollout.

Written by AI. May contain mistakes. Listen to the episode to check what was said.

Chapters

Tap a time to open that second in VO

Navigating Early Career Decisions

0:45 to 2:42

Adrien discusses his initial career decisions and the importance of impact and consensus.

“I joined what was then called the data science team, which you and I have talked about a little, is a little confusing because what we call data scientists nowadays is very different from what was data science then.”

The Early Data Science Team

2:42 to 4:48

Insights on Adrien's experience on the early data science team at Meta and its evolution.

“Software engineers create the products, obviously in partnership with PMs and designers and all that.”

The Shift from Data Science to Product Analytics

4:48 to 8:02

Exploration of the transition from traditional data science roles to product analytics at Meta.

“Yeah, there was just another example of the stuff we did at the time.”

Analyzing Rumors on Social Networks

8:02 to 11:15

Discussion on the research conducted by Adrien on how rumors spread in social networks.

“There were a few people starting to help on the data side.”

Building A-B Testing at Instagram

11:15 to 12:18

Adrien shares the story of implementing A-B testing systems at Instagram and its challenges.

“So I could connect that to the backend deltoid of our AB testing system.”

Career Growth Through Initiative

12:18 to 14:01

Reflecting on how taking initiative led to Adrien's promotion and career development.

“I picked that because I needed it for this other thing I wanted to build.”

Cultural Differences at Instagram vs. Facebook

14:01 to 15:01

Explore the cultural contrasts between Instagram and Facebook during the early days.

“I'm going to try and figure out how do I achieve the thing I want to achieve.”

Reflections on Career Decisions

15:01 to 16:14

Discuss the impact of career choices, particularly the decision not to join Instagram.

“And there was such a big focus on design and craft over data that was very different.”

Building Data Pipelines and Tools

16:14 to 17:55

Learn about the challenges faced in data processing and the development of new tools.

“And I'm also very happy with where I'm at in my career.”

Developing the Bento Notebook Platform

17:55 to 20:01

Discover the journey and vision behind creating the Bento platform for data scientists.

“the same boilerplate over and over again?”
Show all 33 chapters

Strategies for Adoption of New Tools

20:01 to 24:10

Understand the methods used to encourage the adoption of Bento within Facebook.

“And at first, Bento was really, really dumb.”

Taking Risks in Tech Development

24:10 to 27:55

Gain insights on managing risks while pursuing innovative projects in tech.

“And then the other thing we did too was go to Alex Schultz, who's now the CMO of the company, but I was head of analytics at the time and Brady Laubach.”

Transitioning to Management: A Natural Evolution

28:00 to 29:04

Learn about the speaker's unexpected transition from tech lead to manager.

“You mentioned that you transitioned to a TLM during this leg of your career as well.”

Leaving Meta to Explore Entrepreneurship

29:04 to 29:59

Discover the motivations and realizations behind leaving Meta for a startup.

“Meta with desire to start your own company.”

A Sabbatical Instead of a Startup

29:59 to 30:35

Uncover the unexpected outcomes of taking a break instead of starting a company.

“And then I realized that I'm not an entrepreneur or I wasn't at the time.”

Skill Gaps: From Tech Lead to Entrepreneur

30:35 to 31:36

Explore the differences in skills needed between being a tech lead and an entrepreneur.

“I found other people to work with with whom we had different ideas.”

Returning to Meta: The Boomerang Effect

31:36 to 32:54

Hear about the speaker's decision to return to Meta and the changes made.

“And I don't know, on a whim, I decided to buy a house in Denver.”

Joining Clubhouse: A Wild Ride

32:54 to 33:56

Learn about the experiences and challenges faced while working at Clubhouse.

“in the summer of 2020, spent about seven months working on data infrastructure, kind of related to the stuff I had done before.”

Building Clubhouse's Data Infrastructure

33:56 to 35:09

Discover insights on building data systems and analytics at Clubhouse.

“I joined the company to help with the data stack.”

The Second Boomerang to Meta

35:09 to 36:37

Explore the reasons behind the speaker's return to Meta after Clubhouse.

“I guess I had like unfinished business at Meta.”

Working on Ray-Ban Stories at Meta

36:37 to 38:25

Understand the journey of working on the Ray-Ban Story project and its implications.

“You know, I came back to the company as an IC7.”

Growing Pains in a New Domain

38:25 to 39:48

Discuss the challenges faced while transitioning into hardware development.

“the user experiences on this specific device were good.”

Advice for Ramping Up in New Domains

39:48 to 40:53

Get actionable strategies for successfully adapting to new work environments.

“I use the, you know, the boss strategy of doing the social network exploration thing first.”

The Journey to Principal Engineer Promotion

40:53 to 42:00

Learn the story behind achieving a principal engineer promotion at Meta.

“And like, you know, however many engineering teams are working with that.”

Understanding Promotion Pathways

42:00 to 42:40

Learn about the intricacies of navigating promotions in a tech career.

“My responsibility was very specifically on the experiences we were shipping.”

Building Consensus for Promotions

42:40 to 43:40

Discover how to gain support from leadership for career advancement.

“IC6, I had to like talk to my manager and be like, okay, do you think we can put me out for promo?”

The Role of Social Capital in Promotions

43:40 to 44:30

Understand the balance between networking and technical competence in promotions.

“And so I went to him and I was like, you carry a lot of weight in this organization.”

Carving Out Your Role

44:30 to 45:50

Explore the importance of initiative in defining your professional scope.

“Like you need to have the underlying work too.”

Collaboration and Trust Building

45:50 to 48:10

Examine how collaboration fosters growth and opportunity in tech roles.

“When it comes to that first type where there's a limited role and there's probably other people who would like to have that role.”

The Importance of Versatility in Engineering

48:10 to 50:40

Learn how a well-rounded skill set enhances career opportunities.

“So again, I, and this is a constant across everything I've been talking about over communicate.”

Maximizing Opportunities Through Relationships

50:40 to 54:20

Get insights on building relationships to unlock career opportunities.

“But having the ability to do that type of stuff means that you can start a conversation with people.”

Key Advice for New Graduates

54:20 to 54:40

Adrian highlights the critical advice for early career success.

“The more shots you take, the more likely you are for one to land.”

Seeking Career Stories from Senior ICs

56:00 to 56:17

Listeners are encouraged to share names of senior ICs for career insights.

“want to bring on to, please let me know.”
Hear the part that matters, and keep it.Open this episode in VO. Double tap your headphones to save a moment as you listen.
Get VO free

Transcript

Automatic transcript. May contain errors.

0:00Software engineers have power at this company. This is Adrien. He grew from a new grad to a principal engineer at Meta and shared the story of how his career grew. The first thing I did was like, hey manager, I'm not going to do what my job is and what the team is doing because I think there's an opportunity there. What's your biggest learning from the principal engineer promotion? You need to have like the impact in the underlying work, but then it is also way easier to like build the consensus ahead of time. The advice he gave could help any tech career. How do you maximize your luck when it comes to people opportunity?

0:34Oh, so many thoughts. The first one is, you know, like I... Here's his full career story.

0:43Can you tell me a little bit about the first team that you joined and why you picked it? So I was actually pre-allocated. I joined what was then called the data science team, which you and I have talked about a little, is a little confusing because what we call data scientists nowadays is very different from what was data science then. In early 2011-12, there was this emergence of big data. And, you know, mainly at LinkedIn and Facebook, teams of statisticians and computer scientists and early machine learning researchers leveraging a lot of data to build better products. So that was like the very early days of doing A-B testing and doing A-B testing at scale, doing measurement and proper measurement of things.

1:31And so that was that team. I was pre-allocated to that team because I had a PhD. I was working on social network analysis. So I was joining this small team of 20 or so people for the people who know the Facebook stack. That team had been behind the whole A-B testing platform for the company, had been behind a lot of all of the data pipelines that are being used to measure and count everything. We would often joke that, you know, at the end of the day, we were just doing big counting. And so I was pre-allocated to the data science team. Did you see yourself more as a data scientist at the time or a software engineer?

2:10You know, it's very funny. I have this very distinct memory of a conversation, my first one-on-one I had with my manager, Cameron Marlowe, who was managing the data science team at the time. we were standing in line about to have lunch. And I was kind of, I don't know, I was kind of a little pretentious. I was like, you know, I have a PhD. I'm not like, I'm not a software engineer. And he was like, hey, software engineers have power at this company. You are a software engineer. Don't pigeonhole yourself into like a category or an area that is not like the most important job at the company. You are a software engineer.

2:48Software engineers create the products, obviously in partnership with PMs and designers and all that. But software engineering carries a lot of weight. And yeah, since then, I've always considered myself a software engineer. That is my primary job. My title has always been software engineer or my official workday title. I think I was a research scientist for a while in the outwardly displayed things. I was a data scientist for a while, but no, always a software engineer. And then, like I mentioned to you, around 2014 or so, the role of product analytics got renamed to data scientists across the company.

3:25So all of a sudden we moved from having, you know, 20 data scientists or 30 data scientists, all with PhDs doing data analysis, doing software engineering and stats to having, you know, 500 or so data scientists doing mostly product analytics, which was kind of like a crisis and identity in the team I was on at the time. But, you know, we moved on. Like at the end of the day, the title was not the important part. The important part was the impact of the work we were doing. Can you explain the difference between the product analytics and the old data science function? I'm curious what are things that an old data scientist would do that a data scientist today would not be expected to do?

4:07Well, one, that was like when we were building, you know, Deltoid and like all of those A-B testing tools. Nowadays, data scientists were like are mostly users of those tools. They're not the one who have like defined the algorithm or the sampling strategy or the double bootstrap or the sorry, the bootstrapping that you're using to like compare test groups and whatnot. So it was a lot of people like Dean Echols and Eitan Bakshi, really amazing statisticians who were building those tools that are now powering the company. So there were the tool builders more than the tool users. And those tools allowed the data science function to scale, that people without that deep statistical understanding could go into a tool and understand data much more easily than someone in the past.

5:00Yeah, there was just another example of the stuff we did at the time. I worked on how rumors spread on social network. That was like my very first project at the company. I worked with amazing researchers, Lada Adomich. She was eventually my manager and a director of data science at the company. But her background was like as an academic doing research on social networks. And so with her and Alex Dow and a few others, we spent the first six months I was at the company analyzing how rumors spread on social network. Now, by rumors, I really want to be specific here. Like I'm not talking about fake news, which is a slightly different flavor.

5:40I'm talking about rumors, mostly memes and, you know, the type of stuff that end up on, say, Snopes. And the stuff we were looking at was the shape of those cascades. How do they spread? Do they tend to like, you know, spread mostly in long chains? Do they tend to fan out? And it's really dependent on a few things. And there were like fascinating results we found. We found that like false rumors have a tendency to spread faster than true rumors. And even if you point out that a rumor is false, that doesn't really limit its spread. So that was the type of work we were doing. Until, you know, like I spent about six, eight months doing that, published maybe two or three papers.

6:20I think the impact we had on the company was affecting the weight of reshares in Newsfeed. We were like, hey, if we continue doing too many reshares, we're going to lose organic content. But that was the impact. So my manager at the time was like, you wrote three papers, help tweak Newsfeed. Meets all. Go figure out something impactful for the company. It's super interesting, the false rumors spreading faster than true ones. I mean, it matches intuition. If something's wrong, people are more likely to then reshare because they'll say this is wrong, which then some percentage of people agree with it will share it because it's right.

7:02Another polarizing set of people will share it again and say this is wrong. I think it's more that false rumors tend to be more egregious. And because they're more egregious, they are inherently more shareable or more viral. Like true things tend to be more boring than false things on average. I want to go into your first promotion story, kind of getting to the senior engineering level. Can you talk about the story behind doing that at Instagram? Yeah. So, you know, after like this rumor work, I was very lucky to just meet Mike Krieger, who was, you know, co-founder and CTO at Instagram. Instagram had been acquired in September of 2012.

7:47It was a very small team at the time. I started talking to them in like early 2013-ish. And the team was still relatively small. Like the core Instagram team at the time was probably 30 people. And then there were like a lot of like Facebook people around helping on the safety side. There were a few people starting to help on the data side. Just to give an idea of like the maturity at the time, this is when the very first data pipelines to count how many users on Instagram were created. And I was like, hey, this is like a cool product. So, you know, this little photo social network that we've acquired.

8:24They don't really do anything with data. There's no personalization. There's an opportunity to do something cool here. And so the first thing I started helping with was the Explore tab. The Explore tab, you know, circa 2012, 2013, was basically the most popular content on Instagram. And with a few others, we decided to add a little bit of personalization to that and surface, you know, popular content from your friend. content you might be interested in. And so we did that. We started building, you know, like a bunch of like different sources. And then there was this question of like, well, how do we know if it's good or not?

9:00Now, obviously, it's probably going to be better than only having popular content on the platform. But there was a desire to like understand the impact of what we're doing. And similarly, I was also like helping out with some people looking at growth and user acquisition. And you're like, can we plug into Facebook and like deep link you went to Instagram or like promote Instagram within Facebook, how do we measure conversions here? Instagram didn't have any A-B testing system. So, you know, as an old IC4, I was like, you know what? I think Instagram needs A-B testing. So I talked to like a few PMs and I talked to Krieger and Kevin Systrom.

9:35And everyone was like, yeah, you know, we have like bigger fish to fry right now. Instagram was in the midst of what we're calling instagration, which was migrating Instagram from AWS where it was running to the Facebook infra for cost and all of that. And so they were like, yeah, you know, like, you're a little A-B testing ideas. Good. We'll come to that later. But like, we have like really important things we need to do now. So please don't bug us. And I was like, I don't know. Let me try and see if I can build that. And so I roped a PM, Jeff Cantor, to get, you know, air cover on what I was doing.

10:13And I just kind of hacked something together. Now, Facebook had an A-B testing system. So I was like, I want to reuse this as much as possible. But like I said, Instagram was running in a different infrastructure. So how can you plug those things and connect them together? I did the dumbest, hackiest, probably very expensive thing I could do, which was add a custom Facebook API endpoint that was allowed listed on the Instagram app ID, which was essentially log those things. And so that way you could like log all exposures over the internet, sending that from AWS using the Facebook API. Now you're logging your exposures.

10:53So that's like half of the problem is solved. The other half is like, how do you hash users into the right groups? That was like, you know, 50, 100 lines of code. So replicated that on the Instagram side. And at that point, I just had a system to hash users into buckets, log exposures. and we already had some like data in our data warehouse. So I could connect that to the backend deltoid of our AB testing system. So I had all the different pieces. So at that point I was like, okay, I can kind of like run some like web experiments. Unfortunately, we don't have a website or it was like very early days of the Instagram website.

11:32So I think the first thing I did was like a server side AA test to prove that it worked. And then I found like a mobile engineer who was willing to, you know, help me with like the iOS code and with the Android code. And then we started running like one, two small experiments, like very small things just to prove that like the system worked and that it was scaling. And it did. So that's the story of like how we brought A-B testing to Instagram. Now, obviously, after Instagram, all that, all of everything has been like probably written four or five times since then. But that was the story behind my promotion.

12:06I built that thing. By the way, I had no idea that promotions existed at that point. I was like a little IC4 who was completely naive, was just working on things because I was excited about them. I didn't pick that because I thought it would be successful. I picked that because I needed it for this other thing I wanted to build. Come PSE season, at the end of the year, my manager was like, congratulations, we're promoting you to IC5. I'm like, what does that even mean? What is an IC5? uh yeah and then i transitioned that a b testing system to this newly created datagram team which went on to own and maintain that interesting i i can already tell in your early career story there are examples of unusual agency in chasing things down i mean sounds like no one told you to build this and you have a few examples in that story if you went up to random people like the CTO of Instagram.

13:03You went up to a mobile engineer and you said, hey, can you, you want to join in on this initiative? It sounds like that's pretty standout that you had that behavior so early in your career. I never really thought about that this way. It was just, I think the early days of Facebook were very, very bottoms up. Everyone kind of operated like that, or at least that's how I understood the world, right? You need to do something and you can't do it yourself. So you try and find someone to help you with it. You know, the early days of Facebook, I mean, obviously, we still have hackathons nowadays, but there was such a big hackathon culture.

13:39In the first six months, I think I probably did six hackathons once a month. Every like on a Thursday evening, you would spend the entire night in the office with other people hacking on something that was not related to your day job. And that that to me was the culture of Facebook. And so naturally, when it came to my day job, it's like, of course, I'm going to hack on something. Of course, I'm going to try and figure out how do I achieve the thing I want to achieve. Were there cultural differences between the early Instagram team and Facebook at the time? So I never officially joined the Instagram team.

14:14So on the data science team, we were kind of operating as consultants helping different teams around the company. And so, you know, we would do like six months, two year stints embedded in a team, but my reporting chain never changed. I was very lucky to have few managers. I know that a lot of folks have changed managers every six months. I think in my first two, three years at the company, I had two managers, despite working on very different teams. Not joining Instagram, by the way, officially, is probably one of the biggest mistakes I've made in my career. Not to say I have any regrets. This is more the flavor of like, I didn't buy a bunch of Bitcoin in 2013 type of regret.

14:57but I think my career would have been very different if I decided to join instead of like move on to something else in terms of culture Instagram was like it really felt like a very small startup within a startup you know Facebook was like 2 ,000 ish employees Instagram like the whole core team everyone working on Instagram we all fit in one big conference room it was like 30, 40 people. And there was such a big focus on design and craft over data that was very different. But other than that, it was to me like that same like energy of like just creating stuff. When you say it was the biggest mistake that you've ever made in your career, what do you mean by that?

15:39And where do you think your career would have been if you joined Instagram? That is really hard to tell. I think my career growth would have been accelerated. it. I might have like reach certain levels faster if I had joined that team at the time. You know, if I look at the folks who were working with me in that space at that time, they went on to have really fantastic careers and, you know, hitting like IC sevens, IC eights, IC nines, IC tens way sooner than I have or probably ever will. Like I said, it's really hard to know what the counterfactual is. And I'm also very happy with where I'm at in my career.

16:18It's just, this is like a road not taken. You know, after that, I understand that you built some frameworks and you worked on some additional tooling that was highly leveraged at the company. Can you talk about the story behind your IC7 or senior staff promo? So like I said, you know, I was kind of like playing around like all those different projects, bringing data to like non-data teams. and I had my hits. And then in other cases, it didn't really pan out. So I got roped into this project to count the number of people using one of Facebook's property. I'm not gonna spend a lot of time talking about it, but in the process of doing that, that was around 2015 or so, we had to do a bunch of data processing.

17:00We had to do a bunch of machine learning and inference. And the tools we had were just icky. They didn't really work well. Like the developer experience was horrible. We would have to like, you know, work within like one data pipelining framework and then move to like another thing to do the machine learning and the inference and then go back and forth. And I was like, this is this is not fun. I'm like wasting so much time just going back and forth. So I started building this little library that essentially let you do data pipelining within the machine learning orchestration framework. And at first, that was just like me writing a bunch of helper scripts for myself because I didn't want to have to go back and forth.

17:38I didn't want to have like deal with landing code in two different code bases and like synchronizing all of that. I was like, I want my code to live in one thing, do all of my thing in this code base, and then I'll be happy. But in the process of doing that, I just started tinkering a little. And I was like, why is that whenever I need to write a data pipeline, I have to like write the same boilerplate over and over again? It's always the same thing. Why can't I set those things to be the defaults? And so I kind of whittled away a lot of the boilerplate that you had to write. And so I put together this library where if you were building a data pipeline in the machine learning orchestration framework, FB Learner Flow, what would take you, say, 300 lines of code in the canonical data pipelining system would probably take you 20 lines of code.

18:27You had this escape hatch to add all the configuration, but by default, it did the right thing. And at that point, I was hooked. I was like, I am building a thing that can make people's lives easier. Forget about this, like counting number of people on Facebook. Other people are going to figure that out. I want to help those people move faster. And so then I started looking at like other things where people were wasting time. And at the time, if you were a data scientist, like as a product analyst, if you were a machine learning engineer, the way you worked was by building or setting up your own tools.

19:01Half of the company was using Jupyter for notebooks. The other half of the company was using RStudio, which uses this statistical program language R. And the way you would set that up is you would look at one of 10 different wikis that were all outdated, and you would have to set that up either on a desk server or on your machine, a lot of manual steps. And I was like, that's kind of silly. We should just make it so everyone has a Jupyter instance running if they want, and they don't have to configure it. And so I just kind of started building that. I remember telling my manager, you know, it was probably February.

19:37I was like, hey, this is the beginning of the half. I'm going to take two, three months to just hack on this. And if it doesn't pan out come, you know, April, I'll just find another project to like save the half and like, you know, not get some meat most. And so I started hacking on this, roped in a couple more people, and we built what eventually became the very first version of Bento, which is the notebook platform based on Jupyter that's used all across the company. And at first, Bento was really, really dumb. It was just a script that would set up Jupyter for you. But we had this vision behind it.

20:10What if instead of just being this like external tool that you have to set up that doesn't communicate with anything at the company, we integrated that better within the rest of the tooling? What if you could just open a browser, type Bento, and now you have a notebook that's running and you already have the libraries that are built within the company that you can reuse instead of having to like figure out how to do that manually what if you could have like other programming languages eventually you know people start hacking hack into that and so over the course of about a year or so uh we started like putting the system together a big thing that i worked on it after that was building bento on demand where instead of having a dev server where we would set up the system for you you could just request an on-demand instance you could work on that and then release it because we're doing that for like development environment.

21:06And we're like, yeah, that makes a lot of sense. You don't have to maintain a dev server. And so in the process of doing that, I, you know, I helped lead the development of the platform. But more importantly, I put the team together. I transitioned into a tech lead manager role, started building a team. And the way I built the team was hiring people who were very excited about the tooling world. Actually, I just hired a bunch of people who were already building tooling. on the side in their spare time i was like hey do you want this to be your full-time job sounds like you like to do this thing it's super impactful do you want to do this full time uh and so you know i brought in like a bunch of like amazing people uh so good team like six seven eight people uh and so i got promoted to uh tlm2 mostly on my ic work and the vision i had for bento and tlm2 for people who are outside the company is equivalent to senior manager which is equivalent to senior staff engineer in the industry.

22:05And when you hear these great stories of new infrastructure or tooling that everyone takes for granted today, what I want to know is what is the step-by-step process on how you actually get the tooling from an idea to something that everyone is using? So for Bento, the notebook platform, the answer is we didn't really try to get adoption within within people's existing workflows. What I did was twofold. One, we targeted bootcamp and datacamp. So bootcamp and datacamp for non-Facebookers is where you, the thing you go through when you onboard the company. And we just went to datacamp and we told everyone who was working with data, this is the way you set up your developer environment.

22:52You just use this thing. Or you can also just like go do it manually if you want. But you can also just like type this one word and you have your developer environment. The company was growing like crazy at the time, right? And so when you have this like amount of insane growth and, you know, the company is going to say like double in size within like a year or two, you get your growth from like all of those newcomers who don't know the legacy systems. And then you get the stragglers because everyone else around them then use the new system. So that was like a lot of the growth strategy behind Bento.

23:27The other thing we did with Bento was provide support and maintenance for the legacy systems. And so, you know, we built trust with users that way. So if you were installing Jupyter by yourself, you could go to that group that was unmonitored before us. and we provide help and we provide support. And then over time, you know, after building that trust, we would start encouraging people and be like, yeah, you know, this like thing you want to do, I can give you a recipe that's going to take 25 steps to do that. Or we've actually built that in Bento. It doesn't really change your workflow. It'll just make your life easier.

24:04You'll move to that. So to summarize, you know, step one, find an easy way of getting a bunch of users because network effects work. step two for the people who are on the legacy systems just provide value to them that's super interesting because when i think of these developer offerings i just always assume that you're going to have to influence a group of people that is using something today to switch off of something in this particular case in a growing company there's this whole new user base is like all these people coming in they're they're deciding from a fresh slate and it sounds like your offering was a superior product in a sense.

24:43So it was a pretty easy sell. And then the other thing we did too was go to Alex Schultz, who's now the CMO of the company, but I was head of analytics at the time and Brady Laubach. And we just told them, hey, we know that there's a lot of pain within your teams. We want to help. We think that this is the first step. And I remember Brady saying, yeah, this is a good first step. There's like those 20 other things you need to go fix. I was like, okay, let's take it one step at a time. And let's start talking more. There was no team at the time really building tools for data science and machine learning.

25:21And so this is when I actually ended up leaving the core data science team. And I re-orged myself into the DevInfor organization to start that team really focused on data developer tools. At the beginning of the story, you mentioned you took on some performance system risk. You literally told your manager, hey, I'm going to take on and build something that has a lot of potential, but also it might flop entirely. And then we can scramble to figure out performance so that, you know, you don't get a below meets all rating. I'm curious because at that time, the industry was not as intense when it comes to churning out short term results.

26:01Do you think that trying to do something like that today would be more difficult? And do you have any advice on more generally how to take on risk to pursue these high rewards? I think the consequences of underperforming now are more drastic than they were 10 years ago, for sure. I think the strategies when you want to take risk is the same. Make sure you're on the same page with your hierarchy and your manager. At the end of the day, we are all evaluated based on our expectations. If you're not aligned on what is expected of you with your manager, then that is a problem. Now, you know, I was on a team whose job was to provide help with data, data consultant in a way, right?

Read the full transcript

26:46Now, the thing I was building was tooling and infrastructure, not at all data to consulting. So the first thing I did was like, hey, manager, I'm not going to do what my job is and what the team is doing, because I think there's an opportunity there. Are you okay with me doing this? Can we make it so, you know, we carve out two, three months for me to go explore that and make that part of my expectation. If it pans out, great. If it doesn't pan out, well, I was expected to go explore this. It was a calculated risk. We all agreed as a team, my manager, my skip, myself, that like that was a thing I was going to do.

27:21And at that point, you know, there's an agreement. This is the job you're going to do. Everyone is on the same page. I think it is a lot riskier to go and do your own thing. You know, you lock yourself in a room, do your thing for three months, show up and you're like, I did this thing. And then everyone's like, yeah, but no one knew that you were doing this thing. Over-communicate, I think, is really the strategy I would recommend. And also be ready to hear no. Like I was very lucky to have a manager that said, yeah, you know, I think that makes, it's risky, but it makes sense. Go do that. I've had, you know, instances later on in my career where I wanted to go do a thing and I building that consensus.

28:02And what I told was, no, don't do that. You mentioned that you transitioned to a TLM during this leg of your career as well. What was the thinking behind that transition? I was building the team, right? We were building this product. I knew we had to scale and we needed more people. And so then the question was, do I go hire someone to manage me and the rest of the team? Someone who might come in with a different vision for the team or a different strategy? Or do I try this management thing? And so to me, it was really driven by a desire to just take this little crew we had assembled and lead them or support them in building this product we wanted to build.

28:47So it was kind of like a natural evolution. It was not really a thought out, I want to be a manager. I'm going to transition into management and find a role like that. It was just I was tech leading a team. We needed more people. The team needed a manager. I ended up being the manager. So after you got this IC7 promotion, I understand that you left Meta with desire to start your own company. Yes. What was the thinking there and the story behind you leaving? How did that go? At that point, I had been at the company for about seven years. That was the only company I had ever worked at. You know, my professional experience before that was, like I said, doing a PhD, working in my own corner, seven years of Facebook and growing tremendously, learning a lot, but also not really knowing what happened in the outside world.

29:33And then I think there was also maybe a little bit of hubris. I was like, I built this like platform that's being used by at that point, 60 % of all people doing data at the company. I was like, I can go build that externally. You know, if Facebook needed this in 2018, the world is going to need that in like 2020 and I'm going to go build it. So I left and I thought I was going to do a startup. And then I realized that I'm not an entrepreneur or I wasn't at the time. You know, my change in the future, but at the time that was not who I was. I really enjoyed going deep into technical problems. And I think I had maybe underestimated the amount of work at the time needed for me to like build or rebuild by myself with like, you know, our team of like six had spent two years building on like a very mature infrastructure.

30:23I often joke that I left the company to do a startup and I ended up taking a sabbatical instead. It was wonderful to travel the world. I went to a lot of wonderful places, but I did not start a startup. I built a few prototypes. I found other people to work with with whom we had different ideas. Nothing really crystallized. What were the skill gaps between yourself at the time, successful tech lead and an entrepreneur? in order to be a successful entrepreneur, you need to be able to delegate the hard stuff, right? You scale yourself through others. And to me, at that point, it basically meant that whenever something became interesting, I would have to find someone else to do it.

31:10My involvement would have to be superficial. And so, you know, I could hack a prototype together, but like if I wanted to take it to the next step, I would probably need to find like some engineers to go work on that while I go like, you know, try and figure out how to get people to use the thing in the first place. And I wasn't really into that. So after the sabbatical, you boomerang back to Meta. What was your thinking behind going to Meta? So like I said, COVID happened. I was living in New York at the time. And I was stuck in my tiny apartment. And I don't know, on a whim, I decided to buy a house in Denver.

31:45So moved to Denver, bought the house, got a mortgage. And I was like, I need like a full-time stable job. I interviewed with a few places. I had a few offers. At the end of the day, the reason I came back to Facebook was James Pierce. James Pierce is a fantastic manager. He was a director of engineering. His claim to fame is, you know, he was the manager behind the open source program at Facebook in the early days. he worked on portal he worked on so many amazing things uh and i always looked up to him and so when it came time to find a new role i reached out to a few people in my network including james and he was like yeah i'll take you come work for me so i entered you know i interviewed i did a behavioral interview because i boomeranged uh and they're like yeah you're still you're still not crazy you can come back uh got a few other offers but like at the end of the day it was really the draw of working with, you know, a few people I really knew and respected.

32:46And then I understand that you went to Clubhouse after. Yeah, this is, yeah, after, you know, so this is the crazy thing. I came back to Facebook in the summer of 2020, spent about seven months working on data infrastructure, kind of related to the stuff I had done before. And then a buddy of mine just put me in touch with one of the co-founders of Clubhouse. And now, you know, if you remember Clubhouse like went crazy viral and crazy growth in like late 2020, early 2021. And I remember, you know, talking to them at first, not seriously, because I was like, I've just been back at Facebook for seven months.

33:24I can't leave now. But I talked to like the two founders and I was like, oh, this is exciting. Oh my God, Zuck is on Clubhouse. And like, there's all of those people. Like it was having a moment. And it was, you know, all the talk. And so, yeah, I decided to join Clubhouse. You know, when I joined Clubhouse, the company was like maybe 10, 11 people. Insane amount of hype around it. A lot of users. And yeah, it was a very interesting year I spent there. You have any interesting insights or stories that you'd like to share? I joined the company to help with the data stack. There was one person working on data when I joined, Kenny D 'Amica.

34:05who was starting to put together the analytics stack. There was no machine learning at Clubhouse. There was no feed ranking, or at least not machine learned feed ranking. Clubhouse was like spamming people with notifications. And so a lot of the work I did in the early days was just building a lot of those systems. Like I said, built A-B testing for Instagram, built A-B testing for Clubhouse, because we wanted to be able to measure the stuff we were building, introduced some machine learning to Clubhouse to filter out the notifications we were sending because it was very spammy. What was the internal culture like?

34:41The culture was just very hands-on. A lot of people were very, very eager, extremely talented pool of engineers. Clubhouse was like this interesting mix where I think, you know, a large fraction of the company was either former Coinbase or former Facebook, pretty much. Yeah, a lot of like very independent, self-driven, hungry engineers who just wanted to build a really, really cool, authentic social network. So after Clubhouse, you went back to Meta for a second boomerang. For a second boomerang. I guess I had like unfinished business at Meta. No, you know, when I decided to leave Clubhouse, I actually did a very thorough job search.

35:24I ended up talking to a lot of companies. I had an offer from Apple that I really considered. The reason I decided to go to Meta was twofold. one a manager, Vincent Hardy, who had been my manager in the past, whom I wanted to work with again. Vincent at the time was the manager, the engineering director behind Ray-Ban Stories. Ray-Ban Stories is this partnership, you know, the glasses between Meta and Ray-Ban. And I was like, I've never worked on a product. I've never worked on hardware. I have this connection who is working on that and he's willing to take a chance on me. I kind of want to see what that pivot would look like being, you know, not being the data guy anymore, but kind of like working on something else.

36:12Yeah. That was one thing I wanted to know, which was you were entrusted with this Uber TL role working on in a very different domain than, than your past experience. And so So it sounds like the key that got you that role was that you came through a referral through someone, a trusted past manager. No, not entirely. So I was not interested with like any Uber TL role from the get-go. You know, I came back to the company as an IC7. Ray-Ban Stories had been released in September of 2021. And after launch, there were quality issues. There were growth issues. and so when I came in what I was asked to do was like hey can you like look at our growth story like you know about data can you look at like the data stuff a little bit make sure like you know we're we're dotting our i's and crossing our t's and so I spent about eight months a year uh working with fantastic leaders and engineers and data people on ray-ban stories to understand like where were things breaking uh where did we need to invest more where do we need to measure more and that's how I built the trust with that organization so it's been about a year doing that and then there was a reorg at the end of 2022 we merged a bunch of organizations together and people started getting different roles and you know we moved people around and I told my manager at the time hey you know it's been fun to do this but the reason I joined smart classes in the first place was I wanted to work on smart classes I didn't want to be the data guy anymore there's this project, I would really, really like to work on that.

37:50I know I don't have experience in hardware and product, but like you've seen, you know, my track record of the last year, I've developed this like product sense. Can I go help with that? And he was like, yeah, you can, you can move on to that project and work on that. There was another engineer who was actually the Uber TL and BSTO for that entire program. And so I spent the next couple of years, essentially working on that engine, just kind of like gaining more scope over time. And I ended up, you know, kind of like supervising all experiences across this specific hardware line. I don't go into details because the product is not yet released.

38:25But my job was to make sure that like all of the experiences, the user experiences on this specific device were good. And so that meant working with a lot of different teams across smart glasses and eventually what became wearables towards the end to make sure like we were shipping the right set of user experiences. Were there any growing pains in switching into this new domain? I think there were a lot of growing pains in the organization as the organization was growing and maturing. And so naturally those kind of like rippled onto me. In the early days, I struggled a lot with working or the cadence around working with hardware.

39:09You know, I started working in 2022 on something that will be released at some point is currently not released. And so this like extremely long lead time and validation and putting things in the hand of users was kind of missing. But once I got to a point where at least there was like internal fish fooding and dog fooding within the company. And we started getting like some feedback and some signal that made things a little easier. Do you have any advice on how to ramp up successfully in like a completely different domain? I think it's the same thing as like ramping up at a new company or a different flavor of it.

39:48I use the, you know, the boss strategy of doing the social network exploration thing first. Talk to people, ask them who I should be talking to. Don't be afraid to ask dumb questions. Like you're the noob on the team. Like everyone knows that you don't know anything. I'd rather ask a really silly question now rather than six months from now, not know what we're talking about and try and get your hands dirty. It's a thing I've always tried to do. Check out the code. Even if you're not going to like work on like, I never officially worked on firmware, right? I did check out the code and I did make a few tweaks just to like get a feel for it get an understanding of it uh and then kind of like map things out this way and then i'd say the last thing i'd say is pick a hard problem to solve i learn a lot by doing uh and so you know this might not translate to other people but like i learn by doing so i pick a hard problem to solve where i have kind of like an idea of how to solve the thing and then i can fill in the blanks as i go and that's where i learn on this team this is where you got your IC8 promo or your principal engineer promo what I'm curious what's the story behind that promotion what is the scope that actually got you promoted well so in this case I was eventually responsible like I said for like all experiences on a device and so I was working across multiple orgs you know dozens of teams I think at some point like the the set of PMs I was interacting with was probably like 35 or so PMs.

41:22And like, you know, however many engineering teams are working with that. My job at that point became a lot of like coordination and just like overall architecture. And my responsibility was making sure that we were delivering on our milestones from an experiences perspective. The reason I say experiences and on the whole device, by the way, is that the way we were organized is there were teams working on the OS layer. And, you know, So I would like work a little bit with them and communicate requirements and like poke holes into their story. But there were partners. I was not responsible for like that part of the stack.

42:00My responsibility was very specifically on the experiences we were shipping. So if you think about, say, RayBan Meta, for example, which is a product that's in market, the experiences on that would be all of the AI on the device, all of the music listening, the photo capture, and then all of the companion app stuff. So you can imagine something like that for another device. So that was the scope. I can go into a little bit of details on how I actually got the promo because that one was a little bit more work. Like if I think about like my entire, you know, set of promotions from IC5 to IC8, IC5, I had no idea that promo was a thing.

42:42It was kind of like a surprise. IC6, I had to like talk to my manager and be like, okay, do you think we can put me out for promo? And my manager was like, yeah, okay, yeah, I think you're ready. And it went through. IC7, it took a couple of cycles where we'd like to like do a few revs. IC8, I went to my manager and my manager at the time had never done an IC8 promo. And we're like, okay, so how do we do this? We partnered on writing the promo packet together. I wrote a substantial amount of the promo packet, obviously with his help. And then building consensus within the organization, going to multiple VPs early on and be like, Like, you know, this is the work that I've been doing.

43:30Do you see the ICA scope here? Would you be supportive of the promotion? And like building that consensus and seeking that mentorship in some cases, you know, there was a D2 in the organization who I knew would be absolutely critical in me getting this promotion. And so I went to him and I was like, you carry a lot of weight in this organization. I'd love to understand how I can make it to that level. Would you mind just having like a, you know, monthly conversation with me, just checking in and helping me course correct. And so six months later, when I went up for promo, he was supportive because he had been involved in the process the whole time.

44:07So identifying who the champions are is even more important for the highest level promotions and working with them to kind of understand what your gaps are so that when it comes time for that discussion, it's just a matter of logistics, but everyone is already aligned prior to that room. Yes. Now, to be clear, I don't want to make it sound like getting promoted is just a social game. Like you need to have the underlying work too. But you need to have both of those things. You need to have like the impact in the underlying work. But then it is also way easier, at least in my experience, to like build a consensus ahead of time.

44:46So that when you go to a, you know, performance calibration session, you don't have to, you don't have a debate in the room. Uh, and so for my I see a promo, it took two cycles. Like the first one, we started socializing. My manager even didn't even put me up for promo officially. And in that cycle, he just talked to people around and be like, you know, just feeling the water. And then in the following half, people had that context. They're like, oh, we're having this conversation. This is going to happen eventually. Uh, let's see what's missing, what we can do this half. and then obviously then you know with the amount of work i did in that half and the impact i had and that support and mentorship that's how i ended up getting it when it comes to the scope and the role that got you promoted it is it's a role that it it requires permission from from those around you to have that role you know there's there's only one uber tech lead on i mean you know relatively.

45:44There's one of that role available. It's not like you, kind of like your bento story, you created a role without permission from others and you kind of built it up into something. When it comes to that first type where there's a limited role and there's probably other people who would like to have that role. Do you have any advice on how to secure that scope for yourself or go towards that if that's something you're interested in? So funnily enough, that's not exactly the case. Because in this case, there was an Uber TL for this entire program. And he's a fantastic engineer, Jin Sung Yu. I just identified that there was a lot of work on experiences, specifically on the experiences side, working with product and design that I could help with, where, you know, he could focus on like the broader program, and I could just like narrowly tackle that area.

46:40Yeah. And so, you know, over time, he and I built this trust where I just started focusing on that. And I started taking that off his plate. He didn't have to worry too much about it. Instead of having to coordinate with like 10 or 12 different engineering teams on experiences specifically, he could just go through me. The system stuff, everything else he would do himself. But I ran a very tight chip on experiences. And so I made his life easier. And so in a way, I kind of like took that role upon myself. Like there isn't really like an Uber TL for experiences on each product line. I just kind of like, you know, carve that out for myself within that specific program.

47:19Now, at some point, you know, I worked with my leadership and I was like, hey, I've been doing this thing. And people are asking, like, why is Adrian doing that? Do you mind if we just say that, like, I'm the TL on experiences that would make my life easier? but it became a post hoc thing. Once I was already doing the work and I had done the work for about a year at that point, I just asked to be blessed with a little label so that I could explain who I was in a sentence as opposed to, I'm just this engineer who's touching all of the experiences. And then the thing I really wanna make clear here is that I've heard a lot of engineers talking about scope as in stealing scope from other people.

48:02That is the wrong way to think about it. you know, taking something off someone's plate doesn't mean that you're stealing from them, or it is if you're not talking to them about it. So again, I, and this is a constant across everything I've been talking about over communicate. I went to that engineer, I was like, hey, I am very excited about this space. Do you mind if I like help with this? And he's like, yeah, sure. I, you know, I'm swamped. If you want to take that on, take it on. And then, you know, I come back a few weeks later and say, hey, there's this other kind of like related thing. uh is it okay if i talk to them he's like yeah sure knock yourself out and like you know in the process then he can go and like explore other things uh and broaden his own scope yeah in my mind it's it's a win-win for for him because i mean i imagine you helped him scale himself so he can you know chase some other scope maybe he's going for ic9 or something like that and he has evidence that he grew someone to ic8 or helped i don't know if that was the case in this this example, but oftentimes TLs are gracious to give scope so that they can move on to bigger things and help you grow into their role.

49:10And similarly, I've done that, you know, with like more junior engineers where I had to actually fight with more junior engineers and tell them, Hey, can you, can you actually take that and like, just own it? Uh, like it's going to be good for you. I also would love to like be able to delegate that to someone. So coming to the end of your career story, I wanted to do some reflecting across some of the things that I saw. One thing I wanted to ask was, you have a unique skill set that is very software engineering heavy and also very data heavy from your past experience. And I'm curious, what unique career experiences were only possible through that lens?

49:50I think all of them. I think I've always tried to be a well-rounded engineer. And, you know, in addition to software engineering and like data, I think I've always tried to like develop a strong product sense and a strong design sense. At Facebook, we have like those archetypes once you reach senior staff and principal, and I've always been a product hybrid. And to me, like this, like well-roundedness is where I can add value, being able to both, you know, have like a deep product conversation with product management leaders and the next day go down and like debug some like firmware code. Uh, like being a well-rounded person, I think is one of the things that, uh, I've always taken pride in.

50:42Uh, Robert Heinlein has this quote, uh, where he says like a competent man should be able to like do all of those things, uh you know write a sonnet die calently and whatnot and he finishes and says specialization is for insects uh and it's it's one of the things that like i've always taken to heart i i love learning and i want to try and be good at a lot of different things uh and then you know bring this like panel of things to the table and so when i was working uh in wearables you know i would like build little prototypes uh you know like design my own little circuit boards and like hack things together.

51:21Obviously, not production ready. I'm not a hardware engineer. But having the ability to do that type of stuff means that you can start a conversation with people. You can go and talk to a product lead and be like, hey, I have this idea. Here's the thing you can play with. One thing you said, and this is evident to me throughout your career, you said something that your career is a series of bumping into the right people. You mentioned a quote like that. And throughout each leg of your story, there tends to be someone who either brought you along or was instrumental in one of the projects that got you promoted.

51:58I'm curious, do you have any tips on how to, I guess, maximize your luck when it comes to people opportunity? Oh, so many thoughts. The first one is, you know, like I've been talking a lot about myself for the last like hour now. None of the stuff I've done would have been possible if I was working in a vacuum. Like everything I've done has been, you know, working on a team, convincing people, getting people to, you know, go in bad for me. Like some younger software engineers, I had rough edges when I was earlier on in my career. I had like very strong opinions about things and that didn't always work out in my favor.

52:35And so I learned very quickly that, you know, we're all in this to succeed. And the best way to succeed is to help others succeed. Not to want anything in return, but just, you know, fostering success around you, right? A rising tide lifts all boats. And that's the thing that I've been trying to do in my career probably for the last decade or so. You know, the first like two, three years of my career, I was maybe a little selfish. And then I started realizing, hey, we can all succeed together. And so when you build that trust, and I'm not saying I'm going to be friends with all of my coworkers.

53:12When you have relationships of trust and respect with people, that is a really good way of making sure eventually, if you have a need, that person is going to be there for you. Like you don't do that in order for them to be there for you. You just, you are a good person. You are a trustworthy person. You build trust and then you will reap the benefits of being a good person. Eventually. That's one thing to don't be afraid to ask every career change I've made. I have never applied for any job on a website. I have always reached out to someone I know. Once you build this relationship of trust with people and you, you know, you're comfortable asking them and be like, hey, there's no pressure.

53:56You can say no if you don't want to, but would you mind just giving me, like doing me a little favor? So don't be a dick, essentially. You know, build trustworthy relationship with people. Don't be afraid to ask, but also don't be afraid to hear no or not hear back from people. People are busy. That's fine. The way you maximize your luck is you maximize, I was reading something the other day about like the surface area for luck. Take more shots. The more shots you take, the more likely you are for one to land. And then the last question I'd like to ask you is if you could go back to yourself when you just graduated college in France and give yourself some advice knowing what you know today, what would you say?

54:37Be a good person. Invest in things that are fun. Invest in your relationship with your coworkers. It doesn't really matter at the end of the day who gets the credit. everyone is going to get credit for something i think early on in my career i was very credit driven be patient you know i think there were a few times in my career where i was pushing for a promo or when i wasn't ready uh my c7 like i said took like a couple of halves to go through and stay curious and mostly just like enjoy it uh you're gonna have an amazing adventure Awesome. Well, thanks so much for sharing your career story with us, Adrian.

55:17And now if you want to share with the audience where people could find you, maybe they can go and I'll put it in the show notes. Sure. At this point, I'm mostly just active on LinkedIn, so we can put my LinkedIn in there. And then, yeah, no plugs. I hope that the audience will get something out of this. Awesome. Thanks so much for sharing this with the community. Thank you so much for having me right. 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.

55:55If 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 ICs. 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.

From the publisher

Adrien Friggeri went from a new grad to a principal engineer (IC8) at Meta. He is the original TL who started Bento if you’re familiar with that infra at the company. He got to where he was through a series of promotions across different teams and projects. I interviewed him about everything he learned along the way


𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀:

• Transcript: https://www.developing.dev/p/new-grad-to-principal-engineer-ic8

• YouTube: https://youtu.be/2Sjzd9pt6Ts

• Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835


𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:


00:00 - Intro

00:43 - First team at FB

07:24 - Senior promo /w IG

16:30 - Story behind Bento (Senior staff promo)

25:33 - Taking on perf risk to start the project

29:03 - Learnings from leaving big tech

32:46 - Joining Clubhouse

35:08 - Return to Meta (again)

40:51 - Principal promo (IC8) and tips

51:37 - Maximizing your luck /w people

54:26 - Advice for younger self

55:42 - Outro


𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗔𝗱𝗿𝗶𝗲𝗻:


• LinkedIn: https://www.linkedin.com/in/friggeri/

• Instagram: https://www.instagram.com/adrien/

• Personal Website: https://friggeri.net/


𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:


• 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

More from The Peterman Pod

All 60 episodes
New Grad to Principal Engineer (IC8) at Meta (Career Story)The Peterman Pod · 56 min
Listen in VO