“The Coding Machine” at Meta with Michael Novati

What does a coding machine mean? It's very controversial because anyone can write a lot of code in theory. A junior engineer could sit down and just press the keyboard all day and write a lot of code. The zoomed out thing is impact. So what is the code doing?

You know, writing a lot of code all day long, but is it moving projects forward? Is it helping launch a product that might need a team of five to 10 engineers that just one engineer can do? Is it unblocking a lot of people by just pushing a lot of things forward? Is it refactoring?

a lot of code extremely quickly and fast so that new engineers don't even have to deal with old libraries. These are the type of examples that make a coding machine a coding machine. I'm still a coding machine to this day at Formation. I'm writing code all day long. I think I have 20 commits today. already. Oh, wow. And it's just the morning. Michael Novatti spent eight years working at Meta from 2009 to 2017, where in some years he was the number one co-committer across the whole company.

He started as an intern and in just six years was promoted four times, getting to the E7 level, which is the equivalent of principal engineer level at other tech companies. Michael is now the co-founder of Formation, our remote software engineering fellowship program. In today's episode, we go into...

What the coding machine archetype is as Meta for Stock Plus engineers and how Michael became the first ever coding machine at Facebook. Meta's engineering culture and why the company built so many custom internal tools. How the hiring committee works at Meta and how they make hiring decisions.

And a lot more advice for doing well on tech interviews and additional stories from Michael Simon Mehta. If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube. Michael, welcome to the podcast. Hi, I'm happy to be here. Thanks for inviting me. So let's start with something really surprising and interesting about you.

There's these things called archetypes. They're used for performance reviews and promotions, as I've learned when I researched the company, things like Fixer, TextLead. And there's something called the coding machine, which apparently came about. because of you. Can you talk about that? Yeah, sure. I can talk a little bit about the coding machine. So it's kind of back in maybe 2015 or so.

So in general about the archetypes, there's kind of two purposes for them at Meta. Overall, fairness is really important at Meta. So the archetypes are kind of these...

examples of what an engineer who's at the principal senior staff kind of level would look like. And the archetypes are modeled after existing engineers who are there. So they're kind of a way for... the company to kind of pattern match upcoming engineers against these existing engineers and try to have a fair system for who's at this level and who's not.

The reason why there's not just like one or two and there's a handful of them is that Meta kind of has this. They don't use this analogy a lot internally, but I've always found this a natural analogy is like the pro sports team. analogy when you have a professional sports team you have a bunch of baseball players say or basketball players and each person has a different position that they play

But all of those people at the pro level are pretty good. They're all quite good at every position. They can throw baseballs, throw basketballs, etc. But, you know, Steph Curry is the best three-point shooter. I think I don't know that much about basketball. And in the analogy of the archetypes, there's similarly people have specialties. So everyone, once you're at that level, you can do all the basic things engineers do.

you know, on a daily basis, but there becomes these different specialties where you're exceptional or one of the best in the company or even best in the industry at. So the coding machine is something that was, it was invented for me. And the kind of I won't go into all the history of like the back and forth of how it happened. But generally speaking, there wasn't really a an archetype for what I was doing at already. So this was kind of a case where they had to.

Sit down, compare me to people who are already at these E7 plus levels, zoom out and focusing on impact. That's like the. kind of word you'll hear a lot when you talk to Facebook people about performance reviews is impact. And they try to say they kind of notice that.

Overall, Michael is impacting the company very similarly to other E7s, but there isn't an archetype that he fits into. I'm not a specialist or... um a fixer is a really good example like i don't write one line of code to save 10 million dollars simple cut dry that's what a fixture is yeah um i have a friend who's a fixer and

You know, he writes a few lines of code a year and they are extremely impactful because he's spending most of his time talking to people and deep diving into these like really weird intersections of issues. And that's pretty easy to quantify. It's easy to understand the impact on the business. So some of those archetypes are a little easier. Now, with a coding machine, it's a little harder. It's very controversial because...

Anyone can write a lot of code in theory. A junior engineer could sit down and just press the keyboard all day and write a lot of code. So what does a coding machine mean to be at this level? The zoomed out thing is impact. So what is the code doing? You know, writing a lot of code all day long, but is it moving projects forward? Is it...

helping launch a product that might need a team of five to ten engineers that just one engineer can do? Is it unblocking a lot of people by just pushing a lot of things forward? is refactoring a lot of code extremely quickly and fast so that new engineers don't even have to deal with old libraries. examples that make a kind of a coding machine a coding machine. Now, how they kind of created this, there's maybe the story behind that. It's just a lot of back and forth.

an executive and who really, uh, sponsored me. Um, James Tom Allison. And I think that he's, I think he's head of Facebook quote unquote, the product now. Um, and, or the app they call it, I think. And yeah, he was really kind of championing me and working with the other VPs at the time to kind of connect the dots and make this happen.

um yeah and i'm still a coding machine to this day at formation i'm writing code all day long i think i have 20 commits today already um it's a busy day and it's just a morning yeah just this morning uh yeah so i you know it's kind of it's um i would say like in terms of going back to that that professional sports analogy um it's like that's kind of the thing that that's my thing that i'm the top one percent at on the professional sports team it's like we need to

move this new prototype forward insanely quickly, then I might be the go-to person. We need to refactor a lot of code really fast. I'm the one person you would go to in the whole company to talk to about doing that. And that's what kind of justified me being at that level.

Trust isn't just earned, it's demanded. Whether you're a startup founder navigating your first audit or seizing security professional skill in your governance, risk, and compliance program, proving your commitment to security has never been more critical or more complex.

That's where Vanta comes in. Vanta can help you start or scale your security program by connecting with auditors and experts to conduct your audit and set up your security program quickly. Plus, with automation and AI throughout the platform, Vanta gives your time back so you can focus on building your company. Businesses use Vanta to establish trust by automating compliance needs across over 35 frameworks like SOC 2 and ISO 27001. With Vanta, they centralize security workflows

complete questionnaires up to five times faster, and proactively manage vendor risk. Join over 9,000 global companies to manage risk and prove security in real time. For a limited time, my listeners get $1,000 off Vanta at vanta.com slash pragmatic. That is V-A-N-T-A dot com slash pragmatic for $1,000 off. This episode is brought to you by WorkOS.

If you're building a SaaS app, at some point your customers will start asking for enterprise features like SAML authentication, SKIM provisioning, and fine-grained authorization. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand and you can ship quickly and get back to building other features. Work OS also provides a free user management solution called AuthKit for up to 1 million monthly active users.

