People who haven't done CTFs sometimes dismiss them. Artificial problems, artificial constraints, artificial flags. No one in the real world hides a string in an ELF binary and calls it a vulnerability.
They're right about the artificiality. They're wrong about the conclusion.
What's Fake
CTF binaries are compiled to be solved. Real binaries are compiled to function. The difference matters: CTF authors know the solution path; real software developers do not think about exploitation at all. A CTF challenge is a puzzle with a guaranteed answer. A real target is a system with bugs that may or may not be meaningful, and no one has confirmed there's a path through.
CTF scoring is also artificial. Time pressure, first-blood points, the metagame of figuring out what the challenge category implies about its solution: none of that maps to real work.
What's Real
The thinking patterns are real.
Enumeration as instinct. CTFs train you to look everywhere before committing to a path. Run strings, check the imports, look at what the binary does with its arguments, examine every input surface before picking one to attack. This instinct transfers. Real systems have more surfaces and more noise, but the discipline of looking before assuming is the same.
The cost of wrong assumptions. In CTF, a wrong assumption costs you time. In a CTF marathon, it can cost you the challenge. You learn quickly to distinguish "I believe X" from "I've verified X," and to track which assumptions in your current theory are load-bearing.
Comfort with uncertainty. Most CTF problems don't announce their vulnerability class. You're looking at a binary or a web app or a packet capture with no spec, no source (sometimes), and no indication of what you're looking for. You develop tolerance for operating with incomplete information, which is the actual condition of security work.
Building and discarding theories. You try something, it doesn't work, you update the model. Rapidly. The feedback loop in CTF is fast enough that you can run a lot of theories in a session. That iteration speed builds a habit of treating theories as provisional, not commitments.
The Transfer Problem
Not everything transfers. CTF binary exploitation often involves techniques (specific ROP gadgets, heap layout manipulation, format string exploitation) that appear in the real world but are not the bulk of real-world vulnerability work. Real vulnerabilities are often less technically interesting than CTF pwn challenges; they're logic errors, configuration failures, and trust boundary misconfiguration.
CTF also creates a bias toward exploitation over discovery. The problem is handed to you; in real work, finding the problem is often most of the job.
How I Use It
I do CTFs when I want to sharpen specific skills: working under time pressure, seeing how a challenge author thinks about a problem, practicing techniques I haven't touched in a while. I don't confuse the scoreboard for a measure of real capability.
The most valuable thing I got from CTF is not a technique. It's the habit of working a problem systematically when I don't know where it goes. That habit is useful everywhere.