Review/overview – Page 8 – bor0's reflective blog

After this book was recommended to me by too many friends and coworkers, I decided it’s time to read it.

The structure of the book is such that concepts are introduced with examples, backed by scientific experiments. At the end of each chapter, summary statements are included.

It’s an okay book, though I cannot say that I have learned a ton from it – most of the stuff I had already experienced or read somewhere else. I liked the “puzzles” bit. The author starts talking about something and then walks you through your own thought processes while you were reading that piece. Felt pretty similar to GEB, in a way.

The book could’ve used a bit of structure to make things more explicit. I think a proper categorization of “Definitions”, “Experiment”, “Results”, “Takeaway” would make for a much easier read. Every page is just filled with letters – there’s a lot of text! 🙂

Here I will give a short summary of every part.

Continue reading →

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:

I keep telling everybody how much I enjoy the rotation, and I want to share the details of that (i.e. my personal experience)
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.