It's a drop-in replacement for Alt-0 and comes standard with useful features like domain verification, role-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. you get limited customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Vercel, and Perplexity. Check it out at workoos.com to learn more.

That is WorkOS.com. Do I understand correctly that A, this happened when you were at E7 level, which is a very senior level, I think equivalent of senior staff or principal engineer at companies that do have like... levels. And then B, can you give an example of what type of work you were doing at the time? Just give us an example of what your week-to-week looked like. Because you mentioned refactoring or doing impactful stuff.

Yeah. So the conversations start when you're at the E6 level, which is generally considered staff. You know, three is... Junior, four is mid-level, five is senior, six is staff, and then seven is senior staff. And getting three, four, five is kind of your more standard common traits between those levels. And at six, you start to think about what makes me a little different than others. You're participating at a higher level. And then that's when you have the conversation to get to seven.

I was a coding machine from day one unofficially. Like literally as an intern, the first thing I did on my second or third day was I just noticed that the org chart tool looked really... It was kind of a handmade tool at Facebook and looked really... Really janky. This internal tool where you can look up the org thing. I feel most companies have their own if they're not using something like Workday these days, but a lot of them build it, right?

And I don't know why. I mean, Facebook built all their own tools, so I guess I know why. But it was just kind of weird. It showed two levels. You had to do lots of scrolling. It was really weird. So I was like, I'm just going to rewrite this. And, you know, the vertical height was weird. So I just made it horizontal. So Mark Zuckerberg was on the left and his reports were to the right and their reports were vertically below them. So it's kind of like a horizontal layout.

And I just shipped this. I wrote it. My manager approved the PR. I was second, third day as an intern. Shipped it and didn't get permission or anything like that. Just drove it out the door. Didn't even really know what I was doing. doing socially or social norms-wise at the time. I just thought it was like, cool, let's do this. Let's crank out this code. And that was really well-received.

So you ship this on, I don't know, second or third day, same day landing, and then suddenly the internal tool that everyone at the company is using, it just completely changes the visual design? And people thought it was fantastic because... the horizontal nature which was kind of actually just a judgment call because the the page was too tall vertically like if it was a vertical layout it's just too much scrolling but people loved it because it kind of flattened the hierarchy it showed that

you know, anyone can have influence across at any level. And on a horizontal line, like an intern is at the same line as Mark Zuckerberg. So it was like, and people love this. And so it kind of reinforced this idea that like, wow, this. is just how things work here. I can write as much code as I want and ship it as fast as I want and we'll see what happens. And then there's lots of adventures after that. How big was the company?

20-ish, I'd say about 200 engineers and about 700 employees at the time. So relatively small, yeah. Still in downtown Palo Alto. Scattered across a couple offices, yeah. Sorry, that was a bit of a sidetrack. We were talking about what I did on a day-to-day basis, I think, as a coding machine. I called myself a product engineer.

officially allocated to a product team. I started off on internal tools, which is a product team at Meta. And then I worked on Facebook Groups and the first version of Facebook Workplace. I worked on News Feed. I worked on Facebook groups for schools and colleges. I worked on Messenger for kids. That was one of the last things I worked on. So I was always on a product team.

But I was always doing a lot of refactoring and code cleanup on this kind of quote unquote on the side. So a typical day was kind of, I would say contributing as like a. seen E5 senior engineer kind of locally on the team that I was on. Someone who's, you know, working on a pretty small team of five to 10 engineers, leading projects, helping break things down, helping mentor.

And then that was kind of like, I would do that in like 30% of my time and spend the rest of my time on this massive refactorings and cleanups and kind of these.

code-based wide efforts um wow so like in 30 of your time you did the work that you know like for an e5 or e6 that would spend i don't know like you know like 60 70 80 of their time depending on how you look at it yeah wow yeah but that was But that was kind of like, like that's kind of also why the coding machine progression is, is hard because it's like, if I'm kind of acting like that, that role on a team, it's like, if I did.

If I spent that 33% of the time, multiplied it by three, and I just did like three, replaced three senior engineers, that probably wouldn't be enough to justify getting to like the kind of E7 plus level at Meta. So that... had to kind of be weighed in with the, this like outsized other impact that I was having. Yeah. I don't know if that makes sense. And the concept of archetypes, it's super interesting that, first of all, someone championed you. Was it your manager at the time?

It was actually my skip-level manager. Your skip-level champion saying, here we have this IC doing great work, but they don't really have an archetype, and let's create one to recognize and help them grow professionally. But taking a step back, the concept of archetypes is very unique to Facebook or Meta these days. I haven't seen it at many other companies, but what I do see is...

There's kind of a glass ceiling of people being stuck unless you become a tech lead or more. Usually it's a tech lead where you go on and you have an impact. Why do you think... With your current business, you have a window into how other companies operate and how they interview and how to get in. Why do you think this is?

Meta still seems to be one of the few companies that has come up with this concept of career progression for repair senior software engineers on the IC track with archetypes. Yeah, I think it's a good question. I think it reflects the company's culture. It's an engineering first culture. There was tremendously talented individual contributors that I worked with early on in their careers. And Meta wanted to support those people.

and kind of break through that idea that you have to be a manager to progress. So they wanted these people to be empowered. And it's not just the levels. I feel like nowadays the companies are so large, people are kind of... Maybe the way that IBM felt to me 10 years ago is maybe how people might start looking at the structures of these big tech companies now. They just have tens of thousands of employees. It's a lot more.

rigid um but meta like really wanted to have these individual contributors be superstars that were kind of socially influential to at the company and and kind of you You would see at all hands. You wouldn't just see a presentation from the vice president of a department. You would see a presentation from the highest ranking individual contributing engineer as well. And they kind of had this.

this equal presence. But I raised a lot of, or flipped a lot of tables, you could say about this at the time, because I felt like there still wasn't even enough support of ICs at the senior levels. more junior levels of management, there was about parity more or less between like a first level manager and a staff engineer, the M1 and E6. They were roughly equal percentages kind of.

Just to click on that, when you say roughly equal, do you mean in terms of influence, scope, compensation, expectations, that kind of stuff? Yeah, all of the compensation, like scope, all that stuff was roughly equal. And the kind of ratio of senior managers to junior managers was roughly the same as E7 to E6, which are like the... parallel levels. And then once you got beyond that, to the kind of director level, which was D1 and E8, there was kind of...

