Getting a job at Automattic

I have been with Automattic for a couple of months, and it’s been a fantastic ride. Since I joined, people have asked me about the hiring experience and what to expect, so I decided to write a little about it.

I’m not part of the hiring team, and these are my personal opinions about the process. Whether this works or is the same for you depends on the team, the position you’ve applied to, and yourself, but here we go.

Application

applied in July 2020 after reading this NYT article, where Matt talks a little bit about the hiring process. (You can read a little more about it in this post).

The application form is clear and straightforward, and besides the usual contact information, CV, and cover letter, I got three simple and direct questions:

  1. Tell us about an interesting app you’ve worked on.
  2. How do you use our products?
  3. What questions do you have for us?

I rarely over-think my answers, so I wrote (in my own words) about a project I have been working on, talked about how I have been connected with WordPress over the years, and sent a couple of questions about the future of the products. Nothing fancy or elaborated.

Tip: Being yourself will get you a long way. Not only at Automattic, but in life in general. Talking about yourself and your experience is not easy, but you will do fine as long as you are transparent and honest. Make sure everything you say reflects on your personality.

Interview

Within a week, I heard back from the team and got a link to book a 90m chat interview in Slack. I picked a slot and got invited to Slack three days before the D day.

You get access to a few Slack channels, where you can hang out with other candidates and employees, and relevant information about your interviewer, the position, the team, and Automattic, including The Automattic Creed. 

Tip: You’ll get a lot of information in the process (even before the interview). Take the time to go through it. It is an opportunity to find out more about Automattic and the team. When in Slack, talk to others (even if it just to say hello), and ask questions. It’s a two-way process.

For the Slack interview, I was paired with someone from the Mobile team, somewhere in Canada. He was patient and took the time to explain the process and answer all my questions.

We talked about my background as a developer, experience on iOS, real-life coding problems, my thought process, and of course, got into more technical iOS stuff. There were no whiteboard tests, algorithm problems, or live coding exercises. It felt like a fun, technical conversation, and time passed pretty quickly.

Tip: Take your time to answer. There is no pressure to write fast. Make sure you get into detail and give examples if that helps you explain your point. And again, make sure to ask questions. You will be talking with someone close to your team, so this is an excellent opportunity to understand what day to day looks like and dig into the company culture.

After roughly 90 minutes, he told me that they would be reviewing the chat, and I should hear back towards the end of the week. As you can imagine, the first thing I did was re-read the entire interview while silently regretting most of my answers. ๐Ÿคฆโ€โ™‚๏ธ

Code Test

After a few days of anguish, my recruiter pinged me to tell me the interview went well and confirmed I was moving to the next step, which would be a code test. ๐Ÿ˜…

Tip: Keep an eye on Slack. Most communication relevant to the process will take place in the Slack channel.

The code test was about adding a new feature to an existing ObjC app. There were no constraints on time or implementation details, although the test should not take you more than a few hours.

I was encouraged to check other parts of the app and make fixes or adjustments as needed. Whether I just wanted to implement the required feature, rewrite everything, or add more functionality, It’s entirely up to me.

After completing the main task, I browsed around the code, found some improvement areas, and fixed a couple of glitches to make things a little more stable. 

Since I had to go back to my ObjC books as I haven’t used the language in a while, it took me about 7-8 hours over the course of a week to open a PR with the changes.

Tip: Without constraints or time limits, it might be challenging to understand when is a good time to stop. You may be tempted to rewrite big chunks of the app or even the whole thing, but if you do, make sure it will make a difference. 

Approximately three days after delivering the project, another person from the Apps team reached out with feedback, this time from Taiwan.

Feedback was very specific, and you could tell this person reviewed my code in detail. I got a list of things that went well and then some pointers to stuff that could be improved. Fortunately, the ‘good’ stuff was longer than the ‘bad’, and I got moved to the trial. ๐Ÿ˜ƒ

Trial

The trial is about working together with your team on a real-life project. It’s a part-time paid engagement, and you can decide how much time to put, so It’s ok to work on nights and weekends and set your own schedule.  

