The Pragmatic Engineer - “The Coding Machine” at Meta with Michael Novati

Episode Date: January 15, 2025

Supported by Our Partners• Vanta — Automate compliance and simplify security with Vanta.• WorkOS — The modern identity platform for B2B SaaS.—In today’s episode of The Pragmatic Engineer, I’m joined by Michael Novati, Co-founder and CTO of Formation. Before launching Formation, Michael spent eight years at Meta, where he was recognized as the top code committer company-wide for several years. The “Coding Machine” archetype was modeled after Michael at the company.In our conversation, we talk about what it was like working at Meta and dive into its engineering culture. Michael shares his journey of quickly climbing the ranks from intern to principal-level and gives level-headed advice on leveling up your career. Plus, we discuss his work at Formation, where he helps engineers grow and land roles at top tech companies.In this episode, we cover:• An overview of software architect archetypes at Meta, including “the coding machine”• Meta’s org structure, levels of engineers, and career trajectories• The importance of maintaining a ‘brag list’ to showcase your achievements and impact• Meta’s engineering culture and focus on building internal tools• How beating Mark Zuckerberg in a game of Risk led to him accepting Michael’s friend request• An inside look at Meta’s hiring process• Tips for software engineers on the job market on how to do better in technical interviews• And more!—Timestamps(00:00) Intro(01:45) An explanation of archetypes at Meta, including “the coding machine”(09:14) The organizational structure and levels of software engineers at Meta(10:05) Michael’s first project re-writing the org chart as an intern at Meta(12:42) A brief overview of Michael’s work at Meta (15:29) Meta’s engineering first culture and how Michael pushed for even more for ICs(20:03) How tenure at Meta correlated with impact (23:47) How Michael rose through the ranks at Meta so quickly(29:30) The engineering culture at Meta, including how they value internal tools(34:00) Companies that began at Meta or founded by former employees(36:11) Facebook’s internal tool for scheduling meetings (37:45) The product problems that came with scaling Facebook(39:25) How Michael became Facebook friends with Mark Zuckerberg (42:05) The “Zuck review” process(44:30) How the French attacks crashed Michael’s photo inlay prototype(51:15) How the photo inlay bug was fixed (52:58) Meta’s hiring process (1:03:40) Insights from Michael’s work at Formation(1:09:08) Michael’s advice for experienced engineers currently searching for a job(1:11:15) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:• Inside Meta’s engineering culture: https://newsletter.pragmaticengineer.com/p/facebook• Stacked diffs (and why you should know about them) https://newsletter.pragmaticengineer.com/p/stacked-diffs • Engineering career paths at Big Tech and scaleups: https://newsletter.pragmaticengineer.com/p/engineering-career-paths • Inside the story of how Meta built the Threads app: https://newsletter.pragmaticengineer.com/p/building-the-threads-app—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

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 ten 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 a morning. Michael Novati spent eight years working at meta from 2009 to 2017, where in some years he was a number one code 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 staff 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 and journal 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's time at Meta. 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. At Meta, 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, text lead. And there's something called the coding machine, which apparently came about because of you. Can you talk about that? Yeah, sure.

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, their 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. And 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, et cetera. 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, when Once you're at that level, you can do all the basic things engineers do or 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 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 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 or a fixer is a really good example. Like, I don't write one line of code to save $10 million, simple, cut, dry, easy. So see that. That's what a fixture is.

Yeah. 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? And 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 it refactoring a lot of code extremely quickly and fast so that new engineers don't even have to deal with old libraries? So there's kind of these are the type of 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. It's an executive and who really sponsored me. The name's Tom Allison. And I think that he's head of Facebook, quote, unquote, the product now. Wow.

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. 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. It's a busy day.

And it's just the morning. Yeah, just this morning. Yeah. So, you know, it's kind of, I would say like in terms of going back to that professional sports analogy, it's like that's kind of the thing that, that's my thing that I'm the top 1% 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 and 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-founder navigating your first audit or seizing security to 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 SOC2 and ISO-27-01. With Vanta, they centralized 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.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 Sammel authentication, skin provisioning, and fine-grade 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. WorkOS also provides a free user management solution called AuthKit for up to one million-monthly active users. It's a drop in a replacement for Alt-Zero and comes standard with useful features like domain verification, rule-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. You get limited as 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, Versal, and Perplexity. Check it out at WorkOS.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? You know, just give us an example of like what your like week-to-week looked like.

Because you mentioned like 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 like, janky. The internal tool where you can look up like the org thing. Yeah. 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?

