Wrote on

Automattic trial year 2 – (probably) my last trial. Thoughts about the hiring process.

I have another post with my trial experience from last year, you might have to read that first, this one will be a little different. Read it here.

So… if you read my blog you might know that last year I trialed for a job at Automattic. Even if their canned rejection message on Slack mentioned something like “re-apply once you feel ready”, the official waiting time to re-apply as an engineer is a minimum of 1 year.

A year has passed and I was offered another try to get hired. If you are familiar with the process you might already know this, but the hiring process includes these steps:

  1. Screening process – You send the CV and wait.
  2. Interview step – Your CV was attractive to them, so you are offered a written interview on Slack.
  3. Code test – After the interview, you are offered a quick code test that should last a few days.
  4. Trial – If they like what you did on the code test, you are offered a paid trial project. This is the final step that gets you a hiring recommendation.
  5. Talk with HR – the latest step is a formality, but you talk about your future salary, preferred start date, and possible conflict of interest situations.

It is worth mentioning that this year I skipped steps 1-3 and went directly to trial.

I got precisely the same trial project as last year, same criteria, and the only thing that was different was how I ran the project locally aka the tooling was a bit updated.

I was excited to see I had the same project because I already knew what went wrong codewise last year and I could avoid those things. The final state now is 100% different from last year and I tried to give my best to have a nice codebase.

Ah, I forgot to mention. I did not make it this time either. But because I am the second time in this process, I saw some things that really upset me and I think I am safe to say I will never apply for the job again in the future. I am going to explain why and maybe it is worth reading if you are a fan of Automattic like I am. I think I am safe to say I was more loyal to the company than other already employed persons out there.

I had an idealistic view of this company, but once you see the process twice you can form strong opinions about it.

I am going to outline next a few problems and thoughts about the hiring process. Those are strictly my own opinions and I stand by them 100% after 2 years of going through the process.

Double standards

Throughout my trial, I was always asked to write extensive PR descriptions on Github. I tried to do my best and I almost wrote novels out there, thoughts about my decisions in code, good documentation on changes, and testing instructions. First I received feedback that the testing instructions should follow the same pattern in every PR, I applied the feedback for the rest of my trial. Right at the start of the trial, the trial lead said that my commit messages are not helpful enough and I should make them more descriptive. I did that for the rest of my trial. Then I got the feedback that commits messages should focus more on WHY I made a change, not what I changed. I made sure to follow the feedback for the rest of my trial.

Just for reference, one of my pull requests has 2068 words or 12600 characters.

They request the people in trial this extensive documentation in writing and expressing their own decisions.

But take a look at this PR. Or this. Or this. Or maybe this. Or maybe this initial PR on a repo merged as WIP and the first sentence says “Still working on this, do not merge”.

You get the point, once you are hired you no longer have to write novels and express your decisions. Or take a look at those commits:

If I were to write those commit messages from the start, I would end the trial on day 1.

This is why I think they have double standards, once you are eventually hired you no longer follow exactly the same rules as you do in the trial. And that is somehow expected, but the trial is meant to be “close to real-life”.

Another double standard: I wonder when is the last time one of their employees decided NOT to use an official SDK library available as open-source and available through composer but instead write the whole logic again from scratch. I cannot give many details about my project, but imagine you start using Stripe for payments on your website/app but instead of using the available SDK you start to write the logic to encrypt cards and requests to Stripe manually. Is that the normal approach in the day-to-day life at Automattic? I do not think so, the person that implements that would just do composer install and use the official SDK.

Especially when you are a promoter of open-source I find the request to NOT USE an open-source package in order to complete a task difficult to understand. Sure, you can take a look at my skills on low-level things like building HTTP requests and so on, but is that something you do daily on the job?

Lack of empathy and transparency

I believe some sort of automation should be done when you are a company that big, but they have somewhere an internal blog where they have canned responses for every possible scenario with a candidate. Seriously, my refusal message this year includes 70% of the same phrases as the last year.

