Skip to content

Whoami

I’m a security engineer who started my career in quality engineering and test automation. Over time, I’ve grown from testing systems to securing them end-to-end.

This page is a short overview of that journey; the rest of the site dives deeper into my thoughts on security practice, architecture, and real-world challenges.

Background

AOL / Netscape (2004)

I began my career in 2004 at AOL/Netscape as a QA engineer, working on AOL Blog and AOL Uncut Video. My work focused on functional testing, API testing, and early DevOps practices.

This was where I learned the fundamentals—test planning, automation, and disciplined engineering thinking—guided by a strong mentor, Orla Hegarty.

Red Hat (2007)

In 2007, I joined Red Hat as a system automation engineer on the Identity Management (IPA) project. I worked across a complex backend ecosystem—Kerberos, Samba, NFS, Apache, and more—owning end-to-end automation for distributed systems.

During this time, I also earned my RHCE certification and developed a deep understanding of what high-quality, sustainable QA really means.

Amazon Lab126 (2013)

In 2013, I joined Amazon Lab126 as an early member of the device security team. I built the security lab, automation frameworks, and vulnerability management systems from scratch.

My work expanded into full lifecycle security, including:

  • Vulnerability management
  • Incident response and security on-call
  • Architecture reviews and risk assessment
  • Android app reverse engineering
  • ML-based malware classifier development

This is where I fully transitioned into security engineering as a discipline, moving beyond testing into proactive defense and system-level thinking.

Graduate Study — UC Berkeley (2020–2022)

I returned to school to deepen my understanding, completing:

  • A Graduate Certificate in Applied Data Science (2021)
  • A Master’s in Cybersecurity (2022)

This experience helped me shift from knowing how to understanding why—a critical step in my growth.

The Trade Desk (2023–Present)

In 2023, I joined The Trade Desk as a Staff Security Engineer, and this has been the most transformative phase of my career so far.

Working in a smaller team expanded both my scope and responsibility. I’ve been involved across a wide range of areas, including application security, infrastructure and cloud security, endpoint hardening, data platform security, penetration testing, bug bounty programs, and vendor-facing security work such as VPNs and gateways.

More recently, I’ve also started working with GenAI/ML and agentic security, exploring how emerging systems introduce new attack surfaces and require different ways of thinking about risk.

This role pushed me beyond specialization into a much broader view of security. At first, the breadth felt overwhelming—I wasn’t sure if I could cover everything effectively. But over time, something clicked: this ambiguity isn’t a problem to eliminate, it’s part of the job.

Security in practice is not cleanly scoped. It spans systems, people, and decisions under uncertainty.

Today, I feel closer than ever to a grounded understanding of how to evaluate risk across domains and make decisions that hold up in the real world. I’m not claiming mastery yet, but I’m getting close to the kind of engineer I’ve been working toward becoming.

This site exists in part because of that shift—I’m now ready to share those perspectives openly.

Graduate Study — USC Gould School of Law (2025)

To complement my technical background, I pursued a Master of Legal Studies (MLS) focused on cybersecurity and privacy law.

Security doesn’t stop at technology. Beyond system boundaries, law, regulation, and institutions define what is possible.

This expanded my perspective—from systems to ecosystems, industries, and society—and strengthened my ability to navigate risk in both technical and regulatory contexts.

Trajectory

Over more than two decades, I’ve moved through QA, automation, and into security engineering—and now into a role that spans multiple domains of security practice.

My education at Berkeley and USC adds depth across both technical risk and legal frameworks.

The constant through all of it:

  • Work from evidence
  • Be explicit about trade-offs
  • Keep the people impacted by the system in mind

Why I Write

I write for a simple reason: to help.

That belief comes from both the support I’ve received—and one experience that stayed with me for a long time.

Years ago, when I was finishing my computer science degree, I ran into an unexpected problem. After submitting my graduation application, I was told I didn’t meet certain U.S. general education requirements—specifically in basic physics, math, and related subjects.

The situation was frustrating because I had already completed equivalent coursework years earlier in China. At the same time, I was already working full-time as an engineer, and my first daughter had just been born. Life was busy, and going back to retake foundational courses from scratch didn’t make much sense given where I already was.

I scheduled a meeting with my academic advisor and explained everything in detail—my background, the coursework I had already completed, and the practical constraints I was dealing with. I wasn’t asking for special treatment, just a fair evaluation of whether those requirements could be waived.

The conversation was short.

He listened, acknowledged that he understood the situation, and then said something along the lines of: “I could help. But I won’t. This is your problem to solve.”

That was it.

I left the room without saying much, but I remember the feeling clearly. It wasn’t just frustration—it was the realization that sometimes, even when help is possible and reasonable, it won’t be given.

In the end, I took the only path available. I enrolled in community college courses and worked through the requirements one by one. It took me three extra years-I don’t regret doing the study. I’ve always enjoyed learning, even when it meant revisiting fundamentals I already knew from a different system.

But that experience shaped a simple rule for myself:

If I’m ever in a position to help someone in a small, reasonable way, I will.

That’s the mindset I bring to writing here. If something I share saves you time, helps you think more clearly about a problem, or just makes a difficult situation feel a bit more manageable—that’s enough.

What I Write About

This site is a collection of notes and essays on:

  • Security architecture and product security
  • GenAI / ML safety and abuse
  • Real-world incidents and industry shifts

Think of it as somewhere between a lab notebook and a set of essays.