Clearly mentally. And I don't know why. Like, I mean, Facebook built all their own tools. So I guess I know why. But it was just kind of weird. Like it showed like two levels. It did like lots of scrolling. It's 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 was kind of like a horizontal layout. And I just, like, 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, like, kind of 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 like really well received. So you shipped this on like, 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 like totally changed the visual design. And people thought it was fantastic because the horizontal nature, which was kind of actually just a judgment call because the page was too tall vertically. Like if it was a vertical layout, it was 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's like, and people love this. And it, 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 chip it as fast as I want and we'll see what happens. And then there's lots of adventures after that, which was like 2009. How about how big was the company? roughly. It's about 220-ish. I 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 side track. What a story. We were talking about what I did on a day-to-day basis, I think, as a coding machine. So I was a, I called myself a product engineer. I was always 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 C, 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 refactoring and cleanups and kind of these code-based wide efforts. 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 kind of 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 role on a team, it's like if I did three, if I spent that 33% of the time, multiplied it by three, and I just did like five, three replaced three senior engineers, that probably wouldn't be enough to justify getting to like the, 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, you know, someone championed you. Like, was it your manager at the time? It was actually my skip level manager. Your skip level. But like your skeptical of champion saying, all right, here we have this, this I see doing great work, but they're not, they don't really have an archetype.

And let's, let's create one to recognize and, you know, help them grow professionally. But taking us a step back, the concept of archetypes is very unique to Facebook or, 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 of, usually is a tech lead where you go on and you have an impact. Why do you think few, you've now, with your current business, you're also, you have window into how other companies operate and how they interview and how to get in?

Why do you think this is? That 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. It's like a, 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 Meadow 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 now the days the companies are so large, people are kind of maybe the way that IBM felt to me early, 10 years ago is maybe how people might start looking at the structures of these big tech companies now. They just have like tens of thousands of employees. It's a lot more rigid. But meta, like, really wanted to have these individual contributors be superstars that were kind of socially influential to at the company. and kind of 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 equal presence. But I raised a lot of or flipped a lot of tables you can say about this at the time because I felt like there still wasn't even enough support of ICs at the senior levels. at the kind of 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 normalized and stuff but once you got to the director just to click on that when you say roughly equal do you mean in terms of like influence scope compensation expectations that kind of stuff Yeah, all 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 get 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. me 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. But there is still kind of this limit. And I was really pushing back on that. I wanted like the infinite limit. I wanted to know why there weren't equal numbers of directors and kind of principal engineer or whatever, there's partner engineers. I don't know,

whatever the titles got beyond that. There isn't really titles. Yeah. 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 managery, like, kind of behaviors. even if you write 10x the code or 100x the code, 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 can only get so powerful. powerful though as an IC and managing all of those if you're 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 and the company so I still you know that maybe this is like I still don't have like 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 But yeah. Is it fair 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? It's an 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 an E7 plus, there's kind of a private group for those people to interact. That's kind of like, you know, back channel, maybe they'll, you know, kind of sync on things. It's probably at 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 in this bucket. There's the outside people and the inside people. And very different. Those aren't the right words because that sounds actually very, it sounds like. Yeah, but I understand what you're saying. External, people who joined Facebook externally at a high level and people who grew there from a low level. And there was definitely attention. 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 behaviors. People who came externally at these really high levels. They brought different perspectives from their previous companies. So a lot of extremely senior people from Google and Microsoft brought kind of their perspectives. But the kind of those, 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 like a 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 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 the recent years. I would probably expect it would have changed. But at the time when there was only about a hundred of people at these levels, there was definitely 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 the limits of of what people thought or pushing people to think differently Like 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 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 kind of irreplaceable. and there's a lot of stuff going on there that might change that. So 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 four 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 rolls through the ranks

so quickly and what you learned doing this? I was known at the company, company wide as being like 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 like shut down all my other email accounts and only used that one. Wow. It was just like all, 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 have it, 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 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. 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 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. In fact, I was a very difficult person to manage. And I don't know my manager's like me that much just because I'm a little impulsive and I'm very passionate when I'm doing my work. And that's a little hard.

to wrangle me sometimes when I'm really in there. But 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. So I also felt like I could help my manager do well at their job.

So if that's maybe 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. You know, I could, my manager could be really blunt with me. Like, Michael, I'm getting feedback. You're, like, causing too many bugs on this area of the code. It's bothering this team.

Like, that's going to hold you back. Like, work on that. And I'm, like, not defense. 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. Then when it comes around to kind of performance theory 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 and then working on those things?

So that kind of really helped me. It's funny that you say this because, this concept like when viral when Julia Evans blogged about she called it a brag document in my book the Software Injure's guidebook