After you get the rejection message, you no longer get any feedback or something to make the decision transparent.

Also canned messages like “It would be an honor to have you as a teammate or colleague” in the context of being rejected the second time… is a bit too much.

Automattic has a creed. I tried to apply every word of this creed while on the trial period. One part of the creed is “Given time, there is no problem that’s insurmountable.” which is funny because one of the two bullet points received as feedback that made them decide not to hire me was a thing that was not communicated to me in order to improve it if it was a problem. In fact, the second bullet was in the same spirit too. More on this a bit later.

Also, it was the year that I found out they have “strong yes” candidates that are more likely to be hired. What are their criteria for putting a candidate in that strong yes category? No one knows. Is it fair to have a favorite candidate right from the start and still put others like me who were not in that strong yes category through the emotional stress of a trial? Yes, emotional stress… while on the trial you are rarely told you do something good, and when they tell you about a positive thing, most of the time it would not be about coding.

Repeating bad patterns

Last year I finished my tasks on the 6th of May and the decision took exactly two weeks to come.

This year I finished my tasks on the 13th of May and the decision took exactly two weeks to come (today 27th).

I don’t even imagine they talked about my code for two weeks. This is impossible. What I imagine that happens in those two weeks is wait to see if there are better candidates in their opinion. When you have a large number of people you can choose the right one. The only problem here is the point above, lack of transparency – the two bullet points they gave me as final feedback are something they could have sent the next day after I finished my work, it is nothing worth waiting 2 weeks for.

Independence and owning your own decisions

One of the things Automattic promotes a lot is distributed work and independence along with the power of owning the codebase and making decisions.

You do not have this luxury in the trial.

Sure, you work in a distributed company but that does not mean you are 100% alone, you work in a team and you always get feedback from the team if you seem to go in the wrong direction with the code, right? At least that is how I read their teams work.

When we’re speaking about trials, I really believe they have a completed test, the same one you do, and if you are not solving the trial 70-80% in the same way, you failed.

So you really cannot get a taste of that independence, the trial is rigid and very open to subjective reviews.

Last year, my work was too simple in their words and not DRY enough, this year was too complicated without need. It seems like is way too hard to find that sweet spot they are looking for between too simple and too complicated, and… chasing one’s point of view about how a codebase should look has nothing to do with “independence” and “owning the codebase”.

Biased and maybe racist decisions

I used to love this company and the idea of working there so much that I never searched for anything bad about this company. And in the situations where I did find something negative, like a Reddit for forum thread about it… I simply decided not to believe it.

Even if they are committed to diversity, equity, and inclusion when you go through the process a few times you notice that while two persons might know the same amount of programming and have similar skills, in the end, the person that would be hired would HAVE to be in a minority. Why? I don’t know, I am sure they are not racist because they want to, but maybe they go too far and in the end discriminate against the majority at the expense of the minority.

I cannot make information public, but I could not see this pattern. If I could make the information public maybe I would get sued or be accused that I am racist, but it’s not like this. The facts are there and I would like to remember anyone that they have an open organization, you can easily find internal data if you are employed which would prove my point here.

In my first interview, I was asked specifically if I ever helped a non-profit organization or under-represented group using tech. Luckily for me, I did have some websites built for non-profit organizations and for the church I attend, but I assume [Objection: speculation] that if I did not have those websites built I would not pass the code test.

Why do I think the hiring is biased? Because most of the people they hire are in a similar age range. It does not matter if at 28-29ish I am married for 7 years, have two kids and I work in tech literally since I finished high school hence tons of experience. Heck, I even learned PHP and web programming way before high school, before PHP was cool. Nope, all of that does not matter because they are biased.

Having a back door to get hired

