https://retiari.us/tags/hiring/ Recent content in Hiring on Alex Maestretti Hugo -- gohugo.io en-us Tue, 25 Jun 2019 14:37:03 -0700 https://retiari.us/books/who/ Tue, 25 Jun 2019 14:37:03 -0700 https://retiari.us/books/who/ Who was given to me by a friend of mine who is a partner at a venture firm. They have been using this to grow their practice, and giving it to all their CEOs. The text lays out a solid strategy for hiring ‘A players’ into your organization. It provides a set of steps that address many of the shortcomings in hiring that I have witnessed in organizations, in terms of lack of investment and rigor in the hiring process. Too often hiring managers just dust off the last job description they used, wait for HR to send some resumes, and then make a hiring decision based on gut. The authors lay out a much better approach, and break it into Sourcing, Selecting, and Selling, which are the same basic phases that I have written about for my hiring approach. It is a quick read with some good details, but there are of course summaries available that capture the broad outline well. Sourcing starts with a rigorous evaluation of your needs for that particular role, all too often folks just start hiring without understanding the specific needs of the role. Hire specialists, not generalists. Sourcing includes all your personnel’s resources for networking. https://retiari.us/posts/oncall_devs/ Mon, 04 Dec 2017 12:02:31 +0000 https://retiari.us/posts/oncall_devs/ In hiring for my team I sometimes get questions about on call. I wanted to share some context on how I view on call for our team vs a dedicated engineering team. To the question of whether a role is a responder role or a developer role: It is both. I feel strongly that successful engineers solve their own problems so I am looking for responder-developers that can play both positions. In the larger more traditional SOC/SIRT teams they will often carve off engineering as a specialization mostly to ease hiring as they scale. The downside is the dedicated tools team can loose touch with the operational aspects of the role and start building things the ops team doesn’t need, even as they get more and more mired in requirements documentation and program oversight. The Netflix model, whether in security or building the UI, is that every engineer owns their program from start to finish; so you develop the requirements, you decide what to work, you build it and you operate it. Everyone is ‘on call’ and this aligns the incentives to write good clean functional code; when it breaks you get paged. I know many folks coming out of a SOC/SIRT role at a more traditional company are looking to leave on call behind, but that is mostly due to the type of on call they had to endure.