Jerry Jones

Tag: Automattic

  • Lessons from Hiring Software Engineers

    Lessons from Hiring Software Engineers

    I’ve been a jack of all trades web developer for nearly 15 years and moved to working full-time in hiring in September 2020. At Automattic, we’re hiring as fast as we can. This has given me a chance to work with and evaluate hundreds of software engineers over the past eight months.

    The Day-to-Day: A Bit of Context

    As a full-time hirer, my first responsibility is to kindly assess, mentor, and guide candidates through our hiring process to determine if they would be successful at Automattic. On the surface, it sounds like all I do is run interviews, grade code tests, and guide trials all day. 

    Don’t worry, SpongeBob! It’s actually really interesting!

    While that may be my primary responsibilities, it comes across less as “grading” and more as:

    • Digging into the why behind someone’s code.
    • Becoming a PR Review expert.
    • Delivering kind, constructive feedback.
    • Implementing new ideas on how to accurately and more quickly evaluate candidates. 
    • Formalizing/automating processes to make hiring more efficient.
    • Working on interesting technical challenges to improve our hiring toolkit.
    • Improving my own problem solving and designing abstractions skills by challenging my assumptions of how code can and should be written.
    • Changing someone’s life by letting them know they got the job. 🎉

    The Human Side of Engineering

    Most engineering roles at Automattic are focused on coding in order to help people. In hiring, it’s a bit more meta: we are focused on identifying the best people to write code in order to help people. 

    Kramer can’t believe it.

    Engineering hiring is an interdisciplinary role that allows you to think deeply about how to best evaluate and mentor your candidates. Even when a candidate might not be ready to be an Automattician today, most are eager, kind, and smart. Our goal is to help them learn through useful feedback and mentorship on how they can grow to be successful their next time around.

    If you’re like me and have a hard time with giving direct feedback, then working in hiring is also a huge opportunity to grow as a person. I’ve learned more about how to confidently give effective, constructive, useful feedback in the last eight months than I have in my whole life.

    Giving Effective Feedback

    This should be its own post to dive into the details. Here are a few quick lessons learned:

    • Be positive, and focus on their ability to grow to meet the challenge.
    • Be direct. If the feedback isn’t clear and actionable, you can’t be sure it was understood. And if you can’t be sure it was understood, you didn’t really give any feedback.
    • Give feedback continuously. Don’t save it all for one big review at the end. The “official” feedback shouldn’t be a surprise – they should already have heard it before. This also allows people a chance to correct problematic areas before they become a bigger problem. It also shows you how they are at receiving and addressing feedback.
    • Set clear expectations. What does successfully addressing the feedback look like? How will they know they’re doing it better now?

    What Makes a Good Developer?

    This is something I’ve spent a lot of time thinking about recently. I think it’s different for each organization. For example, you can be a really technically skilled engineer and not get a job at Automattic. And you can be a great engineer for Automattic, and not be able to get a job at another big organization. I don’t think I have the technical skills to pass more algorithmic-focused code tests, but I’m a great match for the kinds of problems that need solved at Automattic.

    So, more accurately, the question should be, “What makes a good developer at [insert organization name here].”

    For us, a brief list looks like:

    • High self-motivation and drive
    • Technical ability
    • Fast learner
    • Great written communication
    • Can adapt and solve problems from many different areas, even if they’re not familiar with the language or codebase
    • Good self-management and dependability
    • Can give and receive feedback well, allowing for a lot of positive growth

    There’s plenty more, but the main takeaway here is that technical ability is one of many pieces. It’s OK to not have the strongest technical ability as long as you have many of the others and, especially, if you can learn whatever you need to learn.

    How do you Evaluate that?

    Having a list of things we’re looking for is one thing, but how do you fairly and accurately determine someone has those qualities?

    This is much harder to do than it seems, and relying on your own intuition of, “I know it when I see it,” is a great way to have a super-biased, toxic, homogenous company.

    I wrote about Qualities of Expertise earlier this year as part of my learning around evaluating expertise. It’s hard, as the problems that require expertise to solve are open-ended, contextual, and don’t have a clear right/wrong answer.

    The best way we’ve found to evaluate this is to have a 25 – 40 hour, paid trial where we give candidates a close-to-real-world codebase with some basic direction and let them solve it however they feel is best. It’s like a paid-mentorship and code camp where you might get a job offer in the end.

    The great thing about the trial is that there are no right answers. There are multiple, valid approaches to everything. It’s less about the direction you choose, and more about:

    • How you arrived at your decision.
    • How you communicate your decision.
    • How you solve/implement it.
    • Does it work? Does it work well? How do you know?

    There’s no accidentally passing the trial. If you receive an offer, it’s because you’ve been thoroughly vetted and deserve the offer.

    The fast-paced learning and self-improvement is keeping me highly engaged in Engineering hiring. My next big step is learning more data and rubric development. I doubt I’ll run out of things to learn anytime soon.

    If you’re a software developer looking to grow in these areas and have the opportunity to work in hiring, I highly recommend it.

    Thanks to Thuy Copeland, Derek Springer, and Boro Sitnikovski for edits and feedback.

  • Tips for Text-based Interviews

    Tips for Text-based Interviews

    Since joining the hiring team at Automattic in the fall of 2019, I’ve noticed different patterns and preferences on text-based interviews. Some of these are also general interviewing tips.

    Send shorter messages

    The pacing of the conversation is improved when you send multiple shorter messages instead of one multi-paragraph message. Answer as you go along. This gives more opportunity for your interviewer to drop pertinent emoji reactions and give feedback/redirect along the way.

    Shorter messages = more engagement and faster feedback.

    If someone starts down the wrong path on a question and answers once every five minutes in a wall of text, then the interviewer isn’t given an opportunity to redirect early on. The interviewee may unintentionally be cutting their interview short since they spent so long answering the wrong question. Also, it’s not a very engaging conversation if you only see a message once every five minutes.

    Tip: It’s OK to type fast and correct typos/edit for clarity as you go.

    Avoid Threads if possible

    This is something I prefer. I watch that “_ is typing,” alert like a hawk. This is your cue to know if you’ll be interrupting someone or not.

    It’s really helpful to know if you should wait for them to finish sending a message or if you should jump in with another message. In Slack, this alert only shows up if you’re typing in the main channel. The threads don’t show it, so you’re not sure if someone is typing.

    Of course, there are some small comments that are better in threads. That’s fine. Keep threaded messages short if you need to use them. If you need to go back and discuss something, instead of using a thread, you can use a block quote for context:

    Quoted text you want to talk about.

    Can you clarify this comment? I’m not sure I understand what you’re asking.

    In async conversations where you don’t need to know if someone is typing (most everything except interviews), then I 100% prefer threads. It’s all about context.

    Show your thought process

    So much of our interview and hiring process is about how you approach a problem rather than the final answer. Do you need more context to make a good decision or provide a good answer? Ask for it! Don’t make an assumption about it.

    In the end, a lucky right answer without showing your thought process isn’t worth as much as a solid thought process that arrives at a different answer.

    Don’t bother name dropping

    We don’t have a checklist of frameworks or languages we want you to mention. It’s about how you solve and approach problems. If you demonstrate a strong learning ability, then we’re not worried about if you’ve worked with x, y, or z, since we know you can learn whatever you need to in order to get the job done.

    Tell the story

    If we ask a question like, “Tell me about a time when…,” act like you’re telling someone a story about it, because you are! Give context:

    • What was the project?
    • Who worked on it? What was your role?
    • Why did you solve the problem the way you solved it? Did you consider alternatives?
    • How did you know you were successful? Specific metrics are 🔥

    In the end, it should sound like a concise story. This allows the interviewer to understand the issue and context so much more than if you only focus on the “What.”

    Also, be prepared to answer follow-up questions related to your story. For example, that specific metric you mentioned earlier — how did you measure that?

    It’s not that different

    A few little etiquettes are different, but, in the end, the same rules apply to in-person interviews as text-only interviews. Most people have never been interviewed over text, and most people do great with it. If you practice telling your stories and can demonstrate a pattern of success, you’ll be fine, text-based or in-person. 

    Thanks to Thuy Copeland, Josh Betz, and Enej Bajgoric, my fellow interviewers at Automattic, for reviewing this post 🙌🏻

  • Across the Atlantic Handoffs

    Across the Atlantic Handoffs

    Automattic is a large worldwide team, made up of smaller, worldwide teams where everyone works remotely. That was one of the things that made me excited to work there, but also very curious as to how it worked in practice.

    Would the timezone differences slow us down? Would we unintentionally get in each other’s way? What if we needed an answer from someone who had already logged off hours ago?

    Working as a Team

    The team of eight I’m on is made up of people from 6 countries:

    • Argentina
    • Czech Republic
    • Germany
    • England
    • United States
    • Greece

    And it’s amazing. We work so well together. This boils down to:

    • Caring about doing a good job.
    • Wanting to help the team.
    • Being responsible and motivated to work independently.
    • Communicating * 3

    I’m a big fan of everyone on the team. We all do the above points well, in my opinion. I’m not sure how well it would work otherwise.

    The End of Day Handoff

    One thing that really helps us work efficiently is our End of Day notes. Everyday before logging off for the day, you post:

    • The status of what you’ve been working on.
    • Any PRs you need reviewed.
    • Is there anything you want to handoff? Lots of notes here, if so.
    • Is there anything blocking or that you need help with? Similar to the above, but not exactly. This could be something outside of a code-related thing.

    This helps us know the status of everything in a consistent way, while also being able to pick-up work or help each other out. We call this asynchronous communication. A lot of things don’t need to be real-time conversations if you communicate clearly enough.

    The handoff works especially well when there are two people spread out over far enough timezones that they have 2 – 4 hours of overlapping time. One person starts work in a more focused way, then there’s enough overlap time for working together and getting on the same page, then handing off to the next person to work on it.

    It also builds a lot of team camaraderie as well as being deeply satisfying when you say you need help with something, go to bed, then wake up and find it’s taken care of.

    Working in Sync

    Earlier on when I’d joined Automattic, I was helping out on a complicated issue where two of us were working actively on the same PR. I was trying to act in a supporting role to get it over the finish line without getting in the way. I tried to walk the line between helping out without taking over.

    I reached out to my co-worker Damián to make sure I wasn’t stepping on his toes by working on the issue.

    “Please, step on my toes.” he said. “I’ll let you know if something isn’t going well, and I ask you to do the same for me.”

    So many places look at being in one office at one location as an advantage, but I’d argue that this kind of open, honest communication and End of Day handoffs allows our team to work more efficiently than if we were all in one area.

    Either way, it’s an amazing team. We’re hiring, so be sure to apply if you think you’d enjoy working remotely on a worldwide team.

  • Getting Hired at Automattic

    Getting Hired at Automattic

    I started at Automattic on November 20, 2019, and it’s an incredible place to work. I’m constantly impressed by my coworkers kindness, intelligence, and compassion. If you’re looking for a rewarding remote job that you can work from anywhere in the world, definitely apply.

    I’m still overjoyed and amazed I was hired. While going through the hiring process, I devoured the blog posts from people describing their journeys. Here’s my contribution to the catalog. I hope it helps someone.

    The Creed

    Before applying, I would recommend reading through the Automattic creed to see if it aligns with you. I think most companies have a creed to pay lip service to.

    That’s not Automattic. The creed really is embodied in an amazing way. It sounds cliché, but it’s true.

    Recruitment

    End of September, 2019

    I was contacted by a third-party recruiter about applying. I believe this may have been an experimental program, and is not the normal process.

    It was the first time that I was contacted by a recruiter who:

    • was kind and supportive
    • really wanted the job to be a good fit for me
    • had a good job offer

    I had actually applied to Automattic a few years ago for a Product Designer role, but did not get past the application step. They were still incredibly kind and encouraging in their rejection. I was shocked and excited to be contacted by a recruiter asking me to apply this time around.

    I sent my resume in, and they passed it along to the hiring team. Within two days, I heard back that they wanted me to fill out their application questionnaire.

    Questionnaire

    End of September, 2019

    I received a questionnaire that helped them and me evaluate if working at Automattic would be a good fit. Automattic has a very unique and wonderful way of working. It’s definitely not for everyone, but it’s something to be discussed and aware of very early on.

    I don’t remember this part taking too long or being too intense.

    Slack Interview

    Update June 2021: Automattic is removing the interview from the engineering hiring process. Candidates are moved directly to the Code Test.

    Early October, 2019

    Within a week, I heard back that I was being advanced to the Slack Interview. The interview is entirely text based.

    A Text-Based Aside

    The entire hiring process is text based. Seriously.

    Never once did I hear someone’s voice or do a video call. Until my first paycheck arrived, a part of me still believed it was all too good to be true, and it was just an elaborate prank. 😂

    They invited me to a slack channel, and I was free to ask questions and talk with the hiring team. They told me how they do what they call “async communication.” You can ask a question, and you may not get an answer for awhile, as the person may be in a totally different part of the world. For example, the hiring team for my trial process was distributed in Europe, Eastern Europe, Oceania, and the US.

    Slack Interview – Continued

    I really enjoyed the slack interview. It was by far the most enjoyable interview I had ever done. The person I chatted with helped me feel comfortable and confident. They knew what they were talking about and used plenty of emoji responses to keep things light.

    The interview felt more like hanging out and talking with someone you met at a conference about what you do, what processes you use and why, etc. It was friendly and, dare I say, fun.

    By the end of our 1.5 hour chat, they told me I was moving on to the next stage. No waiting required.

    Note: I don’t think a fast answer like this is always the case. Just because you’re not told an answer at the end of the interview doesn’t mean you’re not moving on.

    The Code Test

    Early October, 2019

    It’s getting real now. You can talk the talk, but can you… uh… walk the… code? Well, you know what I mean.

    Within a couple days, they sent me the Code Test. It was a github repo with details on the project and what needed fixing. They said to not spend more than 4-6 hours on the test, but, I did spend a little more than that. 😬

    The impression I got behind the intention of the 4-6 hour limit isn’t to see how fast you can code or to make you crack under pressure. It’s out of respect for your time. They really don’t want to waste your time or their own.

    It was hard. I doubted myself. I put too much pressure on myself. I freaked out. I took a break. I figured part of it out. Repeat.

    Within a day or two of submitting my code test, I got a detailed, kind response about things I did well and things I could improve. The intention behind the message was clearly to help me learn. Fortunately, I was being moved on to the Trial phase.

    The Trial: Hot Take

    Mid October, 2019

    The trial phase is a fixed-rate, paid trial at $25/hour and is intended to last around 40 hours. This is a big commitment, and a controversial one if you read around a bit on forums from people debating the hiring process at Automattic. I think it has changed over the years, so here’s my take after having gone through it:

    • The $25 rate is clearly low for a US-based web developer. It’s not supposed to be a living wage and has no impact on your future salary. It is nice that they believe you are a good enough candidate that they are willing to pay you to continue interviewing with them.
    • It’s not an attempt to get reduced-rate work. You get one of a few standardized trial projects that are not intended to be used in production.
    • It’s supposed to mimic the way Automattic works to see if you’ll enjoy working there.

    You’re allowed to do the trial project spread out over as many weeks/months as you’d like. Just communicate what your schedule is going to be. I decided to do it within two weeks so I could get it out of the way and find out sooner.

    The Trial: How it Happened

    Note: I had originally started as more of a back-end developer during the hiring process, but decided to move to a front-end developer role. I was worried they would make me start the process over. Fortunately, they just said “No problem!” and switched me to a front-end trial.

    When you get to the trial phase, they add you to a few slack channels with everyone else on Trial. You are now officially a Trialmattician. This channel is kind of like a #watercooler channel for others on trial. It was incredibly useful and comforting to chat with others going through the same, difficult thing as you.

    The hiring team makes it clear that you are not competing with anyone else on trial. They have a high hiring capacity, so it’s not about accessing a limited amount of positions, but finding the right people who will thrive at Automattic.

    My trial project was another WordPress plugin, but this time it was React-based. I had never worked with React and told them this ahead of time. They weren’t worried about my lack of React knowledge.

    My impression of the trial wasn’t to evaluate how good of a React developer I was (hint: I wasn’t), but to evaluate (among other things):

    • Communication
    • Documentation and showing work
    • Detailing my thought process
    • General coding style and knowledge
    • Ability to work in an async, distributed way
    • How you adapt to a new, unique codebase

    Since I committed to doing the trial fairly quickly, I went faster than they could really provide feedback (this was also due to my trial lead traveling during the first part of my trial). I believe the process is supposed to be more like the day-to-day of working at Automattic where you have code reviews from teammates coming in within a day of submitting a PR (pull request).

    The trial pushed me in a similar way as the Code Test. I doubted myself. I tried to move quickly but just wound up missing silly mistakes. Taking a breath and moving carefully and considerately was by far the best thing I did.

    Overall, it was extremely tough for me. I’m very glad to be done with it. 😅

    When my trial lead felt like they had seen enough to make a decision, they recommended me to be hired. 🎉

    The Matt Chat

    Early November, 2019

    This is still called the Matt Chat even though I talked with someone from HR. The chat involved talking about my trial process, how I felt about it, the good, the bad, etc. I was impressed with how much they wanted to hear my feedback so that they could improve the hiring process. Overall, I remember really enjoying the chat.

    At Automattic, they really care. A lot. They want this to be the best it can be for the candidates putting the time in. Even though it’s not always perfect, it’s filled with good intention and compassion.

    We talked a little about a potential start date and expected salary, and that evening I received and accepted my offer.

    My Advice

    • Every step along the way, I thought I would get rejected, but I didn’t. Hang in there! The hiring team does not pass people through out of kindness (even though they are very kind). They move people on through the hiring process because they believe they will succeed.
    • Imposter syndrome is real, but you’re there because you deserve it. Believe in yourself like they believe in you.
    • Have a support system. Be prepared to get together with a close friend (or two or three) and just talk about what you’re going through. I’m so thankful for my friends’ encouragement and being willing to listen as I got everything out of my head.

    If you’re considering applying, do it! The process is very difficult, but the reward is so, so worth it. If you’ve already applied, know I’m rooting for you!

    Leave a comment if you have any questions, and if it’s something I can/am allowed to answer, I’m more than happy to help. 🙂