What I Learned About Recruiting Security Engineers

I have been building a security engineering team for the past 9 months. Here are a few things I learned.

Photo by Matthijs van Heerikhuize on Unsplash

It is going to be challenging.

First, let us acknowledge that security recruiting is hard. It is very very hard, and is possibly the hardest kind of engineering recruiting out there. When I realized that I was struggling to get good candidates in the door, I reached out to friends, former colleagues, and other directors and VPs in my network, hoping to learn from their wisdom. Their first responses were the same:

• “It took my nine months from the time I opened my role to my first hire.”
• “Our req has been opened for a year, and we haven’t made a single offer.”
• “I have been doing this for years, and it’s still a hard problem for me too!”

If you are preparing to build a security engineering team from scratch, set expectations and timelines appropriately. Patience is required.

Fact #1: demand far outstrips supply. I will touch on the specific shape of this demand in a later section.

From https://www.cyberseek.org/heatmap.html.

When I extended our search beyond California to all of the United States, the funnel did not improve. My anecdotal recruiting experience agrees with the heat map on cyberseek.org: supply is low in every state.

Fact #2: the usual sourcing pipelines are not going to work. I have more to say on sourcing in a later section.

“Security Engineer” means different things to different people.

NIST maintains the Workforce Framework for Cybersecurity (the NICE Framework), which defines the different categories, specialty areas, and work roles within cybersecurity. Cyberseek provides a diagram that one can use to explore this framework, which served as a useful starting point for my job descriptions.

From https://www.cyberseek.org/heatmap.html. You can drill down into each category and review the detailed skills required for each job.

Bigger companies with > 50 security specialists can also borrow from Microsoft’s org chart, which outlines the various specialized teams.

For pioneering security engineering teams, these frameworks helped me learn about the different specialties that exist in the talent pool, which allowed me to polish my job description and fine-tune my sourcing. My search criteria differentiate between:

• Security QA
• SecOps
• AppSec
• InfraSec

Radar diagrams I built to communicate the different specializations I need.

In the past 9 months, I created, defined, and re-defined the criteria for my roles, my job descriptions, and my pitch multiple times, until I found the matches we were looking for.

There are cultural differences between sectors.

In the space I work in, there is a huge demand for engineers with a product mindset. It does not matter if the engineer is in Infrastructure, Platform, or part of a feature development team. It does not matter if the engineer interacts with product managers weekly. We need engineers at every layer of the stack who can understand the customer’s context and keep the business’s needs and the market’s competitive landscape in mind while making calculated tradeoffs.

Within security, it does not matter whether the engineer works in Application Security or Infrastructure Security. Security engineers with a product mindset can synthesize the latest threat reports and industry best practices, look past the theater, and help us prioritize what is important for our security posture. We expect our security engineers to attend calls with customers and explain how the policies and controls defined in our SOC 2 Type II report address their specific concerns, within the context of the customer’s business.

I have observed that security engineers who most recently worked at local government agencies, county offices, city departments, hospitals, and consultancies do not exhibit this quality. The same has been observed for engineers currently working at retailers that do not leverage (or perceive) technology as part of their core competitive advantage.

Good sourcers matter a lot.

Good sourcers matter, a lot.

Good full-time sourcers know how to research the talent pool, understand the mix of candidates, and figure out the right keywords and search criteria to use that can improve quality at the top of the funnel and the pass-through rates at each step. It is very difficult and time-consuming for a hiring manager to wear all 3 hats: sourcer, recruiter, coordinator.

Very good sourcers are actively engaged with the community. They attend meetups, understand the local lingo, and know how to identify candidates that are itching to move. They have networks that tell them which companies are restructuring their security org, moving their security teams (e.g. to Austin), or planning layoffs.

Hire the sourcer before hiring the candidate.

Ask for help.

Finally, I learned that cold-messaging people on LinkedIn to ask for help and advice actually works. Using plain-old LinkedIn messaging, I reached out to Directors and VPs of security engineering teams at similar companies in Silicon Valley, asking for advice and feedback. Their insight informed my current team structure and recruiting strategies.

Try it. In fact, if you are building a security engineering team, I would love to hear from you and share detailed notes. Find me on LinkedIn.