10x more directors or something like that. I mean, there was like 10 E8s at the company at the time. There's like 20, 30 directors. And then that's when I started asking the question like, okay, so there's this great career progression for ICs compared to all other companies that I know.

Um, but there is still kind of this limit and I was really pushing back on that. I wanted like the infinite limit. Um, I wanted to know why there weren't equal numbers of directors and, and kind of principal engineer or, uh, whatever. partner engineers, I don't know, whatever the titles get beyond that. There isn't really titles. And so I pushed a lot on that. And at the time, the reasons...

weren't necessarily super clear, so I was really pushing on it. And in retrospect, kind of zooming out, I really see that there's a limit that an IC can have in terms of impact as an IC without... having these manager-y like uh kind of behaviors um even if you write 10x the code or 100x the code um you cannot replace

30,000 engineers with one engineer. So you can be a VP of engineering, though, overseeing 30,000 engineers. So no matter how kind of multiplied out, like, I don't know, it's like... some anime analogies where these characters get like super like super like jacked up yeah you know they they they They can only get so powerful, though, as an IC. And managing all of those, if you're the manager of 10 of these superstars, you still have more influence slash impact.

over kind of the direction of those people in the company. So I still, you know, I still don't have like a the best articulation of that. But I do understand now more why once you start getting to those extremely senior levels that you can't really get past a certain point as an IC. But yeah. Is it fair to...

To say that for these really senior IC roles, the E8s, the principal, distinguished or partner engineers, tenure becomes really important because I would assume that it's really hard to come from the outside and have this outside influence. Whereas if you've been there for a long time, you've helped build some of these systems, you know them very deeply, you have a super strong network, it's just a lot easier to have that outside influence. Is this a fair observation? Excellent.

observation and question and point and discussion topic for sure. Because this was actually one of the most interesting kind of tensions I started observing when I got to that level. Anyone who's in E7+, there's kind of a private group for those people to interact. That's kind of like, you know, back channel, maybe, you know, kind of...

sync on things. This is probably out of most companies probably, by the way. And there's like a kind of in-person event too that they were doing at the time. And there was basically two groups of people at this. And in this bucket, there's the outside people and the inside people. And I'm very different. I mean, those aren't the right words because that sounds actually very, it sounds like, yeah, but I understand what you're saying. People who joined.

join Facebook externally at a high level and people who grew there from a low level. there was definitely a tension. Like the Facebook culture is so strong. The values are so strong. The people who rose internally were generally promoted extremely quickly, similar trajectories to me. And they had a very... Facebook ingrained like, uh, behaviors. People who came externally at these really high levels, they brought, um,

different perspectives from their previous companies. So a lot of extremely senior people from Google and Microsoft brought kind of their perspectives. They definitely did not immediately align to the Facebook values the same way the internal people had built up over the years. So there was definitely this difference. And generally speaking, the... external people who joined externally had a harder time having impact at those levels and not a lot of them um were

at Facebook for a very long time, and a lot of them kind of left. I don't know if this has changed in recent years. I would probably expect it would have changed. But at the time, when there was only about 100 of people at these levels, there was definitely that. that difference. And I think it's a testament to how strong Facebook's values were actually meant something and were not something on paper.

Like if you were move fast and break things was a value. And if you moved really, really fast, like, and you broke something, you were almost. Rewarded is not the right word, but like it was not a bad thing that you like you were not fired for breaking something because you were trying so hard to live the values. Or if you were making a really bold bet because be bold was a value and you're really pushing.

pushing the limits of what people thought or pushing people to think differently. That was really rewarded even if your idea wasn't great for the business at first and it never worked out.

So I think that's kind of why that happened. I can't speak to today, though, what happened since then, if that's still the case. There's definitely a lot of... uh in the ai talent wars that are starting there's a lot of extremely senior people in ai who are being brought in from external who have unique skill sets that

are that irreplaceable. There's a lot of stuff going on there that might change that. I'm interested in your story because When you told me that in six years you went from intern to E7, which means you went intern, which I don't know is E0 or something, E3, a new grad, E4. E5 senior, E6 staff, E7. I think that's like four.

I counted for promotions and increasing difficult ones. Usually a career path like this would take at least a decade if you're on a strong trajectory. Can you talk about what happened, how you basically rolled through the ranks? quickly and what you learned doing this? I was known at the company, company-wide, as being the single-handed most all-in on Facebook person that you could imagine. When Facebook rolled out... public facebook.com email addresses for all users.

I shut down all my other email accounts and only used that one. Wow. It was just really all in. And people were just like, you don't have a Gmail account. This is crazy. But anyways, in terms of the progression. So I would say one level at a time. It's kind of like I'm not afraid of heights, but like if you're kind of doing a hike or something and it's really steep cliffs and, you know, it's like if you if you.

Look, if you zoom out and look at the cliff, you're like, oh, my God, this is like no one could like walk on that path or climb that cliff. This is like this is impossible. But if you kind of go there, look down and just focus on the next step. you can get there and you might realize that it looks a little different than when you were zoomed out. So I was really took one step at a time and was focused just on what's the next level.

What are the requirements? Am I doing this yet? Et cetera. And there's two key things though, that I think worked really well for me. So, and they're kind of very different, different things, but the first one was. my manager relationship. And this was not, I don't mean this in like a, you should be friends with your manager or I was friends with my manager.

um in fact i was a very difficult person to manage and i don't know my managers like me that much just because i'm a little impulsive and i'm very passionate when i'm doing my work and it's a little hard to wrangle me sometimes when i'm really in there but um What I mean by the manager relationship was there was a lot of trust and transparency both ways. So my managers knew who they were working with and I trusted that they knew who I was and that we would.

We were on the same page about putting me in the right spot to work on things. And it goes both ways. I also felt like I could help my manager do well at their job. They're a little overloaded with junior people on the team, helping to mentor those people. And having that kind of more trusting, supportive relationship both ways, I think really helped. progress. My manager could be really blunt with me. Like, Michael, I'm getting feedback. You're causing too many bugs on this.

area of the code, it's bothering this team that's going to hold you back, work on that. And I'm not defensive and I'm like, got it, I will work on that, but I will not slow down. And we kind of got that relationship. That's really important for me because it really helped me. just move through the system. On the second thing, completely unrelated, I always had a notepad of things I was doing that might be useful in performance reviews or in summarizing my work later on.

