the advice I gave at DEF CON 34

I did resume reviews at DEF CON this year with the Lonely Hackers Club.

DEF CON is a lot. It always is. This time I coordinated my day job to sponsor a table in the biohacking village aaaannnnd…. brought my teenager (who wants to learn and ended up being a natural at picking locks and talking AI into disclosing info) and my wife (who also works in cyber). Which was a whole new level of awesome, because I got to share an aspect of my life with my loved ones they had never seen.

I gave a presentation too. The presentation was great, I got to talk about my projects. The reviews felt better.

Presenting is broadcast. You prepare, you deliver, people nod, ask questions, you leave. Sitting across a table from someone for twenty minutes while they explain their job situation and what they hope for is a different kind of work. It's slower and it is very "real". I came home more proud of the table than the stage.

Three people stick in my mind

A college student with help desk, audit, and SOC internships behind him. Real experience, all of it verifiable, and worried about no callbacks.

A senior software engineer trying to move into Cyber. Strong engineer, reading his own codebase every day, convinced he was starting from zero because his title did not say security.

A security engineer doing the work of an entire architecture team, while still building and supporting. Authoring policy in a regulated environment on top of their engineering load. Underpaid, overworked…. Applying to architect roles and getting screened out (probably) because his title said engineer.

Every one of them was likeable, highly qualified, and motivated. Every one of them could talk about what they know.

What is actually broken

Applicant tracking systems were sold on the promise of putting the right talent in front of the right eyes. That was the pitch. The purchase was driven by compliance and volume. Employers needed a defensible record of every applicant they touched, and they needed to process thousands of them cheaply. Matching quality got bolted onto a filing system.

The incentives never corrected it. The buyer is HR operations. Their metrics are cost per hire and time to fill. Quality of hire requires waiting eighteen months and admitting some hires were bad, so almost nobody instruments it. Vendors optimize what gets bought.

Meanwhile referrals are consistently the largest single source of hires at large employers, while making up a small fraction of applications. Pick your study and the exact share moves around, and the methodology behind most of those numbers is thin. The direction holds up regardless. The formal pipeline is the overflow path for roles where nobody knows anybody. That was unfortunately true before the software. The software made the overflow path cheaper to run at scale and redirected accountability from the people screening applicants.

So the skill required to get hired is back to resume optimization and network access. Neither one correlates with doing the job. Nobody ever gets fired for the good candidate they never interviewed, which is why the failure is invisible to the people who could fix it.

What I told them

Most of what we covered was translation. Making your work legible to a reader with no context and thirty seconds.

Keep a win list. Write down what you accomplished the week you accomplish it. Or go back and get it done now while I'm reminding you. Most engineers I know cannot answer "what did you do last quarter" at all, let alone in outcome terms, because the details are gone by the time anyone asks. One running document of what you have done (or learned) solves the resume problem, the interview problem, and the I want a promotion packet at the same time. Unfortunately, it is also the piece people are least likely to keep doing, because it costs something every week but pays off indefinitely over time.

Write outcomes, not duties. "Managed vulnerability scanning" (from my own old resume) tells a reader nothing. Scan volume, time to remediate, false positive rate, downtime or cost avoided. Numbers stand out on a thirty second read. Job descriptions do not.

Claim the function you actually perform. If your title says engineer and your job is architecture, say so in the summary line where a human will see it. Stay honest and don't sell yourself short. The bullets underneath will not get read if the header sorts you into the wrong pile. And if the org has let it get to that point, the promotion is usually somewhere else. The company that undertitled you rarely re-levels on its own.

If you don't have it, get experience by giving it away. Small businesses, schools, churches, and nonprofits need basic security help and cannot pay for it. Write them a policy set. Teach a class on online safety. Talk to kids who want to learn. You will get better at explaining security to people who do not want to hear it, which is most of the job and the part almost nobody practices deliberately. Keep the artifacts. A policy set you wrote for a nonprofit is a portfolio piece and a better interview answer than another internship line. Don't over sell it, be real. Focus on what keeps them safe and is easy to do.

Use the real citable references. OWASP and MITRE, and the parts of them that tell you what to do. The Top 10 is an awareness document that people memorize like a spec. The Cheat Sheets and ASVS are where the work is. Running ASVS against one of your own services teaches more than reciting ten categories.

Run a model locally. Several people assumed anything interesting with LLMs required API budget and permission. A mid size model on hardware you already own handles most analysis and classification work. For an engineer sitting on their own codebase, pointing a local model at their own work is a weekend, and it teaches the AI piece and the AppSec piece at the same time.

What I don't know

Though I cannot completely disengage my personal bias, I think that advice was good. I really have no way to know.

There is currently not much follow up. I do not know whether the student landed a role, whether the architect left, whether anyone started a win list. I don't know if I sent someone down the wrong path with confidence like a questionable llm response. The reviews ended when my social battery was depleted and my spoons were gone, and that was that.

That is not specific to LHC, and I'm not criticizing. I think most career advice falls into this pattern. We give it, it feels useful to both people in the conversation, and nobody really measures anything. The advice that gets repeated is the advice that felt good to give, which is kind of a bad selection process.

Wishing I had thought of this earlier

The fix is cheap. Mostly procedural. It just has to respect where it is being asked. Nobody at DEF CON is handing over an email address so a stranger can follow up in ninety days, and they should not have to. So make it anonymous. A card with a QR code and three questions. Did you land a role. Did you keep the win list. Which advice did you actually use. Nothing collected that ties back to a person, answered whenever they feel like it, or never.

If thirty people say the win list was the only thing that stuck, you know where to spend next year's session time. Right now everyone is trying and hoping.

I am going to try to do something about it before next year. And I am going to do this again, more than once a year if I can. DEF CON is one weekend. The need for this is continuous, and it exists at every BSides, every ISSA or ISC2 chapter, and every community college program in the country.