Getting a job at Automattic
I’ve been with Automattic for some time, and it’s been a fantastic ride. Since I joined, people have asked me about the hiring process, so I decided to write about my experience.
I’m not part of the hiring team, and these are my personal opinions about the process. Whether the process is the same for you depends on the team and the position you’ve applied for.
Application
I applied in July 2020 after reading this NYT article, where our CEO Matt Mullenweg talks about the hiring process. (Learn more in this post.)
The application form is clear and straightforward, and beside the usual contact information, CV, and cover letter, I received three simple and direct questions:
- Tell us about an interesting app you’ve worked on.
- How do you use our products?
- 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 elaborate.
Tip: Be yourself. 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 your personality.
Interview
Within a week, I heard from the team and booked a 90-minute chat interview in Slack. I picked a slot and was invited to Slack three days before the interview.
You get access to a few Slack channels, where you can hang out with other candidates and employees, and learn 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 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, 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 go 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 the 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 toward 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 reached out to tell me the interview went well and confirmed I would be moving to the next step: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 entailed a new feature to an existing ObjC app. There were no constraints on time or implementation details, although in my experience 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 was entirely up to me.
After completing the main task, I browsed 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 eight 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 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.
The feedback was very specific. You could tell this person reviewed my code in detail. I got a list of things that went well and t pointers on what could be improved. Fortunately, the “good” stuff was longer than the “bad,” and I moved to a 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 decide how much time to put in, so It’s ok to work 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 work.
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.
In addition to the project information, I had access to a few Slack channels and the P2— a special flavor of WordPress — to document my progress and share learnings.
Tip: Expect the setup process to take some time. Coordinating code reviews, finding a buddy, and getting my contract signed took about 10 days.
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 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 next steps.
Tip: Take your time to do things right. Plan and communicate your decisions. Make sure to set aside time to polish your work, write about your learnings and findings, and especially, 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: Document your code and PRs, so that your buddy can review them easily. Remember that in addition to 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 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’d made it! 🎉 💪
Final chat and offer
A few days later an HR rep 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 and 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 received 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 hiring process in my experience. 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 beside the outcome, you’ll learn a lot from that.
After joining Automattic, I understood 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 progress quickly when you join.
Automattic’s hiring process is amazingly inclusive and removes a lot of bias, which is difficult 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 understand 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 at any time.
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.
Photo: My Home Office in Bogotá
This post was also published in Automattic’s mobile.blog