Interview experience at Automattic

Interview experience at Automattic

The interview process at Automattic is little bit different than traditional SE interview process you find all over the world. The whole process is async, and it is long (a couple of months) and can be tedious.

This is my story- the official process can be found here.

Background

I became interested to look for full-remote roles after reading this blog post from a fellow countryman.
Please do read it if you want to learn more about remote jobs.

Application

I applied online for a Senior Software Engineer role. A couple of days later, a recruiter reached out over email. They asked me to pick a time slot for a 90-minute text-only interview. Once I picked a slot, a meeting was scheduled and I was added to a Slack workspace. A dedicated slack channel was created for my interview (these things were all automated, cool eh?). My interviewer and a few HR folks were added to the channel at the same time. They dropped a few links in there for me to read at my leisure - mostly about what to expect in the interview process.

Technical interview

On the scheduled day I sat for a 90-minute text-only interview. This was a slack conversation with another engineer. It’s based on various topics you typically talk about on the screening interview like my background, my interests, philosophies, etc. For example, we talked about my experience with typical day-to-day job of a SE like unit testing and CI/CD etc, a complex bug I had encountered and how I ran troubleshooting, and how I fixed it. You get the idea.

I sat on the other side of the table many times for NewsCred, and I could tell I was doing well. After a few days, my recruiter got back to me (on Slack) and confirmed the next steps.

Code test

For the next step, I was invited to a Github org for a code test. I had to fulfill some objectives in a repo (an unknown toy codebase). Again, the invitaion and repository creation etc were all done via an automation - which I thought was very impressive. I was given an online editor so that I don’t have to set up anything locally (tho I coded locally in the end and pushed frequently to see the changes live).

I hadn’t written PHP in a while, but I was told not to worry about the programming language. I had to write a bit of PHP and JS code and add unit tests and then opened a Pull Request after 2 or 3 days.

An engineer reviewed the PR and left feedback. They even did QA and gave feedback that I missed a bug. I worked on that for another couple of days and fixed it. This time around, they were happy with the results and gave me a green signal for the next round.

This is not paid project and took about a week to finish.

The codebase was not super clean but I think it is an example of how all code tests should be. People should not ask candidates to build something from scratch, rather provide them with the base and ask them to add/fix/improve on that.

The trial

The trial is the most important part of this process and a test to see whether the candiate is a right fit for a full-time remote role. Again I had to fulfill objectives in yet another unknown toy codebase, this time a much larger repo. I was assigned a trial buddy (who would act as a Product Manager), I was given full freedom on how I wanted to implement the objective.

I would incrementally make progress each week and ask for code review on an open PR. An engineer (the trial buddy) would review the pull request and leave questions and feedback. Same as the code test, my coding styles, unit testing, git commit messages, etc were under the microscope.

Another important part of the trial is to evaluate how I was communicating. I was asked to leave a cumulative updates every week (in an internal blogging tool named P2), on what I am doing and how I am approaching the problem each day (so my reviewer would know my thought process). It was also important for my recruiter to see how I was communicating with my trial buddy (over Slack, Github, and P2) to determine if I would be a good fit.

The trial involved reading a lot of legacy code. I also had to make some architectural decisions and had to document why I choose one path over another in the P2 blog.

This part was paid. It took around four weeks to finish (people usually do it in about six weeks). With this passed, you are sure to receive an offer.

Informal chat with DevEx team

This one was a video call. We talked about my interests to find the right team for me.

Offer from HR

This was another slack chat. We negotiated terms.


Work with us

Remote jobs — work from anywhere.
Want to make the web a better place for more than a billion people each month? We’re hiring.

Here are some job application tips from Automattic’s Talent team.

Author

Mehedi Hasan Masum

Posted on

2022-02-26

Licensed under

CC BY-NC-SA 4.0

Comments

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×