Episode description

Links:

• More about Leif
• How Automattic Hires Developers
• The Automattic Creed
• Open Positions at Automattic

Detailed Show Notes:

• Leif switched from an academic career to industry (0:50)
• He explains his reasons for the switch, and we discuss that it is difficult to choose where you want to live when you want to become a professor (2:47)
• Leif got his new remote job in the industry at a startup called IDoneThis (3:20)
• The startup was sold, and the team discontinued, so Leif found himself again looking for a new job (3:50)
• Well, as luck would have it, Life got in contact with Automattic, the company behind WordPress.com (4:09)
• Leif applied and interviewed for Automatic although he wasn't familiar with the company's tech stack (4:40)
• Leif explains the interview process at Automattic (7:03)
  • First, you send an email to jobs@automattic.com  (including a resume and a cover letter)
  • If you are invited for an interview, you get invited for a slack chat (a screener) where you talk about your background and your skills
  • Then, you get invited to do a small project which takes 4-5 hours over a week. It's a small project with concrete instructions that you must follow. For example, improve some parts of a feature.
  • If that works out well, then, you are invited to do a trial, where you work alongside an Automatic team for a period of 1-3 months for ~10 hours per week. This trial is paid with 25 Dollars per hour.
• Leif fills me in that you aren't working alongside your actual team. The team you are then hired into can be a different one, but you work with an actual team at Automattic and on an actual project. So, if all works out well, your code will be used in production. (9:40)
• Leif describes the tech stack of Automattic, and which skills and technologies you must possess to be able to apply for a position. (10:40)
  • Leif says that the projects at WordPress are very diverse. The tech stacks and the tool chains are therefore very diverse as well. One of the critical skills for any engineer at Automattic is, therefore, the willingness and ability to learn.
• Leif moved within the company and worked on very different projects. Each project you can learn something new, he says. Not only because of the diverse tech stack but also, because each project might serve a different customer base and have a different purpose. (12:20)
• If you want to move to a new project or team, you send a private message to Matt, the founder, and he helps you find a new place within the company (13:01)
• Leif rationalizes that at Automattic, you usually aren't communicating per email. No, they use either chat systems like Slack or internal WordPress sites to communicate and keep track of everything (14:00)
• We talk about how communication processes and channels might differ from a non-remote and a remote company. I wonder, is Matt actually replacing some of the water-cooler conversations you would have at a non-remote company? (14:32)
• Another topic I want to discuss with Leif is how engineers at Automattic keep in contact with other employees if they aren’t in the same building? How do they "hang-out" together? Is there a place in cyberspace that they usually meet at? (15:00)
  • People connect and stay informed through weekly calls, one-on-ones calls, and company-wide town halls that are held once a month
  • Each team and each larger project have its own blog, where you can find all information about everything you have to know
  • Two times per year, each team meets, and once per year all Automattic engineers meet and make a connection with each other.
• Leif walks me through the engineering processes and tools look like at Automattic (17:18)
  • Again, as the tech stack is so diverse, also the processes and tools diver from project to project
  • Some are using Git; some are still using Subversion. Obviously, something like this hugely impacts how the whole engineering process looks like.
• Is Automattic planning to consolidate its technologies and tools? (19:37)
  • Leif clarifies that because they are an open-source company, it's not that easy. Consolidation isn't something you can just put on the agenda. First and foremost, the goals of the company have to align with the goals of the open source project. So only if the open-source project would move from Subversion to Git, Automattic could move as well.
• We discuss how having open source as the foundation of your company creates some tension between the goals of the company and the open-source community. But, embracing open-source also changes the whole company values. Leif describes how transparency is the basis for everything at Automattic. Transparency is reflected in communication and the decision, and although it might not directly influence how people develop software, it hugely impacts the company culture. (20:43)
• Automattic grew quite substantially, so I ask Leif if the culture of the company evolve and change as well?
  • Yes, of course, says Leif. But on the other hand, they still hold on to their main values. The Automattic Creed, a sort of gospel that describes the main values and mindset of the employees of Automattic, helps steer the employees in the right direction.
• Leif reads the Automattic creed to me (25:04)
• I wonder if Automattic has something similar to the Automattic creed when it comes to their engineering processes and practices such as testing or code review? (26:28)
• Leif explains how testing works at Automattic. 26:38
• But what about test coverage? Does Automaticians care about that? Leif says no, because it feels like one metric isn't a healthy indicator. (27:36)
• How does Automattic use code reviews and what does Leif think about code reviews?  (30:08)
  • Leif explains that every code change is looked at by at least one other colleague.
  • Code reviews are very fitting to the learning culture of Automattic. It's highly appreciated engineering practice there.
• I wonder how they ensure – especially at a remote company with many different timezones – that code reviews are looked at in a timely manner. At Automattic, Leif says, they use Trello to track the progress of code reviews, but in addition, they also use a slack app called "the stick" that reminds people if they haven't looked at their code reviews. This normally ensures that you do not have to wait too long for code review feedback. (32:18)
• How does the production process look like, I wonder? And how long does it take to deploy to production? (34:12)
  • Leif says, after review, it's just a merge and a deploy. All is all automated. It's one press of a button. For a few projects, you first might have a staging area for some manual tests and deploy it afterward.
• How do Automatticians handle technical debt? (36:12)
  • Leif explains that they try to move fast, and therefore might create more technical debt than desired. But, once a quarter, they have one week, in which every engineer works on reducing technical debt. Because this is scheduled and expected, they can reduce technical debt and improve the code quite substantially during those times and keep technical debt at bay.
• Another topic I’m interested in is how people at Automattic get assessed and how they get promoted? (39:50)
  • Leif describes that at Automattic, they actually have no titles and that switching from an engineering role to a manager role isn't considered a promotion. Somehow promotions and pay raise work quite different here. I like it.
• How diverse is the technical workforce at Automattic? (44:56)
  • Leif says also Automattic isn't as diverse as they want to be. They struggle with similar problems other tech companies struggle with. But they do actively work towards getting more diverse. How? Well, they are present at events with diverse set of participants, they hire without requiring you to show your face, and by having a very hiring committee that consists of at least 50% women.