Read for example this happy experience for a person that got hired. Since this person had a few people that referenced him, the whole project was much faster and in the end, got hired. Because I am from a little European country nobody knows about and I have no persons inside the company that could reference me, I had to wait many weeks just to get a reply to my initial email, more weeks to start the trial, and 2 final weeks to get poor feedback and rejection.

Traps of putting a senior engineer in a box for hire

I work professionally for 10 years now, most of the time in my positions and projects I was the lead developer. In those 10 years, I for sure made some habits that are specific to me… things about how I structure code and projects, how I design systems, how I think… and so on.

When you are in the trial, you are literally put into a box. You have to conform to the trial lead’s way of thinking otherwise you will fail. Is that fair for a company that looks for senior engineers and brags about the autonomy they give to developers? I think not.

Lack of real-life scenarios

Even if the trial project is supposed to be a close to real-life scenario of what would it be like to work with them, it is really far from that.

Normally their teams are around 10-15 people, around that size. When you are on trial, you only speak with your trial lead. Normally if you ask for help in a team, you would get it assuming there other people in your team would know how to help. While on trial if you ask for too much help and guidance, you would fail because you are not independent enough. If you do not ask for help, you are TOO independent. It is always hard to find the right balance between the two.

Also, even if there is a whole team that takes the hiring decision, you never meet the whole team – the ones you do not know only know you through the eyes of the trial lead. That means that if the trial lead does not like you, it is likely you will not get hired because one person can influence a whole team. The ones that are invisible do not know how you think, interact, and stuff like that, at most they can look at your code.

So no… the trial is not close to real life. You do not get a lot to show on those 40 hours, my trial was even closed before those 40 hours would end. How much can you build in a week? Sure, I can make the trial project in 2 hours… but for sure that would not get anyone hired. The trial requirements are so easy that you could do it in 100 different ways, super basic, complicated, full of abstractions, easy to extend… But who knows what they expect? Only them.

I promise I can do the trial requirements in 2 hours or less and that would be close to real life. That would be merged while working on the day-to-day at Automattic. Crazy architecture and novel-sized PRs are not what you would do for those basic requirements.

Also, you most likely need to do your trial using WordPress, and the WP codebase is not the most up-to-date with the current PHP standards. If you apply hooks in your plugin for trial, you will most likely be asked why… well because that’s how you build things in WordPress. I’ve built WP sites for big clients, international corporations, and more. What is different from the trial project is that I could always, but ALWAYS, make my own decisions even if I was using WordPress or Laravel or Symfony or anything. Code is so subjective and my own view might not be your view. Principles in a programming book are ok but you should not follow those so strictly, you should always adapt. For example, WP does not follow all the principles in Martin Fowler’s book, mostly because they have a strict backward-compatible rule, but it was expected that my trial plugin’s code would follow those. Advanced software design in a tiny rest plugin? Hmm, that might be too much.

So, I do not know how they should hire but the trial is not working nowadays, especially for senior engineers that are so used to a way of working. It is not only me who says that.

The goods – having a creed

Automattic has a company creed. I resonated with it and tried to apply it strictly. That was not enough to get me hired, but the next thing I will do after this article is finished will be to start working on my own creed related to work. It is one thing that worked out for so many Automatticians and will surely help me on my path moving forward. So the good thing I learned from A8C is that having a creed is ok. For some context, check out Matt’s post “Why Your Company Should Have A Creed.”

Ending question – will I apply again?

Short answer: no. Two times in different scenarios was enough for me. The trial is the most stressful thing ever, mostly because I was highly motivated to get the job because I absolutely loved the company. In the end, you might love a company and its culture but in the end you still work with people employed there. Once you get to the human factor, you are trialling for a normal company again. You might get a trial lead or trial team that does not like the company as much as you do. There are even employees that are not excited about the company, they just do their job and close the laptop at the end of the day and they are done.

I was never this type of person. I always was 100% loyal to every company I ever worked for and because I saw Automattic as the “perfect company to work for” I am sure I would have been very motivated on the work I would do for them.