I actually like it's one of the best advice I gave to people who were focused on the career I called 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 to be a manager. I loved it. I loved the one 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. And like, it was just really pleasant surprise. So I think, you know, I'm assuming your manager's view kind of, you know, shifted on you as well and knowing like, oh, you're doing all these other things, which is, 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 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 like starting with that, like can you share like we know Facebook had internal tools, but what kind of internal tools were they? Like how can we, you know, like imagine if someone went back in time, what would you, you know, described 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, I was really 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 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 coworkers of coworkers and message them and stuff like that, which now seems like obvious, but at the time that was not obvious people, you know, it was very different. But so let me have

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 it was a internal tools were seen as 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 slow moving, boring team. But at meta, it was like our Facebook at the time. It was like probably the most exciting team because you could build product at a speed for building product for seven, eight, nine hundred thousand people. It's 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. They built it. 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 and eventually hardware for servers themselves. So that mentality resulted in a in like 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. Wow. You know, site integrity. Like it really felt like no matter what job you had at Facebook, it was a product engineering company. And I think that's, I think that's still stuck through to this day too. So then just to be concrete, like there was like a specific like a custom version control.

It wasn't like GitHub or something like that, custom code review, custom build tool. And I know Facebook also open source some of this, or at least release some of this, like the build tool, I think was it was a buck and like fabricator. They also released for something. But like everything was just like completely custom, right? Or like internally like built for to work however you wanted 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 time, I can't remember if they used Git first, but they basically

jumped to me 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 like hack, hack, hack into it things that they wanted. So it was still the same ethos even though it was not everything. The Git people were not as open to making

some of those changes. So 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 stat sig and I think

there's some others. So SatSig is experimentation, right? or it was seated by the experimentation platform. Yeah, gatekeeper internally. I mean, these are not like people are not one. I also know graphite. They're a team five meta founders who are bringing the concept of stack diffs to production.

Like, again, inspired by this. It feels like there's a lot of teams who saw like 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 seems like there's demand for it. Mark Zuckerberg said in, it's like a, why 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 like training people, how to build a really good product. And kind of training people to potentially be really good founders. And I thought it was like a bit weird at times because he also didn't talk that much publicly at the time. And I was like, oh, but like, 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 a 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 like really robust, strong products that are kind of, you know, coming out and 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 and that it was awesome as well? Someone told me. Yeah. Yeah.

Yeah, there was. My intern project when I started was also a meeting scheduling tool because it was like, you just wanted to click on three people, find a meeting for them. I find a time they can meet, find a meeting room done. So I actually built that tool, yeah. It's like when I first heard this, I just had such a hard time believing because this Facebook was already a lot bigger that, A, someone would build this, B, people would also use it and C, there will be a team, team maintaining.

it and somehow that all happened because it kind of sounded like anyone could build is in any company but maintenance would be a pain you know funding a little most companies would have a lot of politics of in terms of like okay we need a staffing for this team we need budget we need to justify in the end a few years later oh let's buy a vendor solution or something so it it really surprised me that even for a relatively small but really important thing it kind of happened there Yeah. 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's also, there are those challenges to 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. Like the meeting rooms, for example, right? 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 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 meeting rooms. And you start diving to the next level of product problems. Like what if people book the room and don't show up? Like, 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. And, you know, and then, so now you start getting into, okay, 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 into all those details, too. And I really love the product detail. 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, you know, 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 like either collaboration or some stories of

interacting or working with him what is yours yeah for sure so yeah I'm actually friends with him because I was there early and I did cross paths a lot and got to know them a little bit over the years. So, I mean, I can tell the story of how we became Facebook friends. That's kind of like a thing.

Oh, okay. Start as an intern. It's all these interns from school. Even though, like, Mark was like two years older than everyone or something. He was not, he was like a college job out. It wasn't like he was like a, you know, industry veteran. But it was still, you know, 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 I, the way that he kind of became friends was he used to play Risk, the board game. 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 had I 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 turns 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. And, you know, I think, and he accepted my friend request very shortly that evening, I think. But the reason is just like showing kind of, it kind of, it's weird because I like basically backstabbed him in the game really bad. blatantly into his face. But it's the game. That's like what risk is. And it's a strategy game.

And I think that, you know, he appreciated the strategy that I had, that I, 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 with in product reviews,

both myself doing product reviews and also product reviews with other people. He asked a lot of questions. He's very detailed. focused, he really dives into like trying to figure out. 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 there was, he was the only person doing them. But there was maybe like 10, 20 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 edge manager would do them. And sometimes members of the team would join if it was relevant. So it would kind of, 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 feedback.

