When I interviewed at Dropbox in 2010 to join the Support Team, they asked, “Do you know Python?” I sheepishly replied, “You mean… like, the snake?”

There was an awkward silence. My face drained of color immediately. In my head, I could hear the searing words of a friend who asked me just a few weeks before, “Why would any tech company want to hire you? You have no technical background.”

In that moment, I felt like a trespasser in a space for the chosen—MIT grads who had spoken in algorithms since childhood and whose parents had helped them debug code for fun. Not a liberal arts college grad who had never taken a single Computer Science class.

My interviewers glanced at each other. Then came the strained smiles and the patient explanation about what Python actually was. This was only the first interview in a daylong onsite, and I was already wondering if they would cut the day short.

I got the job anyway.

That moment during the interview would come to define much of my journey at Dropbox: constantly feeling out of my depth while somehow moving forward. This experience of stumbling upward actually defines many great startups. They hire for slope, not y-intercept. It also tells you something more profound about belonging: the path into the temple of technology is often more painful than anyone admits.

***

In my first year as a Technical Support Engineer at Dropbox, a well-meaning coworker noticed my interest in coding and suggested I read Introduction to Algorithms—the hefty tome known as “CLRS” that every “real” programmer supposedly devoured. I bought it immediately, desperate to belong. I leafed through sections on sorting algorithms but the writing was dense and I couldn’t see why I needed them. JavaScript already had a sort method, didn’t it? Did my coworker actually read through this whole book himself?

For months, that thousand-page pillar of computer science served a different purpose: propping up my computer monitor to a comfortable height. It collected dust while I collected support tickets, serving as a monument to my inadequacy. But meaningful programming knowledge, I would learn, comes from building things. The book was teaching me solutions to problems I didn’t have yet.

Then one day, it struck me: the Support Team couldn’t fix what it couldn’t see. If we were ever going to improve, we needed to visualize our performance metrics. The problem grabbed me so hard that I couldn’t think about anything else on my commute home. That night, I stayed up until sunrise building a live dashboard that surfaced trends through area charts. I remained tethered to my laptop, rifling through MDN Web Docs, experimenting with the Canvas API, and compulsively refreshing my webpage after each new line of code. The next week, my dashboard became a permanent fixture on my coworkers’ screens. That’s when I knew I was hooked.

I’ve since come to believe that the best way to learn programming is to have a problem you desperately want to solve. But at the time, despite building tools the entire team relied on, I didn’t see myself fitting the definition of a programmer.

A month after the dashboard, Arash Ferdowsi—Dropbox’s cofounder and CTO—found me working alone in the dark office on a Saturday night. The motion sensors had given up on detecting life. Arash asked what I was up to, and I told him I was building a bot to auto-close spam tickets. “Were you thinking of using a cron job?” Arash asked, glancing at the screen.

“Does cron start with a ‘c’ or a ‘k’?” I asked as I began typing in a Google search box.

“It starts with a c,” he said. Then: “By the way, I’m really impressed with all of the programming you’ve been learning.”

My transformation was quietly underway—sparked by the dashboard project and then accelerated in that dark office, when a founder saw me becoming something I couldn’t yet see in myself. The bot eventually resolved tens of thousands of support tickets, including one memorable SQL injection attack that created 7,000 duplicate tickets.

***

I kept on building because I kept on seeing problems that needed to be solved, including the need for a customer-facing feature. One day, when I asked Trevor, Dropbox’s Web Team Lead, for access to our production repository, he was skeptical.

I explained: 5 percent of support tickets were people asking us to transfer ownership of shared folders. It was tedious manual work, especially risky when we mozied back to our laptops after our company Whiskey Friday ritual at 4pm. Why not let users do it themselves?

After a long pause, Trevor replied, “Let me beat you in a few rounds of ping pong first, then bring your laptop over.”

I lost at ping pong, but within a day, I had shipped my first customer-facing feature. The code wasn’t elegant—mostly porting existing patterns between modules—but it worked. More importantly, it eliminated hundreds of support tickets.

We can build solutions, ship code to users, save thousands of hours of work, and still not believe we’ve become what we’ve become. “Real” software engineers, I thought, had CS degrees from MIT and Stanford. They could implement quicksort from memory. They hadn’t learned to code at 24 years old, fumbling through MDN docs like scripture they couldn’t quite parse. Real engineers belonged here—I was just visiting.

So I applied to grad school, thinking I needed papers that said I was legitimate. I would study human-computer interaction, become a product manager, find a role where my otherness wasn’t so obvious. I told myself that I liked designing software products more than I liked building software products despite clear evidence to the contrary.

After the acceptance letters started to arrive, I decided to confide in Trevor that I would likely be leaving for grad school soon. His first reply was: “Do you really want to become a PM?”

As I sat quietly pondering what to say, he then asked, “How would you like to join the Web Team?”

I said what the outsider feeling makes you say: “But I’m not good enough to be an engineer at Dropbox.”

His response was perfect: “You’re effectively already doing the job. You’ve been moonlighting as an engineer for months.”

That’s the thing about outsider’s doubt: by the time you’re wondering if you’re good enough, you’ve probably already arrived. We need to accept that we deserve to be in the room we’ve entered. That day in 2012—which also happened to be my birthday—I became the first employee at Dropbox to transition into the Engineering organization.

***

Looking back, my Python confusion was the perfect interview answer. Not because it was right, but because it was honest. It showed I was comfortable not knowing things, which is one of the most important programming skills.

The best programmers I know aren’t the ones who intimately studied CLRS. They’re the ones who stay up until 4am because they can’t stop thinking about a problem. They’re the ones who ask whether cron starts with ‘c’ or ‘k’. The path to becoming a programmer is through building things that matter to people. You’ll learn everything else—the algorithms, the design patterns, the best practices—when you need them.

Years later, I did eventually read CLRS when I had specific problems that required specific algorithms. By then it was just another reference manual, not an idol or a barrier to entry.