I thanked the room, said I had what I needed, and stepped out ten minutes into the final round.
That was a few months ago. The rest is the process that got me there.
Why I applied
Klarna becoming a bank changes the regulatory frame the security org operates inside. DORA and TIBER-EU bring concrete requirements around red teaming and threat-led penetration testing. The kind of context where "why are we running this engagement?" stops being a discussion and becomes a regulatory line item. And where the question after the engagement is what got fixed, not what got written.
Less time arguing for the work, more time spent on it. That's what I was after.
The screening
Standard for a Swedish fintech this size. The recruiter chat came first: background, motivation, timeline. Brisk and friendly.
Then the tests. A logical reasoning test (pattern, deduction, the usual format), followed by a battery of personality and work-style questions: multi-page Likert grids that try to triangulate how you handle conflict, ambiguity, and repetition. I hadn't seen those in a while.
The technical assignment
A self-contained CTF against a fake Klarna dispute application. Two-week window. Heavy web and API focus. I'll keep this section deliberately vague so future candidates land where I did: looking at a blank page with no spoilers.
Scoring was point-based and I scored max: foothold on the web side, remote code execution on the host, local privilege escalation to root. The challenge was structured well. Each finding either opened the next or stood alone. It rewarded chaining.
A few moments from it.
The reconnaissance
Before I found anything useful, I'd spent close to ten hours running brute force against API and authentication surfaces. That's the playbook I default to against production apps, where the assumption is that the easy bugs are gone. This wasn't that. This was a classic CTF, and classic CTFs reward attention over volume. Half the first day went to relearning the difference.
The first real foothold came from a class of misconfiguration that's classic for a reason. Something the deployment pipeline should never have shipped to the web root. Once I noticed it, the rest of the morning was reading history and finding a leftover that turned into initial access.
Web-shaped bugs
The web/API surface was a spread of access-control and authentication flaws. A token verification path more permissive than it should have been. An object-reference flaw against an internal endpoint that trusted its caller. A second factor whose keyspace was small enough to be a formality.
Each of them is preventable at the framework level.
A lot of what was in the CTF is the kind of thing I rarely see in real production environments anymore. Fun to play with, less common to find on the job. The exception is the access-control class of bugs. Those never go away.
A serialization bug
One feature persisted user state in a cookie. The first few bytes of the cookie value gave away the encoding. The application was deserializing client-supplied data without integrity checks, which is a class of bug with one good fix and many bad ones. Swapping the payload for one that ran a command on deserialize gave me code execution on the host.
From web user to root
The serialization bug gave me command execution. The next step was getting a proper shell on the instance. whoami came back as www-data and I started looking around: env, mounts, what processes ran on a schedule, what files those processes read.
One of those files was a script invoked by a system service, with permissions that let www-data modify it. Edit the script, wait for the next run, get a process tree running as root doing what I asked it to do.
A horror story in any real environment, and the CTF authors clearly knew what they were teaching.
Other bugs and flags
There were a handful more bugs and flags I solved during the CTF. I'll omit them. The clues that lead to them are visible enough in the app once you start paying attention, and naming them here removes the part of the challenge I enjoyed most: following the trail.
The report
I wrote the findings up as a client-style report rather than a flag dump. Scope, methodology, finding-by-finding with PoCs, severity, and impact. That part of the deliverable is what tends to separate the work from the play, and it's how I treat any engagement.
A few days later, the recruiter wrote back: invitation to a 90-minute live hacking and programming session with the hiring manager and two engineers.
Before the session
I had questions. Klarna's financial results had been in the news around then (context), with implications for headcount, AI substitution of work, and the shape of the security org. Reasonable things to clarify with the person who would actually be my manager: did he have the mandate to stop things, what did the budget look like, how was offensive work prioritised.
I asked the recruiter for a short call with the hiring manager beforehand. The answer was that I should bring the questions to the 90-minute session.
Fine. I added them to my list.
The session
I joined the call. Said hi. The hiring manager and one engineer; we sat quiet, waiting for the second engineer, who was off refilling water. They were back a moment later. Four cameras on, four people looking at their monitors. No "welcome," no "nice to meet you," no acknowledgment of the assignment. The hiring manager opened with "yeah, let's begin with presentation, my name..."
We did the round of introductions. Then I asked my questions. The answers, paraphrased:
- The CISO holds mandate over security decisions. The head of offensive security does not.
- No KPIs. Team success is measured in number of reports produced.
- No standing budget for tooling or training. Each request goes through the CISO.
- Standard benefits otherwise. Health allowance, the usual.
I took a moment to weigh it, thanked the room, said I had what I needed, and left.
Ten minutes, give or take.
What I took from it
Klarna has a long-standing reputation as one of the strongest talent factories in Stockholm and beyond, and on the evidence I have, that's earned. The engineers who evaluated the CTF and sat in that room were clearly pros. People who do the work well.
The room itself is harder to read. People have bad days. Calendars get crammed. Personal stuff bleeds into work. The atmosphere of a single afternoon is not a measurement of an organisation, and I won't try to extrapolate it into one. Sometimes things are just like that, and that's okay.
The structure question is separate. A team measured by report count, with offensive work surfaced to leadership only through the CISO and budget gated the same way, is a team that ships findings. That setup works for plenty of strong engineers. What I want next is to ship fixes, with the mandate to do it.
I left the call clearer about that than I'd been in a long time. That's the value I take from the loop.