But 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, you know, 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 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. You would see that sometimes. Like in like the nicest way possible. Like it's very not mean, not aggressive person. Just, you know, 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 and not sugar-coding 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, yeah. So you mentioned, you know, 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? There was 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 and 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 good recovery. And 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.

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. And our 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 direction. You can go in both directions, starting at the profile to the template or starting at the template to the profile. So sounds simple. Sounds like Systems Design 101 kind of systems design interview that at formation we're like helping people with all the time. You know, it's like a classic problem. And then like 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. You start with the profile, then 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 this 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 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 note 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 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, generally not by object type. So that machine. machine basically melted. I don't know physically. I didn't hear if it may have physically melted. No, probably not. But it, so that machine like crashed and then, 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 happens. Wow. And yeah, so it's interesting. Now, the interesting thing is like,

it's a really bad bug. And 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 when you talk about these things, like this sounds like the most basic systems design system. Like, you know, you have federation and is the common, and partitionings are very common topics.

Like, you know, and this sounds like an obvious thing. Like, why would you potentially have a two-way edge on a system, and like on a system that where one of the nodes might be like super heavy? This is not an exact example, but Twitter had a lot of outages with the fail whales back then because they had a system that was similarly vulnerable

when Justin Bieber tweeted or something. They had a similar system where that... Yeah, because they had the fan out problem, right? So similar, yeah. I mean, these are like known problems. Like, you know, why? And it's interesting because it's a... I see so many people kind of preparing

when they're thinking about systems design interviews and stuff. They're like thinking about like the textbook answers for all these 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, like, behavioral metrics, all these things that you would do. and you have to put a lot of time and effort into thinking about what are those things where do we log them um 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 is the number of people who have used this you know it's it's it's simpler for a prototype um 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 and those kinds of things. Totally. Simple. 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, you know, start to use those, you know, profile. Yeah, this was, so this actually was beyond my area. The DB, 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 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 reboot. 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 that the kind of site reliability team had one of the most well-stocked bars in the entire like alcohol bars in the entire company they just kept arriving oh thank you for this thank you for that yeah it was and I'm actually not joking it was extremely well-stocked I don't know if that's still allowed or what if they yeah a lots of favor is there that that that that that that that's a good one so something interesting you told me uh before this one is that when it came to hiring uh 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 uh 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, you know, hire or 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? Yeah, 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 used to have cool names, right? These used to have cool names.

I remember they were Jedi. Jedi. pirate and, uh, and, uh, ninja. Ninja was coding pirate was system design and Jedi was the soft skills. Yeah. 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, uh, two like critically interesting things that are about meta's interviews, specifically, the technical ones that really throw people off to are their whiteboarding style and there's almost no small talk. And these two things can throw people off in the technical interviews. A lot of the times you have 45 minutes. You're expected to 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 of it because some people are, well, everyone's nervous. I don't know anyone who.

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 one thing. 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 like guess and check and run 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 really, or better, then you'll go to hiring committee. If you got a, there'll be like a quick debrief with the people. So with the people, the interviewers, I mean. So the interviewers will quickly sync sometimes over email even. Were there any red flags? Were there any strong nose?

You might just end the process there. So usually 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 known. 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. An okay thing or maybe even a good thing.

So 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.

And oftentimes, like all the recruiters who were representing a candidate to try to get approval for hiring would bring their candidate there with 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 a, you know, secret, secret handshake, like not figure out what door to go to. Like, sometimes it would move a lot of minute 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 Canada in hiring committee is a recruiter will present a packet. This is actually pretty interesting. I have 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 a legal constant. institutional number, but it was, that was just like, they wanted more, they wanted a quorum of, of

decision makers. Um, and recruiter would present the packet to them. Uh, a packet has a bunch of information. It has all your interview feedback. It has, um, this is like super, super interesting, but it has the, the interview history of the interviewers themselves. It has the histogram of the interviewer's feet of, uh, past ratings. So, like, Like, is this interviewer like super binary? They're 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 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 thing inconsistencies I can give tons of examples of what those are which

are you know this is 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 are pretty important but might take hours so I won't go into all of them but yeah they're looking for flags and like different things the most common thing that they're kind of looking for is level I reiterate the fairness and consistency that that meadow wants to have in its hiring process and and they want to bring in someone at 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 is 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 mid-level? And maybe we'll reject. Or are they actually at the senior level? And this is simple.

Or did they interview 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 like 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. Like what, this sounds kind of boring maybe. But I was like very interested in making sure that the, I was like 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 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 you're it might be them it would be you like it's like you don't really there's too many ways to overthink it but um 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 10x 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 um sometimes it didn't and 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 like really uniquely coaching people helping people the fact that you were in the room is a big difference.