So if things happened in the moment, I don't know, fixed a really weird bug that was emergency bug that was flagged at like the company level and I jumped in and fixed it. I might just like put a note on my notepad that I did that. And then when it comes around to kind of performance review time.

Or one-on-ones with my manager, I could kind of go over these things I was doing and bucket them and be like, you know, I'm doing a lot of work that a lot of these things are contributing to the requirements of the next level. So what else am I missing to get to this level?

um and then working on those things um so that that kind of really helped me it's it's funny that you say this because uh this concept like went viral when julia evans blogged about she called it a brag document in my book the software engineers guide I actually like it's one of the best advices I gave to.

people who are focused on their career I call it a work log it doesn't matter what you call it but I've gotten feedback from people saying oh I did this one thing that you know they heard about from somewhere from online and it made such a big difference and it's such a small thing but especially when you're doing a lot

of unrelated things or here and there it like and by the way as a manager when i used to be a manager i loved it i loved it when people just brought this to me because i was like oh i had like as a manager i didn't know about like 90 of these like stuff that was not the main project It was just a really pleasant surprise. I'm assuming your manager's view shifted on you as well. Knowing you're doing all these other things, which sounds like Meta appreciated this as well. Facebook.

Yeah, exactly that. Yeah. It's a little tied in. I said they were unrelated, but it is tied into the manager relationship because if your manager trusts you and... and knows how to interpret your words and you give them this document, they know exactly how to turn that into the right thing and what that means for calibrations and performance reviews and stuff. And so I plus one to that for sure.

And speaking about Facebook's engineering culture, back then it was called Facebook, now it's called Meta, so I'm going sometimes back and forth. But what was it like? And starting with that, can you share... We know Facebook had internal tools, but what kind of internal tools were they? How can we imagine if someone went back in time, what would you describe to them? What did you see?

Yeah, this is a good question because I started off on the internal tools team. I was originally going to go to grad school and do a PhD. And I really wanted to work on like kind of social networking.

like things but for companies um and not just companies just like work because social networks were really like connecting people in a way never seen personally And I was like, you know, that would be really cool if like our work was also similarly connected, if we could just as easily find co-workers of co-workers and message them and stuff like that, which now seems like it.

But at the time, it was not obvious. It was very different. So something that's really cool about Facebook at the time was that internal tools were products. So they were products just like user facing tools built on the exact same code base deployed to an employee subset of Facebook rather than like the public website, obviously.

So internal tools were seen as product building. They weren't seen as like... these annoying things that the company has to do like a lot of tools were seen at the time like a you know it's like no one wants to be on the tools team it's the the slow moving boring team but i met it was like our facebook at the time it was like

Probably the most exciting team because you can build product at a speed for building product for seven, eight, 900,000 people is very much faster than building product for, at the time, I think it was like 200 million people publicly. So that was really, really exciting. Meta still, I think to this day, has a culture of building a lot of internal tools from scratch.

One of the main reasons is they built all their infrastructure from scratch. There was no cloud providers at the time, so they had all their own infrastructure. They even built their own servers. eventually hardware for servers themselves. So that mentality resulted in really custom tools to work with all this custom stuff that really just didn't make sense outside of it.

And, but yeah, I think because of that, because all these tools were like treated like products, though, there was definitely like this engineering product. ecosystem the whole company has had as a result. Even if you weren't working on these tools, you were using these tools, you really felt like Facebook was a technology company that was solving even its

internal finances using internal tools and site integrity. It really felt like no matter what job you had at Facebook, it was a product engineering company. So then just to be concrete, there was a custom version control, it wasn't like GitHub or something like that, custom code review, custom build tool.

I know Facebook also open-sourced some of this, or at least released some of this. The build tool, I think, was it Buck? And Fabricator, they also released. But everything was just completely custom, right? Or internally built for... to work however you want it to work. Yeah, I think maybe in terms of everything you said, except for source control, they were using SVN as the backbone. And then people used at the...

I can't remember if they used Git first, but they basically jumped to using Mercurial locally on people's machines to manage their local branches. But then you would always merge. using SVN to the main branches and repos. And the reason they chose Mercurial was because it was a lot easier to work with the open source team to hack.

hack into it, things that they wanted. So it was still the same ethos, even though it was not their thing. The Git people were not as open to making some of those changes. Yeah, building all those tools, the code review tools. A lot of these tools have seeded like the companies of their own now. I think Statsig and I think there's some others. So Statsig is experimentation, right? Or it was seeded by the experimentation platform? Yeah.

gatekeeper internally. I mean, these are not like people moving and copying them, but more or less. I also know Graphite. They're a team, five meta founders who are bringing the concept of stack diffs. to production. Again, inspired by this. It feels like there's a lot of teams who saw Facebook had something really cool that worked really well at a large company, but it just doesn't exist outside. And now they're productionizing it. It seems like there's demand for it.

Y Combinator Startup School talk, I think it was 2009 or 2010. He said that he wanted Facebook to be the place that was known for training people how to build really good product. And kind of training people to potentially be really good founders. And I thought it was like a bit weird at the time.

He also didn't talk that much publicly at the time. And I was like, oh, but what about training people to be really good engineers at Facebook to stay at Facebook forever? And I guess it was the audience. It was the startup audience. But it got me thinking a little bit. And when you zoom out and look, it's like Facebook was exceptionally good at taking passionate, ambitious young engineers who don't have much experience and building extremely strong.

abilities for them to execute and deliver. And we're seeing a lot of those products now being really robust, strong products that are coming out and helping people be on Facebook now, too. One question I have, is it true that there was an internal tool just for booking meeting rooms? It was awesome as well. Someone told me. Yeah, there was. My intern project when I started was also a meeting scheduling tool because it was like...

I just wanted to click on three people, find a meeting for them, or find a time they can meet, find a meeting room, done. So I actually built that tool, yeah. When I first heard this, I just had such a hard time believing, because Facebook was already a lot bigger, that A, someone would build this, B, people would also use it, and C, there would be a team maintaining it.

That all happened because it kind of sounded like anyone could build this at any company, but maintenance would be a pain, you know, funding. Most companies would have a lot of politics in terms of like, okay, we need staffing for this team. We need budget. We need to justify in India and a few years later. as by a vendor solution or something. So it really surprised me that even for a relatively small but really important thing, it kind of happened there.

