I second the recommendation - I'm a regular listener. Over the years I learned quite a few things on the show that would translate well to my job. One example are the episodes on dos and don’ts of measuring developer productivity, which helped me sort my own ideas on the topic.

I liked the explanation on when to use camel case vs. snake case. Also, the input on design patterns was really useful.

I also prefer working for startups or smaller companies nowadays: working closely with the management team helps to understand strategic decisions first-hand.

I also found people at smaller companies to be more motivated , and eager to bring their own ideas to the table. Often, because they feel valued by the founders and see the direct impact they make on their customers.

I find this can be applied to conflict situations in general. Not only to code reviews.

I think you actually don't do any coding challenges, you get to know your colleagues, find out how they collaborate on a daily basis, and experience the company's development process first-hand. Sounds pretty nice, I would say.

There is a coding challenge at the beginning. You're given a sample problem to solve and then your problem is analyzed.

I know this because I've applied to Automattic before and got that far. :-D

Good to know. Thanks for sharing.

Nice read!

Time-boxing my efforts using the Pomodoro technique has also made a big difference to my own productivity. I highly recommend giving it a try if you haven't done so yet.