If you’re new in your tech career through to making your first move into a senior engineering or leadership role then I am open to chat and mentoring on Merit. I’m happy to talk about the industry, career transitions, learning new skills, and/or connect you to other resources where that could be helpful.

In Part I of this series, I talk about shaping the role and how to think about who to hire. In Part II, we’ll cover how to hire and what to ask to ensure you make the best possible hire. Competencies In Part I we discussed what an EM role is shaped like and what competencies we expect candidates to have. These cover both leadership and technical skills. Our final list looked like this:

I do a lot of hiring, internally and as an advisor and consultant. I also read a lot about recruiting, and OMG, there are so many opinions about how to hire engineers. Everything from the interview process to take-home tests to the validity of whiteboard coding exercises has been explored and litigated. Some of my work also focuses on hiring engineering leaders for existing teams or the first engineering leader hired for an organization.

I have a lot of Bash/Zsh/Fish shell aliases. I’ve carted around a collection of dot files across laptops running both Linux and macOS and for use on systems I’ve managed. I’ve shared some of these, specifically for Docker, in the past. I wanted to do a post detailing some of the other aliases I have in case they are helpful to folks and talk through how to create and manage your aliases.

tl;dr: In choosing where to spend your developer experience and advocacy dollars, investment in content, documentation, and initial developer experience is the most critical because it has the broadest addressable audience. But you also need to make an investment in more active engagements (Discord, Slack, Github, contributor resources) if you want to ensure involvement in your community is substantive and sticky. Building channels for developers and growing a developer community should take a tiered approach.