It sounds kind of like when you talk about it now, it sounds like a kind of, I don't know, Wild West place, but, or like, you know, like there's no problems. There's these things are just, it's like the, you know. The best place for engineers. But there are those challenges, too, when you start to grow and scale. It's one of the reasons why as Facebook got bigger, I was kind of less, like, that was not my thing, you could say.

um like the meeting rooms for example right like so that was one of like 40 tools that i worked on when i started was the tool to help people find and schedule meetings it was it was just a very quick I don't know, fast thing. It worked, did 90% of what was needed. It was kind of that vibe. And then, you know, as a company got physically bigger and physically had way more reading rooms and.

you start diving to the next level of product problems. What if people book the room and don't show up? Do you free the room? What if someone else wants to use it? What if someone's... Like sitting there and not doing a meeting, but they're just doing, they're sitting there for fun. You know, there's all those problems that you start, just like I was saying, product problems, even though they're internal.

You know, and then so now you start getting into, OK, do we need to have sensors in the rooms to know if someone's actually there? And then if we need to buy those sensors, we do need a budget for it. And then we need to install them and we need to install them across. 20 different offices. And then some offices have like restricted floors for.

external people and you can't put them in those ones. And like you do end up getting to all those details too. And I really love the product details. I think it's like, I love like going to every single detail of a product and really like ironing those out. But I do not like the budgeting side. or the convincing other people that this is worth the budget side, I'm just like, give me the keyboard and let me code. That's me. Yeah, so you did a lot of coding, but...

You were a pretty early employee at Facebook relatively. Did you get to work with Mark Zuckerberg? Because I know a lot of early employees do have either collaboration or some stories of interacting or working with him. What is yours? I'm actually friends with him because I was there early and I did cross paths a lot and got to know him a little bit over the years.

I mean, I can tell the story of how we became Facebook friends. That's kind of like a thing. Oh, okay. We started as an intern. We started as an intern. Like, you know, it's all these interns from school, even though like Mark was like. two years older than everyone or something he was not uh he was like a college dropout it wasn't like he was like a you know uh industry veteran but um he was still you know he was

He was well-known, and all the interns kind of friend-request him on their first day, and hopefully he'll accept it, you know. And it was interesting, the way that he kind of... became friends was um he used to play risk the board game um i think it was like once a week people would get together it was like four or five people and he would show up often and i really liked risk like i would always play risk as a kid for

Whatever reason, I don't even know why. And one day we're like down to the final three people and it was like me, him, and I was losing. Mark was like in second place, kind of the leader. was taking over. So I did a really, let's say, delicate strategic maneuver where I made an alliance with him to share resources to all go after the first place person.

So he went all in against the first place person. My turn's next. I did not go all in against the first place person. I took over Mark's remaining resources. He just dwindled going after the first place person. I think, and he accepted my friend request very shortly that evening, I think. But the reason is just showing kind of...

It's weird because I basically backstabbed him in the game really bad, blatantly into his face. But it's the game. That's what risk is, and it's a strategy game. And I think that, you know... He appreciated the strategy that I had. It made him feel more like he could trust me. Even though I backstabbed him, he knows where my strategic thinking is coming from. That's something I've seen with Mark over the years.

In product reviews, both myself doing product reviews and also product reviews with other people. He asks a lot of questions. He's very detail focused. He really dives into like. Can you tell us what the product review is? Because I don't think it's as common outside of Facebook. Yeah, it was called the Zuck review at the time because he was the only person doing them.

product teams of five to 10 people at the time, roughly. And once a week, they would do a Zuck review, like a 15-minute presentation kind of thing. Usually the PM or the eng manager would do them. And sometimes members of the team would join if it was relevant. So it's like a doctor's office. There's like a waiting room of the teams because they're so short.

And, you know, one team would go in, do their Zuck review, they would come out and you would see like they got good news or bad news and you would see the expression on their face. And Zuck would kind of just... give lots of feedback and steer the direction and they're really short so it's very efficient um feedback but um yeah those were

So kind of interesting. The more junior PMs would really stress about these because it was like their face time with the leader of the company. And like I was just saying about the risk story, you know, like Mark is kind of judging constantly. Does he trust you? Does he trust your judgment?

trying to read the situation so it was a little stressful for junior pms going in there and uh they would really like sometimes the night before be like trying to think of all different angles and they're like i got this backup slide in case mark asked this question and this other backup slide in case this

one and then you'd go into the review and like you would interrupt in the first slide and just go into a completely different direction um you would see that sometimes like um in like the nicest way possible like he's very not mean not aggressive person just At the end of the day, it was about everyone delivering really good product and wanting to build the best product and really trying all the hardest they could as individuals to get there.

sugarcoating anything not patting on the back for no reason like we just all got to be really honest about what this product looks like and how do we make it better and and yeah so you mentioned you know you try you try to work hard to build the best product, but you also wrote tons of code. So I'm going to assume you must have caused some outages because it just happens and move fast and break things. What was your worst outage or worst bug?

This product that I don't know what the inspiration was. I didn't come up with a product idea, but we wanted to allow people to upload like a photo template on top of their profile picture. So nowadays we see that on LinkedIn all the time with open to work or hiring, that kind of thing. Like this didn't really exist at the time and they wanted to let people at Facebook do that. It would help increase engagement.

People who haven't changed their profile photos for like five years might use this to spruce it up a bit or something, you know? So I was kind of, I built, I built this kind of a prototype of this thing. really fast, like in a week or something after it was handed to me. And then unfortunately, there was some terrorist attacks in Paris and... A lot of people were expressing support on social media for the people who are impacted and trying to hope for a good recovery.

We released, using this new system, we released a template of the French flag that people could overlay over top of their profile picture to show support. What we didn't expect was 100 million people to do that within like a day or two. Wow. Literally. And this was a prototype. So this is an interesting thing. I basically, the way that I built this is, you know, you have like a template object, a photo object.

all these things are federated across tens of thousands of databases. So each kind of object has a home database. So, you know, we need some way to tell this relationship between... profile object, photo object, or sorry, template object. So there's kind of an edge concept to connect the two.

And you can have a one-way edge that just goes from one to the other or a two-way edge where you go in both directions. You can go in both directions, starting at the profile to the template or starting at the template to the profile. Sounds simple, sounds like systems design 101, systems design interview that at Formation we're helping people with all the time. It's a classic problem. And then the system would just fetch these two objects and combine them or something, right? Yeah.

And typically, at Facebook, most things start with the profile. Like a person logs in and that's like the root of all queries, so to speak. Start with the profile and you get the profiles friends. They're kind of edges. It's like a graph and you're starting at the jumping in at the profile and then.