The average time people spend on the project is about 25 hours, and there’s a hard limit of 40. They will connect you with a trial buddy, who can be anywhere in the world. Their role is to guide you, answer questions, and give you constant feedback about your progress. 

You should expect communication to be asynchronous. It might not always be the case, but my trial buddy was 13 hours ahead, working from Hong Kong, so everything had to be async.

Besides the project info, you will also get access to a few Slack channels and your P2 โ€” a special flavor of WordPress โ€” to document your progress and share your learnings.

Tip: Expect the setup process to take some time. Coordinating Code Reviews, finding a buddy, and getting your contract signed might take some time. In my case, it took about ten days to get everything ready.

My project was to build a small iOS application using some of the existing Tumblr APIs, and I had complete freedom on the approach, architecture, and design.

My buddy provided constructive feedback and gave me pointers on how to make things better. We relied on the P2 for technical discussions, Github for code reviews, and Slack for quick feedback and suggestions on the next steps.

Tip: Take your time to do things right, plan, and communicate your decisions. Make sure to set time aside to polish your work, write about your learnings and findings, and especially, make sure to ask questions. Your buddy is there to help you. 

Being on trial is challenging and stressful, but my buddy was extraordinarily supportive. I am still impressed with the level of detail and objectivity of the code reviews, feedback, and openness to proposals and ideas.

Tip:ย  Make sure to document your code and PRs, so your buddy can go through them easily. Consider that besides being your trial buddy they have to do their own work, so be concise, polite, and don’t expect to have their attention 24/7.

After about 30 hours of work and several PRs over the course of two weeks, they introduced me to the Head of Apps, who mentioned they’d seen enough of my work to recommend me to Matt, the CEO, and the HR team. I’ve made it! ๐ŸŽ‰ ๐Ÿ’ช

Final Chat & Offer

A few days later (3-4), a person from the HR team reached out to talk about the hiring process, the trial, and find out about my expectations (again via Slack), this time from Florida.

We chatted about my background, interests, and expectations, while she answered all the questions I had. This was not just an additional interview. It was also clear that the idea of this conversation was to get feedback from me and my perspective about the process, which I find truly amazing.

Two days later, I got a formal offer in the mail, and the rest is history.

Final Thoughts

The whole process took place in Slack, Github, and WordPress (No phone, video, or personal interviews), and I chatted with folks working from four continents.

Everyone was kind, patient, and seemed to understand that these things are very stressful to you as a candidate. It’s impressive how perfectly orchestrated it was, especially with everyone spread around the globe.

People being kind does not mean it’s easy to get hired. On the contrary, it’s been by far the most demanding process I joined. I was fortunate to get a job, but I had to push myself to re-learn and get back to speed during the trial in a way I hardly could have done on my own. It was challenging and rewarding, and besides the outcome, you’ll learn a lot from that.

After a couple of months with Automattic, I can understand why we hire people this way. The process reflects your life as an Automattician, which is very valuable for you and the company, as you’re able to hit the ground running and get up to speed a lot faster.

Automattic’s hiring process is amazingly inclusive and removes a lot of bias, which are two difficult things to achieve the traditional way. It’s also not just about technical skills. It evaluates many aspects, including how fast you can learn, autonomy, written communication, asynchronous work, problem-solving, adapting to constant change, teamwork, and much more.

Companies hiring engineers via whiteboard exercises and algorithm tests should think again. Someone willing to sit down with HackerRank or Cracking the Coding Interview for a few weeks will likely pass, but you won’t get a feeling of the things that help create a long-lasting culture of continuous learning, support, and autonomy.

If you’re thinking about applying to Automattic, go for it. Even if you don’t get a job, it’s a huge learning opportunity and there’s always the chance to re-apply.

I’d love to hear your thoughts and answer questions, so please leave them in the comments below, and feel free to reach out on Twitter anytime.


Photo: My Home Office in Bogotรก

Leave a Reply