A while back I went through a recruiting loop at one young AI company with a large ARR. The kind that ships fast, hires faster, and shows up in the press for both. Cool experience. But I bailed.
It had to do with culture.
Initial screen
The screen was the most engaged I've been in an interview in years. Precise questions, one after another, specific technologies and categories. Whoever calibrated that round knew what they were doing.
It reminded me how it feels to interview for a company that's actually hiring, not filling.
VM and container exploitation
First question, quite specific: how would you exploit a VM or container to extract sensitive data from it?
Honest answer: when I was asked this, my brain glitched and I lost the ability to talk. Why? Because I approached the question from the perspective of the environment I work in today, my current employer. The valid answer covers kernel-level exploits, the --privileged flag, socket or sensitive host-folder mounts, Linux capabilities, and a few others.
CI/CD and IaC
Devs ship continuously. Infrastructure has to be set up, changed, and torn down in seconds. The way to keep up is Infrastructure as Code plus a centralised CI/CD pipeline. So the recruiter wanted to know: how would you go about securing that pipeline, and how do you verify the security around the IaC underneath it?
A proper answer covers:
- Pipeline exploitation, runner abuse, and expression injection.
- State files and credential theft.
The recruiter wanted to know whether you're familiar with the concepts. There's no way to know this stuff unless you've worked with it, or watched someone else work with it at some point.
My answers were vague.
AI and LLMs
An AI company wants its offensive engineer to understand a thing or two about LLMs and AI in general. The main point I learned some time ago that really helped me here: all LLMs are vulnerable to prompt injection (which remains unsolved), and they are not deterministic. A model can give slightly different answers to the same prompt, leaving enough surface for attackers.
I was able to talk through the LLM security model reasonably well. One of the answers that actually landed. How the threat surface maps onto MITRE ATLAS, the ATT&CK-equivalent for ML/AI: prompt injection, training-data poisoning, model evasion, model extraction.
Web
The web block. I was asked to define the gap between one-off IDOR and systematic BOLA, explain SSRF, and walk through race conditions.
IDOR is the endpoint that forgot an authorization check. Change ?id=1 to ?id=2 and read someone else's resource. BOLA is the same bug as a pattern: authorization isn't enforced at the object level anywhere in the API, so the check is missing across most endpoints rather than just one. One-off versus systematic.
SSRF moves the attacker's request through the server. The server is trusted inside the network, so the request crosses the firewall on your behalf: cloud metadata endpoints, localhost services, internal admin panels that would never accept your IP directly.
Race conditions are time-of-check / time-of-use. Two requests interleave, both pass the same validation against the same state, both commit. Useful against redeem-once tokens, balance updates, anything that should be idempotent and isn't.
The web part was hard, but only because I hadn't refreshed the concepts in my head before the interview. Material I've worked with, not material I'd kept current.
I wasn't prepared for every question, but the recruiter was kind enough to give me another shot.
Head-of-security talk
Then I spoke with the head of security.
Experienced developer and manager. Carries himself like a founder of the company he's working for. Ship fast, automate as much as possible, extract every drop. Passionate about his thing.
The conversation with him surfaced enough for me to make a decision.
Notes from the conversation:
- Play hard, reward ($$$) high kind of environment.
- Everything moves around shipping. Shipping is the centre of gravity.
- Introduction to security: a couple of hours of AI/developer onboarding, then access to the company kanban.
- "You start your work by picking tasks and making sure they are completed," said the CISO.
- Authority sits with the CISO, but the CISO cannot stop a release.
- No clear picture of what the team is supposed to achieve.
- Security issues are visible and obvious.
- Working hours go "way beyond" 9-5. Late nights and weekends, "to ship".
Sounds amazing if you have the energy, the structure, and the nervous system for it. Cool, especially with the comp and the upside. In the end I was asked to complete the next round.
The next round: create a HackerOne profile and submit a bug report against their production.
The CISO promised a job on the spot if I found RCE in backend infra or got CI/CD access. Funny part: he said on camera I could do literally anything, "you maybe must not take down our prod, but if you can show us that you can, we will hire you on spot". Funny, but maybe not so strategic.
Bailed
Anyway. I withdrew. Figured that was that.
Rare for me. I usually take a loop to a clear yes or no. This time the signals were too many.
Result
A few weeks later the recruiter reached out. Due to a change of priorities, the role was gone. They thanked me for my time, and I thanked them for theirs.