Feature

What one Google engineer’s route reveals about moving into cybersecurity

Prerit Pathak’s account presents his move from software engineering into cybersecurity as a bold change of direction. The documented path, however, looks less like one jump than a sequence built over several years.

According to an as-told-to account published by Business Insider on 1 October 2026, Pathak began as a software engineer at Dell Technologies in India, moved to the United States for graduate study in 2021, completed a Google security engineering internship in 2022 and joined Google full-time in New York in 2023. Carnegie Mellon University’s Information Networking Institute also identifies him as a former Dell engineer, an alumnus of its MSIT-IS programme and a participant in CTF security activities.

His record includes more than study and stated interest. A 2021 paper lists Pathak as a co-author of SO{U}RCERER, a framework for Android application security testing. A public patent record also names him among the inventors of a Dell intrusion-detection technology. The application was filed in May 2021 and the patent was granted in May 2025.

Together, those milestones turn a familiar career-pivot story into a more useful question. Which elements could another software developer realistically transfer or reproduce, and which depended on access to a Carnegie Mellon graduate programme, international mobility, patent work and a Google internship?

A technical foundation, not a complete qualification

Software engineering gave Pathak a relevant starting point. He has said that experience building systems helped him understand how they might be abused. Google job descriptions documented in the research support the broader connection, although they cannot establish requirements across the cybersecurity market.

A Google access-security vacancy in New York asks for general-purpose coding alongside experience in areas such as security assessments, design reviews, threat modelling or security engineering. An enterprise detection engineering role similarly combines coding and security experience. An Android product security vacancy adds platform knowledge, vulnerability research and triage, secure-design consultation and work involving AI or large language model security engineering.

The common thread across these Google listings is that coding remains useful, but it is not sufficient by itself. Security engineers may need to reason about system design, recognise risk, understand specialised platforms and work with the teams responsible for building or operating products. A developer considering the move is not necessarily abandoning an existing profession. The transition can instead involve extending an engineering foundation into a different set of problems.

That distinction also prevents an overly easy reading of Pathak’s story. The cited vacancies ask for direct security knowledge or experience as well as software ability. They do not support the idea that any developer can move into security solely by changing the title on a CV.

Proof of work before the job title

Pathak’s route illustrates how security-specific credibility can accumulate before a full-time security role appears. Carnegie Mellon’s profile records his CTF activity, while the research paper and patent provide public evidence of technical work. In August 2026, the university reported that he advised students to build credibility through projects, conferences and initiative.

These records do not prove that any one achievement secured his internship or later employment. His chronology is principally based on his own account, and the sources do not reveal how Google evaluated each part of his application. But they do show a sustained pattern of work that existed before he joined Google full-time.

That makes proof of work one of the more transferable principles in the story, although not necessarily in the same form. A published paper and a patent are unusually strong credentials and should not be mistaken for standard entry requirements. The underlying signal is continuity: a candidate can document an interest in security through lawful projects, structured exercises, research or other work relevant to the role being pursued.

Any vulnerability research used for career development also requires clear authorisation and responsible disclosure. Pathak has attributed part of his early interest to finding and reporting a vulnerability, but the full circumstances and acknowledgements were not independently confirmed in the research. His experience does not justify unauthorised probing as a portfolio strategy.

One bridge, not the only bridge

Graduate education was central to Pathak’s transition. It provided a security-focused setting between his work at Dell and his Google internship, and it formed part of a sequence that culminated in full-time employment. Yet the available employer documentation does not establish a specialist master’s degree as a universal requirement.

The cited Google access-security and enterprise detection roles accept a bachelor’s degree or equivalent practical experience. That wording leaves room for routes not built around postgraduate study, although it says nothing about how recruiters compare applicants or how much experience they consider equivalent. It certainly does not mean the positions are easy to obtain.

The distinction matters because a polished success story can make an expensive or selective step appear inevitable. The research does not disclose the financial cost of Pathak’s education, the support available to him, visa constraints or the opportunity cost of relocating internationally. It also contains no comparison with unsuccessful candidates who assembled similar portfolios.

His master’s degree can therefore be understood as an important bridge in his route, rather than a prescribed gateway for everyone else. The documented vacancies offer a more grounded test: candidates can compare their existing skills with the combination of coding, security experience and domain knowledge described for a particular job.

Security engineering is more than simulated attacks

Pathak told Business Insider that his work at Google includes controlled threat simulations followed by analysis and reporting. That description remains his own account and was not independently observed, but Google job documents provide broader context for the mixture of technical and interpretive work.

The access-security role combines research and risk mitigation with technical consultation across products. The detection engineering vacancy includes threat modelling, detection design, post-exercise analysis, documentation and collaboration with incident response teams. The Android position covers vulnerability research and triage alongside secure-design consultation.

These descriptions complicate the narrow image of security engineering as continuous offensive activity. Simulating or investigating adversary behaviour can be one component. Explaining results, designing mitigations, consulting with product teams and communicating risk can be equally important to turning technical findings into safer systems.

Pathak has also attributed importance in his hiring experience to thinking aloud, asking clarifying questions and communicating risk with empathy, rather than relying on networking alone. That assessment cannot be generalised into a universal hiring formula. It does, however, align with job descriptions that place security engineers in collaborative and consultative roles, not isolated technical ones.

The advantage hidden inside the lesson

The repeatable elements of Pathak’s route are relatively clear: he connected existing engineering skills to security problems, pursued focused study, created documented technical work and gained experience through an internship. His account also emphasises communication during the hiring process.

The less accessible elements are just as important. His path involved international relocation, a Carnegie Mellon graduate programme, public research, patent credentials and entry to a Google internship. The records do not show how common that combination is, but it is more substantial than taking an introductory course and applying for a new title.

Nor can one successful candidate and three vacancies establish a general cybersecurity hiring boom. The Business Insider article is explicitly an as-told-to essay edited for length and clarity. Separate labour-market evidence would be needed to make claims about demand, shortages, competition, salaries or the accessibility of entry-level roles.

For readers assessing a similar move, the evidence suggests a sequence rather than a shopping list of credentials. Start with actual role descriptions, identify the gap between existing engineering skills and security demands, and build lawful, role-relevant evidence before treating another degree as the default. The three Google listings also show how much the work varies within one employer: access security, detection engineering and Android product security require different mixes. Pathak’s paper and patent represent an unusually strong version of proof of work, not a minimum requirement.

Read carefully, the story offers neither a universal blueprint nor evidence that a career change depends on collecting the same prestigious credentials. Its more durable lesson lies in separating the destination from the sequence that led there. Existing software skills supplied a base. Security-specific activity created evidence. Graduate study and an internship provided bridges. Communication helped connect the technical work to an employer’s needs.

The language of a leap captures the uncertainty in Pathak’s account, but it obscures the construction underneath. His move into security was not an unsupported jump from one field to another. It was a succession of smaller credibility-building steps, some broadly reproducible, others dependent on opportunities that many candidates will not share.

Building security-specific knowledge on top of software skills is a gradual process, not a change of title. The Hack Academy’s online cybersecurity training programme provides a self-paced way to study listed subjects including cybersecurity fundamentals and internet vulnerabilities, with practical exercises alongside theory.

Alex Mercer

Alex Mercer is a technology journalist and editor with a passion for making information technology and cybersecurity accessible, relevant and engaging. As Editor of TheHackAcademy.com, Alex covers emerging cyber threats, data privacy, artificial intelligence, digital fraud and the rapidly evolving technologies shaping how people live and work.

Leave a Reply

Your email address will not be published. Required fields are marked *