3 minute read
Meet Camilo Cueto, a Software Engineer II on Uber’s Shopper Payments & Merchant Reporting team in Santiago, Chile. In just a few years, he’s gone from building software for a handful of users to developing systems that serve millions in…
Meet Camilo Cueto, a Software Engineer II on Uber’s Shopper Payments & Merchant Reporting team in Santiago, Chile. In just a few years, he’s gone from building software for a handful of users to developing systems that serve millions in real-time. In this blog, Camilo reflects, in his own words, on his journey into Big Tech, the lessons learned from navigating Uber’s fast-paced engineering culture, and the challenges of embracing ambiguity at scale.
“When I landed my first job at a large tech company in late 2023, I was both excited and overwhelmed by impostor syndrome. I had jumped from a small, local software job to an international healthcare software company, where the scale of my work skyrocketed—from a few hundred daily users to a few hundred per second.
Within months, I became a Senior Engineer—not because I was ready but because the leadership team needed me to step up. A lot of this was luck—being in the right place at the right time. But I also take pride in seizing opportunities and working hard to meet the demands of my role. Over time, though, I hit a ceiling in my career growth in healthcare.
When I later joined Uber, I learned again just how unprepared I still was for the reality of working at a global tech giant. The interview process was challenging, testing me across every area of software development. With a ton of prep and practice, though, I was overjoyed to get an offer!
So here I was, with a shiny new Big Tech job, confident I could pivot into it just like before—right?
In some of my previous roles, deployment windows were measured in months, with five or more environments for varying levels of stability and integration testing. Learning about Uber’s deployment schedule on Day 1 shocked and intrigued me—‘What do you mean you deploy every couple of minutes?!’ The idea of reaching millions of users without multiple layers of checks was terrifying (but also exciting) to me.
My past experiences had taught me caution. Uber’s pace taught me agility. Both extremes reshaped my approach as an engineer. I learned that fear is an excellent motivator when your install base is in the millions—but so is speed in a competitive business.
Every line of code carries the non-trivial risk of breaking something massive. You feature-flag everything. Every change is methodical surgery, avoiding unnecessary cuts. Legacy code demands reverence.
At Uber, projects are conceived, built, and shipped in weeks—sometimes in just one. Proactively understanding what might go wrong, who or what will be a blocker, and how to navigate Uber’s vast infrastructure is a skill of its own. Moving this fast builds muscle memory, and mastery means staying ahead of failure.
At Uber, I stopped being a software developer and became a true software engineer—owning not just the code but every step of the solution.
Before, I could rely on a data analyst to size the issue, a business analyst to frame the problem, an architect to plan the implementation, and a testing engineer to validate it.
Now, those roles were all folded into one: software engineer. I had to broaden my skill set, taking ownership from ideation to deployment and beyond. That doesn’t mean we do everything from scratch. We have tons of specialists that we can call on when needed. But as engineers, we’re expected and excited to actively participate in and direct most stages of development.
At Uber, certainty is a luxury. Complex problems lack clear solutions—that’s what makes them complex. We’re building the plane as we fly it—that’s what makes it so exciting.
As engineers, we’d love to pause the world while we build the perfect feature. But reality intervenes: business priorities shift, implementation snags appear out of nowhere, stakeholders have conflicting demands, dependencies get delayed, or—worst of all—you get blocked by a team that owns a critical service.
Ambiguity can be exhilarating or exhausting, depending on the day. It’s either a chance to showcase expertise and creativity or a nightmare where the ground might collapse beneath you at any moment.
This is the Schrödinger’s cat of software projects: until you ship, your project is both a brilliant success and a work in progress waiting for its final breakthrough.
Keeping things from imploding is exhausting but also rewarding. The freedom that ambiguity affords makes space for creative solutions. It’s both terrifying and thrilling.
For me, this has been the real challenge of working at Uber—learning to live in entropy. It was uncomfortable at first. A year later, I’m now managing to adapt and succeed.
When I joined Uber, I thought success meant understanding how software works. What I didn’t realize was that software is the easiest part of software development.
Growth means looking back and realizing how little you once knew.
At Uber, being a software engineer isn’t just about writing code—it’s about ownership and accountability across the entire lifecycle. Navigating ambiguity and complexity has sharpened my problem-solving skills and taught me the value of adaptability.
I’m excited for what’s next. This year may challenge me more than any before, but if there’s one thing Uber has taught me, it’s that I’ll always come out the other side a better engineer.”
Join Camilo’s engineering team →