crawling through the graph from there. And if the profiles are all federated across tens of thousands of databases, you can kind of crawl out through a nicely distributed system without overloading any particular node. But when you have this template, which is an object in the system, just like a profile, if you have an edge from that to the profiles, and there's 100 million of those written in a day,

You have 100 million edges going on that one node, one database that that template, single French flag template is stored on, being written constantly. And rights are a lot more expensive in a system, in at least Facebook's system. And that node is like one machine or virtual machine or something behind it, basically. Exactly, yeah. So, and I mean, there's lots of other objects on that.

that machine too. Like there could be other profiles, it could be groups, there could be like notes, there could be the events, like all kinds of stuff on that machine. It's just, it's kind of the federation is not by object type, uh, generally not by object type. Um, so. that machine basically melted i don't know physically i didn't hear if it it may have physically melted no probably not but um it so that machine like crashed and then and you know if

I'm trying to grab my friends and my friends on that machine like that fails. So it causes cascading effects if that kind of thing can happen. Wow. And yeah, so it's interesting. Now, the interesting thing is like it's a really bad bug. um it's interesting because we help at formation we're helping people with system design all the time it's one of the most common things we're helping people prepare for in interviews and um when you talk about these things like this sounds like

the most basic systems design system. You have federation and partitionings are very common topics. And this sounds like an obvious thing. Why would you potentially have a... a two-way edge on a system where one of the nodes might be super heavy. this is not an exact example but um twitter had a lot of outages with the fail whales back then because they had a system that was similarly vulnerable when uh

Justin Bieber tweeted or something, they had a similar system. Yeah, because they had the fan out problem, right? So a similar, yeah. I mean, these are like known problems. And it's interesting because... I see so many people preparing when they're thinking about systems design interviews and stuff. They're thinking about the textbook answers for all the different things that can happen. And this is just one really simple situation that...

talking through why, like, why did I make this two way? Was I like ignorant or was it not? And the reason I did it was that this was a prototype. And when you're productionizing something. You need to put a lot of logging in for performance, for collecting metrics, for analyzing, like, is this working? Is it not? All these behavioral metrics, all these things that you would do.

You have to put a lot of time and effort into thinking about what are those things? Where do we log them? How do we log them? How do I explain to the PM how to do it? And if we just use the raw data model itself to store some of that. And we keep that two-way edge. It gives us more information. It lets us just count the number of edges as the number of people who have used this.

You know, like it's, it's, it's simpler for a prototype. And we don't have to like build all this stuff. If we don't ship it, I don't want to rip out all this logging. I don't want to like have wasted time explaining to the PM. how the logging is working those kinds of things totally simpler reasonable that's why the decision was made and then the second this machine melted we knew exactly what to do and we

So how did you resolve this outage, right? Because now you actually had a problem, which sounded like it's at a data level. And usually with an outage, if you might, you know... The best way is to roll back the change. Clearly not an option here. How did you fix it so that actually people could start to use those profiles? Yeah, so this actually was beyond...

Beyond my area, there's a DB infrastructure team that stepped in. I removed the edge, so we made it a one-way edge. Due to the success, we... of this feature, we also productionized it and addressed those kind of more logging and things like that that we lose by chopping off that edge. But yeah, so the infrastructure team kind of handles the...

rebooting the databases, the replaying of SQL logs that might be necessary because of lost transactions and things like that. They handle that level. As a product engineer, you need to be aware of what's going on and maybe send over. a six pack of beer or a cake or cookies to the people afterwards to build up that reputation. I'm assuming it was not the first time for them. Like someone adding an edge and overloading a few nodes.

Let's just say the site reliability team had one of the most well-stocked bars in the entire... Like alcohol bars and the entire company. They just kept driving. Thank you for this. Thank you for that. I'm actually not joking. It was extremely well stocked. I don't know if that's still allowed or what. Lots of favors there. That's a good one. So something interesting you told me before this one is.

that when it came to hiring, Facebook has this concept of the hiring committee, but it was also open door. So you could go in and you could shadow and sometimes, and you did shadow multiple times and then you participated. Can you explain to us, like the ones who we were not at Facebook, what was this hiring committee meeting like? I understand these were when they decided on the hire, no hire decisions.

How did they go? What was it like to listen in? And what was it like to participate? And what does this tell about Facebook's hiring process for software engineers? Maybe just a really quick kind of recap of how you get to hiring committee. The kind of meta or Facebook. Interview process starts with a lightweight recruiter screen, get to know you, and then you'll jump into a coding interview. It's called the technical screen. It's like a 45-minute interview, usually two questions.

If everything goes well, you'll go to the onsite where you'll do for most people, you'll do. two more coding interviews, a behavioral interview, and a systems design interview. There's some subtle variations there. You said cool names, right? These used to have cool names. Jedi, pirate, and... and Ninja. Ninja was coding, Pirate was system design, and Jedi was the soft skills.

yeah behavioral at the time it was half behavioral half coding still they really wanted the coding signal um and now i think it's all behavioral um but yeah um And then also just because this is what we do at Formation all the time, two like critically interesting things that are about Meta's interviews, specifically the technical ones that really throw people off to are the.

They are whiteboarding style and there is almost no small talk. And these two things like can throw people off in the technical interviews. A lot of the times you'll, you have 45 minutes, you're expected to code, code up solutions to two problems. So, you know, you jump in and sometimes the interviewer will just be like, hi, my name is blah. Nice to meet you. Here's a problem. And it can throw people off a bit because some people are.

Well, everyone's nervous. I don't know anyone who's not nervous in interviews. But, you know, it can be a bit like, you know, you want to like settle in, build a rapport. Like maybe if I screw up the question, they'll like me. No, not for the coding interviews. You just got to write the code. So that's why one.

And then the second thing is whiteboarding style. Now that things are remote, I don't even think you can compile the code. They either block it or they tell you not to. So you can't just guess and check to run your code to see if it works. They want to see you walking through a clear and clean thought process, problem-solving process for how you're approaching the problem, how you're solving the problem. They want to see your code being clean. They don't care if it...

has some minor syntax issues or you forgot a built-in functions signature and you just guessed it for the interview type thing. Anyways, those are two kind of things that are... specific to their interviews. But anyway, so you have this kind of, you do your onsite, you do your technicals, your behavioral, your systems design, or maybe two systems design. And then you, if...