Yeah. It also, yeah, it really helps people kind of just, yeah. Even if it's just to reassure them when they're, 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, like, you know, get that it might not be that they, might not be that they, might not be that they failed or that it's just like a 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 that 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? Yeah, there's a, it's a pretty similar. So I think the lineage is pretty interesting because, like, it kind of, the interview processes are fairly similar in a lot of the top companies. And there are some differences here and there. And some things have changed a bit over the years.

But generally speaking, you know, Leakode wasn't a thing. It didn't exist as a word until 2012, I think, was when they were founded. And the problems haven't changed. The interview styles haven't changed since before Leakode, since after Leakode. it's pretty consistent kind of style that has been around. And Facebook didn't invent these things. They kind of borrowed a little bit from Yahoo. Yahoo is like one of the big, quote-unquote, successful companies

that kind of was on the shrinking side at that time when Facebook was growing. So they borrowed some things from Yahoo from Microsoft from Google. Google was the preeminent place to work at the time too. So, you know, 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. 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, 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 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 that don't

really have the same the same ethos. Yeah, so we actually see it pretty, the variations of these. Some companies do some more practical non-DSA-A style stuff, but. Yeah, so it sounds like it's smart to, if you want to get into one of these companies, is 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. Yeah. 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. We'll help them with prepare for like these data structure algorithm, 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. Like we, I mean, from a business point of view, that's like the dream is you want to have a service.

Yeah, 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 like a personal trainer. Like you want to get in shape.

Like you might have been an amazing shape 10 years ago. You remember what it was like to have the habits to be in shape, to 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 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 um 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 kind of check when you're making a career transition to a new job, like getting back in shape again, it makes a lot of sense. Yeah. And I know, you know, people complain about how interviewing is different than the job, but it is and it's how it is.

Like, I think you can either fight it or accept it. So. But speaking of this topic, what advice you do we have for more experience? 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 our 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.

I mean, when I joined out of school, it was like, I think there were so few engineers I know people who are trying to get H-1B visas were just being handed them because they had such a surplus. Wow. And now there's like a 20x over-s subscription of people trying to get tech jobs in the U.S. And specifically as one example. But like there was a different vibe back than 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. Oh, interesting. 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 pass the onsite, but now there's another, you know, you're kind of in limbo for a while until you actually match to get the offer.

And then there's some, yeah, so we're seeing, we are seeing like 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 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 code signal or hacker ink, and they fail one and they're like, what is going on? I've never seen this tool before. And we're like, you know, you 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 or 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. The release bot. Yeah. So it's like I got to and then after that I think I stopped like counting. But it was a lot. Yeah. In the thousands. I think it's still. I think I right. I honestly, write more code now, though, even after leaving Facebook app formation. I'm writing a lot of code. So, yeah. Yeah, so like multiple divs per day, basically. For sure, yeah. It's probably around 5 to 10,000 a year, like in the double digits per day. But yeah, that doesn't really mean that much. Some are small. Some are gigantic. It's like hard to, yeah. Yeah, but your code actually

did meaningful work. You know, that that was part of it while you got from a difference. Yeah. Which language did you write the most code in when you were at meta? And which one do you write the most coded now? So then HAC, which Ph.P. It evolved into hack, which is their version of it. Hardly any JavaScript.

And then after leaving, I kind of had to learn JavaScript as almost like a junior and react and get up to speed on that. And now I'm very all JavaScript, yeah, front and and and back end. And which one's your favorite programming language? What's the reason?

So it's grown on me, but I would say write, I would say type script specifically, which I don't really call it a language, but so at meta, I wrote, this sounds like, I sound like telling the like long time ago

stories as like 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. Wow. Now that I've

slowly warmed up to TypeScript, I actually really like it because it helps me catch a lot of, hardly any guardrails. I still can code almost as fast as I would with no types, but it actually catches, bugs,

it helps kind of catch things. Also helps me, you know, be a little less lazy if I'm just going to throw some parameters onto a function to think a little more about, like, do I type, how do I type these,

do I move them into like a structure, you know, that type of thing. But yeah. 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 sticks with me is a lot of the stories in there don't seem to make a lot of sense factually.

And I'm like a very factual, literal person. And when I read this, I'm like, wow, these stories don't seem to be real. But like everyone's trusting these. And it showed me that like storytelling is really important to try to communicate things that are happening, whether the like 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 like communicate stories. So that that kind of showed me this like the power of storytelling historical events. Thanks very much for being on the podcast. This was very, very informative and lots of fun.

Yeah, thanks for having me. It was a great time to revisit some old stories and, yeah, 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 to 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 to the show notes. If you will enjoy 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.