Before we start: as an experiment, below the takeaways, I’m including a more detailed, bullet-point summary in this issue. This is an experiment: please let me know how you like it!
Stream the Latest Episode
Available now on Spotify, YouTube and Apple. See the episode transcript at the top of this page.
Brought to You By
• Vanta — Automate compliance and simplify security with Vanta.
• WorkOS — The modern identity platform for B2B SaaS.
—
In This Episode
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!
Takeaways
Here are my biggest takeaways from this episode:
1. The importance of archetypes at Meta. Archetypes are initially modelled after existing engineers at Meta, and they serve two main roles:
Fairness: offer a way for the company to “patter match” upcoming engineers against these personas, and have a fair system to determine who is at this higher level, and who is not
Career path: offer a non-manager career path that goes beyond the Staff engineer (E6) level. Before archetypes were a thing, it was unclear how to get promoted to E7 and E8 and above levels – where E8 is the equivalent of Director-level (D1) roles
Archetypes are ingrained in Meta’s engineering culture and are a major differentiator compared to other Big Tech companies that lack such nuanced differentiators at the Staff+ engineering levels.
2. There’s a limit on how much influence an IC can have, even at Meta. Despite offering IC career paths that are better-defined at the Staff+ levels than most other large tech companies: at the Principal and above engineering level, there are still more directors than engineers. Michael used to think this is unfair – but, over time, he realized why this is. As he put it:
“Even if you write 10x the code or 100x the code, you cannot replace 3,000 engineers with one engineer. So you can be a VP of engineering, though, overseeing 3,000 engineers. No matter how you multiply it out: even if you are just are the manager of 10 ‘superstar’ engineers, you still have more influence/impact over the direction of those people in the company.”
It’s helpful to understand the realistic and necessary limitations of the individual contributor path in terms of influence, within a large organization.
3. Tenure can become surprisingly important at a fast-growing scaleup. Michael recalled how when he became an E7 (the equivalent of a Principal Engineer at other, similar companies) – he became a part of a tightly knit group of E7+ engineers. Here, the cultural divide between those that had been at Meta for a long time – and promoted into this position – and those hired externally was strong.
Many of the external hires struggled to make the kind of impact that tenured E7+ engineers could, and lots of external hires ended up leaving the company relatively quickly.
Michael observed this during the earlier phase of Facebook/Meta, when it was growing very quickly. While the culture might have changed: this highlights how challenging it can be to “pick up” the culture of a fast-growing scaleup from outside, and how being with the company for a longer time can help you get more stuff done efficiently – and thus also grow faster in your career.
4. Causing an outage at a fast-moving scaleup is not the end of the world. Michale shared an amusing outage when he accidentally overloaded a node (a virtual machine) thanks to shipping a prototype version of a photo mask on Facebook profiles, to add support for a cause. The feature blew up a few days after setting it live, because it could not handle a node being written millions of times per hour, to update two-way graph nodes between a user’s profile and this image template. On top of this, this failure caused cascading failures.
Rolling back this change was not an option. In this case, the database infrastructure team stepped in; made the edge one-way (rather than two-way) and thus removed the write bottleneck.
Michael learned an important lesson: and in the end, it was still a net win for Facebook to realize that this feature is wildly popular a day or two after the launch. Spending a lot of time building a feature that might never get used would have been a worse investment – during this early growth stage at Facebook, that is!
5. Interview processes have not changed much over the last decade! Michael coaches engineers to prepare for interviews, so he has first-hand experience in this. With his words:
“The interview styles haven't changed since before Leetcode, and since after Leetcode. It’s the style that has been around. Facebook didn't invent these interviews: it borrowed a bit from Yahoo, Microsoft and Google. Google also borrowed from other companies at the time.
These days, we see a lot of AI companies, have daily “Facebook-like” processes and vibes: such as OpenAI.
The interviews are the ‘Leetcode interviews’ where they test language-agonostic problem-solving skills.
It’s always been the point to test for these kinds of problems: because it’s what engineers do! Solve problems, regardless of what specific tech stack or programming language you use.”
A consequence of the interview process not changing much, but the job market becoming more competitive is how the bar to do well on these interviews went up. This is because there are more and better preparation materials, so the “average” candidate does better on these interviews than years before. Preparing for interviews at Big Tech companies and scaleups is no longer a “nice to have:” it’s a necessity for even strong engineers, who want to get a job offer.
A summary of the conversation
For those of you more interested in reading a summary of the conversation, see it here. This is an experiment — please leave a comment on how you find this addition!
From intern to E7 in 6 years
Michael joined Meta (then Facebook) as an intern and, remarkably, reached the E7 level (equivalent to principal engineer) in just six years. This rapid career progression is unusual, as a path like this would typically take at least a decade.
His relationship with his managers was critical, built on mutual trust and transparency. His managers knew he was passionate and sometimes impulsive but trusted his judgement. Michael also felt that he could help his managers in their jobs. He was receptive to direct feedback, allowing him to address issues quickly.
He maintained a "notepad" of his accomplishments, noting down significant fixes, bugs, or other contributions. This helped him summarise his work and make sure he was hitting the requirements of the next level, and he would review these with his manager.
From his first days as an intern, Michael demonstrated his coding skills. On his second or third day, he noticed the company's org chart tool was clunky and inefficient. Without asking for permission, he rewrote the tool, creating a horizontal layout and shipping it. This was very well received by colleagues.
As a product engineer, Michael worked on various teams, including internal tools, Facebook Groups, News Feed, Facebook Workplace and Messenger for Kids. He spent about 30% of his time working on his assigned product teams as a senior engineer would. The remaining 70% of his time was spent on large-scale refactoring, code cleanups, and company-wide projects.
Michael became known as the "coding machine" at Meta. The company developed this archetype, in part, to describe Michael's unique impact.
The "coding machine" archetype is for engineers who can move projects forward, unblock other people, refactor code quickly, and help launch products that may typically require a team of engineers.
The archetype was created after comparing him to other engineers at the E7 level, focusing on the overall impact he was making, which was similar to other E7s but not within the existing archetypes, such as "fixer".
While anyone can write a lot of code, what makes a "coding machine" is the impact the code has. This impact is measured by how much it moves projects forward, helps launch products, unblocks people, and speeds up refactoring.
The "coding machine" archetype was championed by an executive, Tom Allison, who helped connect the dots to make the archetype a reality.
Michael explains that at Meta, engineers are compared to professional sports teams. While everyone at a high level is good at basic tasks, people have specialities. Michael's was moving prototypes forward and refactoring code really fast.
Meta’s engineering culture
Meta has an engineering-first culture, where individual contributors are highly valued and empowered. The company wanted to create career paths for talented individual contributors, so that they did not have to become managers to progress.
Internal tools at Meta are treated as products. They were built with the same code base as user-facing tools. This made the internal tools team one of the most exciting to work on because engineers could build product at a much faster pace.
Meta built most of their infrastructure from scratch which resulted in custom tools. Because internal tools were seen as products, it gave the company an engineering product ecosystem.
Michael's intern project was an internal meeting scheduling tool, designed to quickly find meeting times and rooms for groups of people.
Michael recalls that Meta had custom version control, code review and build tools. While the company used SVN as a backbone, they used Mercurial locally on people's machines to manage their local branches. The company chose Mercurial because it was easier to work with the open-source team to hack into it, which aligned with Meta’s culture.
Many internal tools that Meta created have seeded other companies. Examples include Statsig (experimentation platform) Honeycomb (observability.)
The values of moving fast, breaking things and being bold were all reinforced at Meta. If you moved really fast and broke something, you would not get fired. If you were making a bold bet and pushing limits that was also rewarded, even if it didn't work out.
Michael shared a story about how he became Facebook friends with Mark Zuckerberg. During a game of Risk, he formed an alliance with Mark, only to betray him later to win the game. Despite this – or perhaps because of it! –, Mark accepted his friend request that had been pending for some time by then.
At Meta, product reviews are a regular part of the development cycle, also known as "Zuck Reviews". These 15-minute presentations allowed Mark Zuckerberg to give direction and feedback on products. He asks a lot of detail-focused questions to figure out the exact details and make sure that the best possible product was being built.
Michael caused quite the outage, one time. A prototype feature he built allowed users to overlay a photo template on their profile picture. When a large number of users used the French flag template, the system crashed because Michael designed the database to have two way edges for the prototype. One of the nodes got overloaded causing cascading effects. While a two-way edge was not recommended to use, Michael explains he made this decision to simplify things for a prototype.
The interview process at Meta, during Michael’s time
The interview process at Meta typically starts with a recruiter screen, followed by a technical screen (a 45-minute coding interview, usually with two questions). If that goes well, candidates then attend an on-site interview, which includes two more coding interviews, a behavioral interview, and a systems design interview.
During Michael’s time, these interviews had the names “Jedi”, “Pirate” and “Ninja”.
Meta’s technical interviews are distinct because they are whiteboarding style with almost no small talk. Interviewers jump into the technical questions and expect candidates to walk through a clear problem-solving process, without compiling the code to check if it works.
After the onsite interview, there is a debrief where interviewers share feedback. If there are no red flags, then the candidate goes to the hiring committee.
The hiring committee consisted of a quorum of at least three director or VP-level engineers. A recruiter presents a packet about the candidate. The default at this stage is that a candidate is likely to be hired.
The packet contains detailed information, including feedback from the interviewers, the interviewer's history, questions asked, and how many times the questions have been asked. This helps the directors calibrate and interpret the feedback.
The hiring committee looks for flags and inconsistencies but the most common decision point was determining the candidate's level. Michael was often present to ensure that Facebook did not lower its hiring bar as it scaled. He would sometimes give his feedback which would have an impact.
Michael notes that his time in the hiring committee has been helpful in his current business, coaching people, and that he can offer a different point of view.
Advice for software engineers to grow professionally
Michael advises that finding the right job for the right alignment is more important than just checking the boxes and passing an interview.
He notes that the interview processes at many top tech companies are similar, originating from Yahoo, Microsoft and Google and the style has been consistent. This style focuses on testing language and stack-agnostic problem-solving skills.
Michael compares interview preparation to going to a personal trainer. He advises that engineers must get back in shape to prepare for interview processes, regardless of how much experience they have.
The job market for software engineers has changed and is more competitive. There are now more steps in the process. Companies are using online assessments and implementing team matching.
Michael's most productive year, he made thousands of code commits (diffs). While at Meta, most of his code was in Hack, a version of PHP. He now primarily codes in Javascript. His favourite language now is Typescript.
Michael advises that storytelling is a key way to communicate, influence and share as humans. He recommends the book The Histories by Herodotus.
The Pragmatic Engineer deepdives relevant for this episode
• Inside Meta’s engineering culture
• Stacked diffs (and why you should know about them)
• Engineering career paths at Big Tech and scaleups
• Inside the story of how Meta built the Threads app
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
Resources & Mentions
Where to find Michael Novati:
• X: https://x.com/michaelnovati
• LinkedIn: https://www.linkedin.com/in/michaelnovati/
• Facebook: https://www.facebook.com/mn/
Mentions during the episode:
• Software Architect Archetypes: https://newsletter.pragmaticengineer.com/p/software-architect-archetypes
• Formation: https://formation.dev/
• Get your work recognized: write a brag document: https://jvns.ca/blog/brag-documents/
• A Work Log Template for Software Engineers: https://blog.pragmaticengineer.com/work-log-template-for-software-engineers/
• GitHub: https://github.com/
• Mercurial: https://www.mercurial-scm.org/
• Statsig: https://statsig.com/
• Sentry: https://sentry.io/welcome/
• Graphite: https://graphite.dev/
• Mark Zuckerberg at Startup School 2013:
• Mark Zuckerberg at Startup School 2012:
• Risk board game: https://en.wikipedia.org/wiki/Risk_(game)
• Wecode: https://wecode.io/en/
• CodeSignal: https://codesignal.com/
• HackerRank: https://www.hackerrank.com/
• Hack: https://engineering.fb.com/2014/03/20/developer-tools/hack-a-new-programming-language-for-hhvm/
• Javascript: https://www.javascript.com/
• Typescript: https://www.typescriptlang.org/
• The Histories: https://www.amazon.com/Histories-Herodotus/dp/0140449086
Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@pragmaticengineer.com.
Share this post