Everything goes fairly well or better than you'll go to a hiring committee. There'll be a quick debrief with the people, the interviewers, I mean. The interviewers will quickly sync, sometimes over email even. Were there any red flags? Were there any strong no's? You might just... and the process there. So usually I tell a formation all the time. If you do a meta interview and you hear back really, and you don't hear back really quickly, then it's usually a good sign you were not.

quickly node um you at least have a chance so people get nervous when they're like oh no i didn't hear back in a week and that's not a bad thing that's an okay thing or maybe even a good thing so um anyways you'll end up in hiring committee at the time they met When I was there in the mid-2010s, they were meeting like twice a week, I think. And it was open. And this was like really, I don't even know if it was like officially open.

Or, like, I just went. Like, it wasn't publicly open, but it wasn't closed. There was a public calendar for engineering recruiting, and it was on there. Oftentimes, all the recruiters who were representing a candidate to try to get approval for hiring would bring their candidate there with a packet. So people were going in and out. And I just I showed up and I would just started going to them and I would have to figure out where they were. And it was kind of like, you know, a secret.

secret handshake like not figure out what door to go to like sometimes it would move in it and kind of figure out where it was sometimes but if you if you found it you walk in and sit down at the table So what happens in hiring committee is a recruiter will present a packet. This is actually pretty interesting. Very few engineers talk about this topic by the hiring committee. Recruiters are definitely...

would be able to, but I haven't seen a lot of them talking about it. So I won't give like any secret sauce away, but just the general process. A recruiter presents a packet to a quorum of... leaders. So there had to be at least three director or VP engineering people there at the time.

I don't think it's like it's not like a legal constitutional number, but it was that was just like they wanted more that they wanted a quorum of decision makers. And recruiter would present the packet to them. A packet. has a bunch of information. It has all your interview feedback. It has, this is like super, super interesting, but it has the interview history of the interviewers themselves.

It has the histogram of the interviewer's feet of past ratings. So like, is this interviewer like super binary? There are your strong yes, strong no historically. Are they like. Lean yes or lean no. So it helps the reviewers kind of calibrate and interpret people's feedback. Are they a really experienced interviewer or are they a brand new interviewer?

It would have the questions they asked. It would have how many times they asked those questions. Like, did this interviewer ask this question for the first time or have they asked it 150 times? It has like a lot of information in the packet. that was presented to the kind of directors. The directors would read it over, look for anything, any flags. Usually at this point, like the default would be that someone would...

more than likely be hired. So they're kind of looking more for flags or inconsistencies. I can give tons of examples of what those are, which are, you know, this is one of the things that formation we... Like one of the reasons why people work with us is like getting to some of these nuances and stuff are pretty important, but might take hours. So I won't go into all of them. But.

Yeah, they're looking for flags and different things. The most common thing that they're kind of looking for is level. I reiterate the fairness and consistency that Meta wants to have in its hiring process. And they want to bring in someone at a appropriate level where they are an appropriate level consistent with other people who perform or have similar scopes of responsibility. So they want to make sure that your level's right.

And that was probably the biggest thing that was discussed was kind of like, is this person a senior? Are they mid-level? If they're a mid-level, do they have too much experience? Is their career progression a little bit slower than we wanted for a mid-level? and maybe will reject um or are they actually at the senior level and this is simple or are they did they interview at the scene and they and they did they interview and appear

with some of the traits that a senior engineer might have, but they're clearly mid-level from their background, and they want to make the call on where does the offer end up, stuff like that. They're kind of working through all those things. So why did I go is maybe an interesting question. This sounds kind of boring maybe. Let's get into it. I was paranoid that Facebook would lower its hiring bar as they scaled.

And even now, I don't really like saying lowering the bar because I think that especially working at formation and the kind of like the secret sauce, I think, to the to. interviewing and finding a job is finding the right job now. So just because you didn't quote unquote meet the bar for meta does not mean that you're a bad engineer and not hireable. It just means that there wasn't some kind of alignment.

It might be your, it might be them. It might be you. Like it's like, you don't really, there's too many ways to overthink it. But finding that like right role is like way more important than just checking out the boxes and passing the interview and feeling great that you got the offer. So I think that that's like, uh, in, yeah. So in the time though, at the time I was just like paranoid, like, like, I don't understand how the company can grow 10 X and not like.

not not lower the bar accidentally or like I'm paranoid about this like I want an extra check so I was like going to these things to like see who's being hired and seeing if I had any flags and I would chip in occasionally with my my two cents and um You know, sometimes it had some impact. Sometimes it didn't. Well, I guess look at how things work out now. Turns out those sessions were pretty helpful now.

doing what you're doing at Formation, right? Coaching people, helping people. The fact that you were in the room is a big difference. Yeah. It also really helps people. Even if it's just to reassure them if they don't get selected but they thought they did really well. I think I have, you know, you can say things with words, but I really have the experience there to... to help people get that it might not be that they failed or that it could be a lot of reasons.

So in terms of interview processes, you are intimately familiar with Meadows, but of course, because of what you do at Formation, you're familiar with a lot of other big techs. What company do you think has the most similar... recruitment process for software engineers as Meta has these days, if any. The lineage is pretty interesting because the interview processes are fairly similar in a lot of the top companies.

There are some differences here and there, and some things have changed a bit over the years. But generally speaking, Leacode didn't exist as a word until 2012, I think was when they were founded. The problems haven't changed. The interview styles haven't changed since before LeakCode, since after LeakCode. It's a pretty consistent kind of style that has been around. Facebook didn't invent these things, they borrowed a little bit from Yahoo.

They borrowed some things from Yahoo, from Microsoft, from Google. Google was the preeminent place to work at the time, too. And Google borrowed from other companies, and now we see a lot of the AI companies.

Like OpenAI has a fairly Facebook-ish process and vibe. So yeah, we're seeing this kind of, and ultimately like... I think the reason why this is the case is that these interviews, especially the, we call them the Lee Code interview, but like at Formation, we like don't really, we don't like pigeon.

uh pigeonholing the the naming to being like to being about like doing a problem clicking a button and something saying like you passed or that that kind of thing like the point of these interviews is to test stack agnostic and language agnostic problem solving skills and that has always been the point that's like what engineers do um these and these interviews haven't changed as stacks have evolved like they they're really trying to take away

any biases that might come from being a JavaScript programmer or a C++ programmer. Just focus on the core logic, the problem-solving process.

