These are high-level notes from my discussion with a college junior wondering about the field of cybersecurity.
He asked me the question I get most often from students: how do I get into this field. I did not answer it directly, because it is the wrong question, and I told him so before I told him anything else.
That is the limitation to state up front. Nothing below is a syllabus. It will not tell you which certification to get first or which bootcamp is worth the money. If you came here for a checklist, this is not that post.
The question underneath the question
Cybersecurity is not a major you declare. It is a property of systems built by people who are not, mostly, security people.
So the real question is not “how do I get into cybersecurity.” It is “how do I get good enough at building things that securing them becomes obvious.” Those are different questions with different answers, and most of the advice aimed at students answers the first one.
I told him: know a lot about everything, then go deep in one or two places. That is the same advice I would give a salesperson, and I have watched it hold in both jobs. A salesperson who knows only the product is replaceable. One who also understands the customer’s industry and the customer’s specific situation is not. Engineers work the same way. Broad enough to see how a system fits into the world it lives in, deep enough in one or two places that you are the person people call.
How can you secure what you don’t know about
That line is not mine originally, but I have said it enough times that it might as well be.
The best security people I have worked with were computer engineers first. They understood how a system was built before they thought about how it could be broken, and that ordering matters. It is the difference between finding a lock’s weak point and knowing the door was hung wrong to begin with.
There is a specific reason this matters more than it used to. A lot of security work is firefighting: someone shot themselves in the foot somewhere upstream, and now it is your weekend. That is real, and it is also not where the good version of this career lives. The good version is upstream of the fire. Engineers who understand security do not eliminate risk by adding a review step at the end. They stop generating the debt in the first place, because they can see the shape of the mistake before it ships.
You do not want to insert quality at the end. You want to build it in from the start. The people who can do that are the ones who understood the system deeply enough to see the problem coming, not the ones who arrived afterward with a scanner.
What AI changes, and what it does not
He asked, reasonably, whether any of this still matters if AI is about to do the coding.
Some of it, yes. AI is going to handle more and more of the detailed design work. But something has to design the AI, review what it produces, and decide whether the output is actually sound. That work does not go away. It moves up a level, from writing the code to being the person who can tell whether the code is right.
Here is what I think actually changes, and it is not the value of understanding systems deeply. It is the cost of proving you do.
A terminal-based coding assistant now configures your environment, writes your boilerplate, and can run background tasks while you do something else. That lowers the barrier to trying things enormously. A forty-dollar single-board computer and an afternoon used to be a real investment. Now the investment is mostly your attention. The bottleneck stopped being capability a while ago. What is scarce now is imagination: the willingness to point the tool at a problem you actually care about instead of a tutorial someone else wrote.
Which means the proof of competence changed too. It used to be a transcript and a certification. Now it is a public repository with a real commit history, a personal challenge you set for yourself and actually solved, a website you built and are still maintaining. Start that now, not the month before you graduate. A GitHub history that begins two weeks before hiring season says something specific to the person reading it, and it is not the thing you want said about you.
If I can point you toward one concrete action from all of this, it is: get a cooperative internship as early as you possibly can, and start committing code in public before you have anything you consider impressive. The impressive part comes from the history existing at all.
The part that stays human no matter what
Not everything moves toward automation at the same rate, and it is worth being specific about why.
AI is very good at writing software. It is much weaker anywhere the physical world pushes back: robotics, hardware, anything that needs a person on-site with a screwdriver and a working theory of why the thing stopped moving. That is not a temporary gap. It is a structural one, and it means hands-on engineering stays valuable for a long time after pure coding roles get harder to find.
The other category that holds is anything genuinely people-facing. As the technical execution gets commoditized, the differentiator stops being “can you write the code” and starts being “do people trust you enough to bring you their hardest problem.” Jobs that are fundamentally about human connection resist automation for the most human of reasons: people would rather deal with another person, especially when the stakes are high enough to be worth caring about who is on the other side.
Put those together and you get a shape worth aiming for, not a specific job title: broad technical competence, real depth in one or two areas, comfort with the physical world if you can get it, and enough judgment and trustworthiness that people bring you the problem before it becomes a five-alarm fire. That combination does not go stale.
Take this instead of a checklist
I told him the traditional version of a career, one company for thirty years, is already gone. Continuous learning is not a phase before the real job starts. It is the job, indefinitely, and pretending otherwise is how people end up surprised by a layoff they should have seen coming.
So here is the decision procedure, not a summary of what I said. Before you commit to a specialization, ask yourself one question about it: could I explain how this breaks?
If you cannot explain how a system fails, you are not ready to be the person defending it, no matter what the job title says. Go learn that first, wherever “that” turns out to be. Everything else, the tools, the certifications, the specific stack, sorts itself out once you can actually answer the question.