For me it was never about more money (in fact I think they would even get me less money than I do right now if I would have passed the trial), I make more than decent money now. It was never about computers, I have the most powerful laptop Apple made bought with my own money. It was not about perks like office-bugdet, I have a nice home office built (I work 100% remotely since 2018). The only perk I really like how it sounded was the unlimited days-off. I can now get unlimited days of, but since I work business-to-business those are never paid. That is the only thing I miss, but seems like this is almost a lie.

So I am not the typical person that comes in your company for compensation and leaves, I always tried to grow with the companies I worked for, so a person like me brings a lot of value to a company like Automattic, I was ready to get less monthly pay just to work for a company I like.

They did not want a person like me, so that is enough for me to say I will never apply for a job at Automattic again. I do not want the stress of a trial that has a 0.73% chance to get you hired. Seriosly, from a total of 24,904 candidates only around 176 were hired year-to-date (numbers might have rise a bit since I did this research). And from those less than 200 people hired, not all of them are engineers, the trial is required for every role you want.

I’ve read books like “The year without pants“, I listen to every podcast with Matt the founder of WordPress and Automattic, I like the company as a whole but the flawed hiring process will make me stay away from them in the near-to-medium future. I can always make more money as a freelancer or contractor like I am now and I do not have strict conflict of interests contracts to sign that are also very easy to interpret whatever way you want.

So no, the answer is sadly no. It is hard to let go, but I feel like I will always be rejected using the current hiring system.

Should you apply at Automattic?

I can’t choose for you. If you like the company like me, maybe it is worth taking a try, but I would encourage you to set low expectations from them: you might be the best programmer ever, if you don’t think 100% like the hiring team does, you’re out.

There are better companies out there that also support open source, better apply diversity and inclusion and probably pay better. In this state, I 100% think I was also rejected because of my ethnicity, race and religion. I do not know what percentage is influenced by those, but those surely play a role.

Also, don’t make the mistake like me not to read about the bad parts of the company. There is literally a blog that is anti-automattic that reflects thoughts from employees that do not agree with the company 100%. That, and a lot more, is worth reading and would make you create a better (and less idealistic) image of the company as a whole.

Open to questions

Like a lot of you did based on last year’s trial post, I am open to private conversations about the hiring and trial process. I was glad when some of the ones that read last year’s post DM-ed me on Slack to thank me for the article. Seriously, this year I got 5 private messages on Slack from persons that read my article. I also get many LinkedIN messages related to that article, so I am surely open for for questions and guidance about the trial at Automattic.

Ending

I feel like I could write forever about past months, how I waited for weeks for a vague feedback message, how I was ignored, and so on. But the more I write, the more I become sad, because I am writing about a company that I simply loved as an outsider, but once you try to become an insider you can see its real face.

Thank you for reading this year’s experience with the Automattic trial, the one from last year is one of my most visited and read articles from my blog and in that article I was also a bit of a dreamer and idealistic, I did a decent job last year too, but I was too blind and I took the fault 100% on me while I also waited for weeks for a decision (weeks in which they could compare me to others even if they clearly state they have a high hiring capability, I am sure that is why I had to wait 2 weeks for a final decision in both years, waiting for better candidates than me).

It is never ok to dream and be subjective, always try to be objective!

That’s all. Bye. God will provide and like last year after I was rejected I received a more-than-double offer for a better job, I am sure God will take care of me and my family after the mess of 2 months spent in the A8C hiring process.

Webmentions