um and that's kind of what they're trying to do and that's like what engineers do so it's like it's very understandable that all many truly technology and engineering companies use these processes and you know the companies that don't are generally smaller companies because they do actually want expertise in specific stacks or specific experiences or non-tech companies that don't really have the same ethos.

But yeah, so we actually see a pretty, the variations of these. Some companies do some more practical, non-DSNA style stuff, but... It sounds like it's smart. If you want to get into one of these companies, just go through, prepare it. Because it's useful everywhere, right? You master it once and it's useful probably for years or even beyond.

Um, yeah, one of the interesting things that formation that we've seen that kind of shocked us is we actually see people coming back after they come to formation will help them. prepare for these data structure algorithms, these systems design interviews. They get a job and then two years later they come back and do it again and pay us again. It was kind of one of the surprising things. From a business point of view, that's like...

The dream is you want to have a service that's useful to people for their entire lives is way more valuable as a business than a service that's useful at once. So that's actually kind of pleasantly surprising to us. And I think, I think like the, I mean, we're going a little bit of a tangent about interviewing now, but like, I think.

The interview preparation process, I draw a lot of analogies to a personal trainer. You want to get in shape. You might have been in amazing shape 10 years ago. You remember what it was like to have the habits to be in shape.

eat well, to do your exercise and like, you can do it again, but you're not in shape now and you need to maybe get in shape again. And whether you've got a gym membership or a personal trainer or, uh, you kind of just make do it yourself like there is like kind of this recurring pattern of getting ready for these interview processes um there's infinitely

many stacks and combinations of frameworks that an engineer can work with. And when you work with your frameworks and your stacks for years and years, you kind of... you know you it's like you're working out but you're only doing leg exercises so maybe your legs are like really strong and your upper body's like not as strong because you haven't been doing that and you know you have these different transformations that you make just from your day-to-day job so

When you're making a career transition to a new job, getting back in shape again makes a lot of sense. Yeah, and I know people complain about how interviewing is different than the job, but it is. It's how it is. I think you can either fight it or accept it. But speaking of...

This topic, what advice would you have for more experienced software engineers who are interviewing right now, just in the sense that we know that the job market is a bit tougher than before? What kind of tactics have you seen or strategies? that help people and offers at some of these better known companies. What are things that are more important than before? Yeah, it's definitely changed over time.

joined out of school it was like um i think there were so few engineers um like i know people who are trying to get h1b visas were just being handed them because they had such a surplus Wow. And now there's like 20x oversubscription of people trying to get tech jobs in the U.S. and specifically as one example.

There was a different vibe back then, I would say, but now it is more competitive. There's a new team matching process that we're seeing a lot of companies have. Google's had this for a long time. Google's had this process for a long time, but Meta's more recently added the team matching process. We're seeing a couple of other companies, smaller companies, but not do kind of this.

it's like you you know you passed the on-site but now there's another another uh you know you're kind of in limbo for a while until you actually match to get the offer um and then there's some Yeah, so we are seeing that competition be distributed across a couple of different places, adding a couple extra layers, a little bit more filtering on the front end. We're seeing more... More companies give online assessments like right off the bat instead of jumping into the technical interview.

to kind of filter more people there. So we see a lot of people who have like 10 years of experience. They've never used the tool like CodeSignal or HackerRank. they fail one and they're like, what is going on? I've never seen this tool before. We're like, you know, we have to practice that. Yeah, definitely seeing that the competition is definitely distributed across each level of this process, for sure. Nice.

All right, can we wrap up with some rapid questions? Yeah, sounds good. All right, so those are rapid questions. I just ask the question and then you just fire out whatever comes to your mind. the one that you can recall, I've been wanting to really ask this. How many diffs did you close or code in your most productive year when you were a coding machine? Did you keep track of that?

So I did keep track of it because I was kind of in a competition. At first I was competing with other people. Sorry, that was rapid, but I was competing with other people to try to get more code than them. Once I surpassed everyone, I was competing with like this release bot. release like the release part yeah so it's like i gotta and then after that i think i stopped like counting but um it was a lot yeah uh in the thousands

I honestly write more code now, though, even after leaving Facebook app formation. I'm writing a lot of code. Yeah, so like multiple diffs per day, basically. For sure, yeah. It's probably around $5,000 to $10,000 a year. in the double digits per day. That doesn't really mean that much. Some are small, some are gigantic. It's hard to... Yeah, but your code actually did meaningful work. That was part of why you got promoted the difference.

Which language did you write the most code in when you were at Meta? And which one do you write the most code in now? PHP evolved into Hack, which is their version of it. hardly any javascript and then after leaving i kind of had to learn javascript as a almost like a junior um and react and get up to speed on that and now i'm a very uh all javascript yeah front end and back end

And which one's your favorite programming language? What's the reason? It's grown on me, but I would say TypeScript specifically, which I don't really call it a language. So at Meta, I wrote... I sound like telling the long time ago stories as a grandparent or something, but I wrote all my code in Vim with no IDE, no syntax completion. All I had was syntax coloring. Like I almost had the code base in my head to code. And now that I've...

Slowly warmed up to TypeScript. I actually really like it because it helps me catch hardly any guardrails. I still can code almost as fast as I would with no types. But it actually catches bugs. catch things also helps me be a little less lazy if I'm just going to throw some parameters onto a function to think a little more about how do I type these, do I move them into a struct or that type of thing.

And what's a book that you read that had an impact on you? I think it was called Histories. It's by Herodotus, the Greek historian. And the reason why it really like sticks with me is like a lot of the stories in there don't seem to make a lot of sense, like factually. And I'm like a very like factual, literal person.

And when I read this, I'm like, wow, these stories don't seem to be real, but everyone's trusting these. And it showed me that storytelling is really important to try to communicate things that are happening, whether you're literally saying things that happened or not. The point is that to kind of influence and to share and to be human, we have to be able to communicate stories. So that kind of showed me the power of storytelling historical events.

Thanks very much for being on the podcast. This was very, very informative and lots of fun. Thanks for having me. It was a great time to revisit some old stories. Yeah, I had a great time. Thanks. Thanks to Michael for sharing his thinking stories and how a coding machine thinks about things. You can find Michael on LinkedIn and Reddit with links in the show notes.

For more details about Meta's engineering culture and how hiring processes work at various tech companies, see Deep Dives from the Pragmatic Engineer, also linked in the show notes. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. It helps the podcast a lot. Thanks and see you in the next one.