I wrote this post at the time I wrapped my 3rd month of the full-time hiring rotation at Automattic.

The reason for writing this post is two-fold:

1. I keep telling everybody how much I enjoy the rotation, and I want to share the details of that (i.e. my personal experience)
2. In general, I found self-reflection to be useful in organizing thoughts and self-improvement

A little bit of history

I’ve been in the software engineering business (professionally) for over 11 years. I did some programming even before that, but it was nothing too serious.

This rotation gave me the opportunity to try something completely different, but still related to my profession. Accidentally, I found that it’s something I enjoy doing very much! So, even if I were to go back to software engineering tomorrow, it will be with a different (and improved) mindset and with better overall knowledge.

I am very thankful for this opportunity. 🙇‍♂️

The meta effect and paradoxes

The first thing that I noticed when I started my rotation was the engineering qualities:

• Problem Solving (attention to detail, research and troubleshooting – finding the core issue of some bug)
• Communication/technical writing, clarity, think before responding
• Justification and trade-offs of each proposed solution, design & architecture
• Managing complexity, e.g. climbing abstraction ladder (e.g. C->Apache->PHP->DB->…), understanding different layers
• Meta work: process awareness, comm. with stakeholders, gather feedback, being aware of self and of approaches, running pilot runs -> iterating -> improving

The biggest moment was when I had to apply them; both to myself, when I worked on the code tests/trials, and to the candidates when working with them. It looks like it’s only two levels deep but it’s actually deep on so many different levels…

Just a quick example, to be more concrete: I give feedback to some candidate, first checking if the feedback itself is valid, and then thinking how they would respond to the feedback and how I would respond to their response to my response to …

There were some paradoxical moments as well.

I was already familiar with Gödel’s paradoxes and how limited mathematics is, but I experienced hands-on the limitation of having some processes formalized – e.g. trying to quantify candidates as numbers instead of persons. This is the biggest thing I like about our trial – it’s human. And also, not everything needs to have a process anyway, and sometimes you need to make your best judgment – I learned to be more self-reliant.

There are always things to be improved, on tooling, on processes, etc. But I believe we are striking a good balance between formal and informal.

OK, but what _have_ you learned?

Enough philosophy. Here are some straight facts. I feel much sharper now that I’ve learned a lot of new things mostly thanks to the Office Hours and the Engineering Hiring Workshop.

• I learned how to be a better PR reviewer. This sounds so simple and on the surface, but it can go very deep (related: next point).
• There are so many ways you can write feedback, either on PRs or P2s, or Slack. I’ll list just a few of the points, but obviously (I found out that) this is a complex matter.
  • Do you want it to be positive/neutral/negative?
  • How direct/indirect do you want to be?
  • Do you want to hint at something?
  • What is the right question to ask them? What is the answer we expect?
  • What are we expecting from them? What is our target/goal? What is their target/goal?
• A direct consequence of the previous point (but also from other points as well) is I learned that working with people is harder than working with code.
• There is no single right solution. Any solution can be “right”, given the correct arguments. And every solution has trade-offs; we need to make sure we pick the right trade-offs.
• Learned about the engineering qualities and how they break down. To give a few examples:
  • Do your research before you make a decision.
  • Once you made a decision, what other decisions were considered?
  • Communicate before assuming (time is better optimized this way).
• There is no perfect process; with that, I learned to experiment more. For example, a candidate got mostly all greens on a code test (they were a “yes”) but they failed the nonce check so I gave them an optional exercise and they resolved the issue.
• Obviously, I had to make my writing more representative, because after all, I am representing this company. (E.g. start with a capital letter, use correct tenses, etc.) Thankfully, my muscle memory has adjusted fast to that.
• People wrangling can sometimes be hard; I still have to work on accepting negative feedback and not taking it to heart.
• Assessing a candidate is not about the end-product, it’s about figuring their train of thought.