4 comments to this article

  1. It seems like an interesting post, I’ll check both of these later.

  2. Thanks 🙂 the one from this year is more transparent and real I believe, which is why I decided not to apply again at this company.

  3. I read both blog posts and it seems like you were not a fit according to their standards.

    People have different reasons why they hire, but mostly they have to like you to hire you while they might ignore technical lack of knowledge in some areas.

  4. Radoslaw Kurowski says:

    I have been through the same trial at Automattic recently (same task) and I agree with this post.

    TL;DR – I do not recommend applying to Automattic at this time. There are unclear expectations during the trial, it has nothing to do with how great development teams work and is just faulty. Seems like it was designed well initially, then someone not understanding the whole thing began ‘maintaining’ it in a way that made it currently into just not delivering what it was initially supposed to deliver.

    The main problem with this trial is that the expectations are not clearly defined and when you ask for clarification you only get the vague ‘figure out on your own’, or ‘do it the way you think’. Now in my opinion in order to succeed you need to get lucky and hit just the right spot that they have in their script as the correct solution. There is literally no way of knowing where that spot is as there are many ways in which you can deliver a working solution that gets the job done. If you overengineer – you will get rejected. If you make something too simple that does not cover all the nuances they want to see – you will get rejected. Expect no help at determining what they exactly want and you have only a very small context to work with, the rest you have are assumptions that can go into infinity and you will not get any feedback if your assumptions are correct.

    Going into more detail – the main listed and outlined expectation is the ability to ‘communicate’ with the team. But you have NO team, only one person that offers only vague, occasional feedback that is raising more questions than it answers (or you get something like “is that REALLY what you think” in a rather unfriendly manner, never seen that before). This is really confusing, even more so considering that before the trial I had to do a coding challenge first, so one might assume that they will not be focusing on the code that much this time around, but on your ability to collaborate. Wrong. This is another coding challenge with an addition of you having to make blog posts about what you do that no-one reads and responds to. You probably can just copy paste some random text, just make sure that the title is right and they will be happy.

    One of the great things about being able to communicate is that you can ask for help when you get stuck. Even people with a lot of experience do this a lot (‘let him who is without sin cast the first stone’). But despite the fact that I was given access to a #php channel I got reprimanded for asking any questions there (and for not doing research myself) – questions about general things about WordPress since I am totally new to it and the time to complete the trial is limited. So the trial is about communication yet you get banned from using one of the best methods of communication (again, why give people access to it if they cannot use it?). I fail to see any logic there. I never bug people without doing some research first, but when you run into an overwhelming amount of material to sieve through then it is a totally accepted industry standard to ask for some hints. In fact I have been reprimanded in the past for doing way too much digging instead of asking for help. I refuse to believe that at Automattic (beyond the trial) they don’t get this.

    When I got rejected I was told that “I was extremely motivated”, which I totally was and I think that is one of the most important qualities a developer can have (even more important than having a lot of experience). I really went to an extreme with my commitment and research, but got rejected over some rather unimportant technical nuances that in a normal world would have been totally avoided if there had existed the ‘communication’ part in this trial.

    To sum up – either I am unable (as in not smart enough) to see the truth and fail to understand what this trial is meant to achieve, or Automattic has a real problem in the recruitment process. It all feels like (it’s just an opinion) the trial got designed by some person that had gained too much trust and freedom and that person had designed a process that is seriously detached from reality and how things really go at Automattic or in any proper development process. And no-one else than that person oversees that process, plus, that person is convinced that the process is perfect and is closed for any criticism. If I am right then I hope someone up in hierarchy will some day review the process. It might also be that the person that drives the trial has way too many candidates to process and mixes up things or even gets frustrated at times.

    This trial was the darkest and saddest recruitment process I ever had to go through. It was needlessly stressful and made me feel like crap.

    Oh, and the introductory document is entitled as somthing like ‘welcome to the chaos’. It felt intriguing at first, but no, it is not that kind of ‘fun’.

Leave a Reply

Your email address will not be published.

Acest site folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.

Copyright © 2022 all rights
are not
reserved. Do whatever you want, it's a free country.
Guess it's obvious, but the theme is created by myself with TailwindCSS. You can find the source code here.
I still use WordPress 🧡. The theme is custom Laravel though 😎.
%d bloggers like this: