The startup had grown to 100 engineers and finally decided to hire their first security engineer. The CTO wrote the job description himself, pulling language from Google's security team page, adding requirements from Amazon's security roles, and including everything he'd ever heard a security person should know.
The posting listed penetration testing, compliance expertise, cloud security, incident response, application security, security architecture, and cryptography. It requested experience with SOC 2, HIPAA, PCI-DSS, and GDPR. It wanted someone who could do everything.
The candidates who applied? None that fit.
"No one could do all of that," a security recruiter finally told him. "You've described three different jobs and a decade of experience. You need to figure out what you actually need."
Security engineering hiring fails more often than other technical hiring because the field is sprawling, candidates are genuinely scarce, and most companies don't understand what they're actually trying to hire. The person who builds secure code is different from the person who manages compliance programs is different from the person who responds to incidents is different from the person who does penetration testing.
After placing over 100 security engineers at SmithSpektrum, I've learned that successful security hiring starts with clarity about what you actually need[^1].
The Security Engineering Landscape
Security engineering isn't one job. It's a collection of related but distinct specializations, and the skills for one don't necessarily transfer to another.
Application security focuses on secure code: code review, threat modeling, secure development practices, and the tooling (SAST, DAST) that helps catch vulnerabilities. An AppSec engineer works closely with development teams, reviewing designs and code, teaching secure coding practices, and building security into the development pipeline. This is the most common first security hire for software companies because the biggest attack surface is usually the software itself.
Infrastructure security focuses on the security of systems, networks, and cloud environments: hardening configurations, managing access controls, securing cloud resources, implementing network segmentation. If your infrastructure is complex—multiple cloud accounts, hybrid environments, sophisticated deployment pipelines—you may need infrastructure security expertise.
Security operations focuses on detection and response: monitoring for threats, investigating alerts, handling incidents when they occur. This requires different skills than building secure systems—it's about recognizing attacks in progress and responding effectively. Smaller companies often don't need dedicated SecOps; larger ones with significant threat profiles do.
Penetration testing is offensive security: actively trying to break systems to find vulnerabilities before attackers do. This is specialized work that many companies handle through consultants rather than full-time hires. If you have a mature security program or compliance requirements that mandate regular pentesting, a full-time offensive security person might make sense.
Governance, risk, and compliance (GRC) focuses on security programs, policies, audits, and regulatory compliance. This is less technical than other security roles—it's about frameworks, documentation, and audit management. If your primary security need is passing SOC 2 or HIPAA audits, you may need GRC expertise more than technical security skills.
These are different jobs requiring different people. The mistake most companies make is conflating them.
Defining What You Actually Need
Before writing a job description, understand your specific security problems.
For most software companies, the first security hire should be a generalist with an application security foundation. Here's why: your biggest risk is probably your application, your application is where your engineers can most directly help improve security, and AppSec engineers work naturally alongside development teams.
| Security Role | Primary Skills | Secondary Skills | Typical Background |
|---|---|---|---|
| Application Security | Code review, threat modeling | Development experience | SWE → Security |
| Infrastructure Security | Cloud security, networking | Automation, IaC | Ops → Security |
| Security Operations | SIEM, incident response | Forensics | IT → Security |
| Penetration Testing | Offensive techniques | Reporting, communication | Self-taught or specialized |
| GRC/Compliance | Policy, frameworks | Communication, project mgmt | Business or legal background |
This first security hire should have enough breadth to triage problems across security domains (they'll notice if your cloud configuration is dangerous, even if they're not an infrastructure specialist) and enough depth in AppSec to materially improve how your team builds software.
They should also be pragmatic rather than academic. Early-stage security work is about improving security posture, not achieving perfection. A security person who generates findings without helping fix them, who says "no" without offering alternatives, who optimizes for comprehensive security rather than practical improvement—that person will create friction without creating value.
When should you specialize? Once you have two or three security people, specialization starts to make sense. One might focus on AppSec, another on infrastructure, another on compliance. At four to six people, you can build dedicated focus areas. Beyond that, you're building a security organization with leadership, which is a different challenge.
Compensation Reality
Security engineers are expensive because they're scarce. The talent pool is smaller than general software engineering, the skills are specialized, and demand has grown faster than supply.
In major US tech hubs, junior security engineers (zero to two years experience) command $110K to $140K base salary, with total compensation reaching $130K to $170K. Mid-level (two to five years) runs $150K to $190K base, $180K to $250K total. Senior security engineers (five to eight years) earn $185K to $230K base with total compensation of $250K to $350K. Staff level pushes beyond $300K total in many cases.
Certain specializations command premiums beyond these baselines. Cloud security expertise—genuine depth in AWS, GCP, or Azure security—adds 10-15%. ML/AI security, an emerging specialty, adds 15-25% because almost no one has it yet. Offensive security (red team, pentesting) adds 10-20%. Detection engineering adds 10-15%.
Industry matters too. Regulated industries—fintech, healthcare—pay 10-20% more for security talent because the compliance stakes are higher. Government work or roles requiring security clearances pay premiums for cleared candidates.
If your budget assumes security engineers cost the same as general software engineers, adjust your expectations. You're competing for a scarce talent pool.
Sourcing Candidates
The scarcity of security talent means passive sourcing matters more than in other technical hiring.
Security conferences are high-value but resource-intensive. BSides events (regional security conferences) and DEF CON attract engaged security practitioners. Sponsoring, speaking, or simply attending and networking puts you in front of people who might not respond to cold outreach. This is expensive and time-consuming but highly targeted.
Bug bounty platforms (HackerOne, Bugcrowd) provide a hunting ground for candidates with demonstrated skills. Researchers who've found real vulnerabilities have proven they can do the work. Reach out thoughtfully; these people get a lot of recruiter spam.
Security-focused communities—Slack groups, Discord servers, subreddits—reach people who are engaged in the field. Build relationships before recruiting; showing up only to post job listings gets you ignored.
Referrals remain the highest-quality source. If you have any security people already, their networks are gold. If you don't, ask your engineering team: does anyone know security people? Adjacent connections often exist.
LinkedIn outreach works but requires care. Generic "I have an exciting security opportunity" messages get deleted. Specific outreach explaining the interesting problems you're solving, the scale of what you're securing, and why this role matters—that might get responses.
Bootcamp graduates can fill junior roles. Security bootcamps produce entry-level candidates who need training but can grow quickly. If you have the capacity to mentor, this path is worth considering.
What doesn't work: posting on generic job boards and waiting. Security talent isn't searching job boards; they're being recruited constantly. You have to go find them.
The Interview Process
Security engineering interviews should assess both technical skills and the pragmatic judgment that separates effective security practitioners from checkbox-checkers.
A typical process: recruiter screen (fit, logistics, interest), hiring manager screen (background, role alignment), technical deep-dive (domain expertise), practical exercise (applied skills), cross-functional conversation (collaboration with engineering), and leadership/values conversation (culture, career).
The technical deep-dive should match the role. For AppSec, dig into experience with code review, threat modeling, secure development. Ask about vulnerabilities they've found and how they worked with teams to fix them. For infrastructure security, explore cloud security experience, specific architectures they've secured, tradeoffs they've navigated.
Don't ask generic "security awareness" questions that someone could learn from a textbook. Probe for judgment and experience: Tell me about a time you had to convince an engineering team to prioritize a fix they didn't think was important. How do you prioritize security findings when you have more issues than you can address? Describe a situation where you had to balance security ideal against practical constraint.
Practical exercises reveal skills that interviews can't. For AppSec roles, code review exercises work well: give candidates a chunk of code (200-500 lines) with several vulnerabilities seeded in it. See what they find, how they explain the risks, and what fixes they recommend. You're assessing not just whether they spot issues but how they communicate about them and whether their recommendations are practical.
Threat modeling exercises test architectural thinking: give candidates a system description and ask them to identify risks, prioritize them, and suggest mitigations. Strong candidates form structured approaches; weak ones generate random lists without prioritization.
Avoid exercises that require specific tool knowledge unless those tools are central to the role. Security skills transfer across tools; evaluating whether someone knows your specific SIEM doesn't tell you much about their security capability.
Evaluating What Matters
The signals that predict success in security roles:
Can they explain vulnerabilities to engineers? Security impact depends on engineering teams actually fixing issues. If a security engineer can't communicate effectively to developers—translating security concepts into engineering terms, explaining why issues matter, proposing practical fixes—they'll generate findings that never get resolved.
Do they prioritize based on risk? Everything in security could be improved. Effective security practitioners focus on the things that matter most: high-impact vulnerabilities, likely attack vectors, achievable improvements. Candidates who treat everything as critical lack the judgment to be effective.
Have they shipped security improvements? Finding problems is one thing; actually improving security posture is another. Look for evidence that they've moved the needle—not just identified issues, but worked with teams to resolve them.
Do they understand engineering constraints? Security that ignores engineering reality gets ignored. The best security engineers understand that speed, features, and security must balance. They propose solutions that engineers can actually implement given their constraints.
Red flags that predict problems:
"Everything is critical." If a candidate can't prioritize, they'll overwhelm engineering teams with unactionable findings.
Adversarial attitude toward developers. Security works through partnership, not policing. Someone who views engineers as adversaries will create conflict rather than improvement.
Tool-focused rather than skill-focused. Knowing specific tools matters less than understanding underlying principles. Candidates who talk mainly about tools may lack deeper expertise.
Can't explain simply. If someone can't explain a security concept clearly to a non-expert, they'll struggle to communicate with the people they need to influence.
Certifications: Reality Check
I'm often asked whether to require certifications. The honest answer: certifications are weak signals of capability.
OSCP (Offensive Security Certified Professional) is genuinely demanding and indicates hands-on offensive security skills. It's a meaningful credential for penetration testing roles.
CISSP is management and GRC focused, not technical. It indicates familiarity with security concepts but doesn't predict hands-on engineering ability. Fine for security managers; not a meaningful signal for security engineers.
CEH (Certified Ethical Hacker) is widely mocked in the security community for being outdated and insufficiently rigorous. Treat it as a neutral or slightly negative signal.
Cloud-specific certifications (AWS Security Specialty, etc.) indicate some knowledge of that platform but aren't substitutes for real experience.
My recommendation: don't require certifications. If a candidate has them, fine; if they don't, don't penalize them. Evaluate actual skills directly rather than relying on credentials that may or may not mean anything.
Onboarding for Success
Security engineers often struggle in their first months because companies don't set them up correctly.
Access is the first barrier. Security engineers need to see systems, read code, access logs—and getting that access at companies with good security practices can take weeks. Pre-provision access before they start. Don't make them spend their first month fighting for credentials.
Scope is the second challenge. A security engineer looking at a new environment will find a hundred problems. Without guidance about priorities, they'll either be paralyzed by choice or work on the wrong things. Give them a clear first project: "We need to pass SOC 2 in three months" or "We're concerned about our authentication system" or "Help us build security into our CI pipeline." Scoped, achievable goals beat open-ended mandates.
Relationships are the third factor. Security engineers succeed through influence, not authority. They need relationships with engineering teams, product partners, and leadership. Deliberately introduce them, include them in relevant meetings, help them build the connections that make their work possible.
Authority clarity matters. When can a security engineer block a deploy? What issues require escalation? What's their authority to make decisions versus recommend them? Unclear authority creates either paralysis (they're afraid to act) or conflict (they act without support).
The startup that posted the kitchen-sink job description eventually figured it out. They defined their actual problem (application security plus SOC 2 preparation), wrote a focused job description, and reached out specifically to mid-level AppSec engineers who'd worked at similar-stage companies.
They found someone who'd done exactly that work: helped build security programs at startups, worked closely with engineering teams, understood the balance between security ideals and practical constraints.
Two years later, that hire had built a security team of four, achieved SOC 2 certification, and materially improved the company's security posture. All because they started by asking what they actually needed.
References
[^1]: SmithSpektrum security engineering placements, 100+ candidates, 2020-2026. [^2]: SANS Institute, "Security Career Survey," 2025. [^3]: (ISC)², "Cybersecurity Workforce Study," 2025. [^4]: HackerOne, "Hacker-Powered Security Report," 2025.
Building a security team? Contact SmithSpektrum for security hiring strategy and search support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum