Deep Dive
From PHP hacker to Uber's chaos engineer
Gergely Orosz traces his path from teaching himself PHP in high school, through a computer science degree heavy on theory over practice, to finally landing at Skype. His early career took a left turn when he accidentally nailed a backend interview at Uber despite being hired as iOS. A week before starting, his new manager asked if he could do Android too — he said yes, only to discover Uber was in the middle of rewriting its entire app in three months. The project paralleled his Skype experience: remote team, distant HQ moving at a different pace, constant firefighting. When Orosz told his manager the project was a disaster, the manager listened. Within weeks, Orosz went from individual contributor to project lead, copying the organizational playbook he'd seen work at Microsoft. His confidence came from pattern recognition, not ego. By the time the project shipped successfully, management asked him to formalize his leadership role — initially at the same level and pay as a senior engineer, sometimes with lower performance reviews. This reflected Uber's philosophy that management was lateral, not upward.
Inside Uber: brilliant architecture, held together with duct tape
When Orosz joined Uber in 2016, it was the hottest company on the planet, fresh off massive funding and growing faster than any competitor. From the outside it looked polished. Inside, everything was held together with duct tape and Google Sheets. The on-call rotation was a nightmare — noisy, constant stress, no clarity. What shocked him most was the sheer number of junior engineers and the 5,000-plus microservices architecture everyone was copying without understanding why Uber built it that way. The real reason was strategic: Uber knew they'd scale from 200 to 2,000 engineers in two years. They'd need many products — Uber Eats, Uber Rush, Uber Air, Jump Bikes. Hiring tons of senior engineers was impossible, so instead they created platform teams filled with senior engineers who built infrastructure. This freed junior teams to own their own services independently. If a junior-built service crashed, it didn't cascade. Within 6-12 months, those juniors became senior engineers through sink-or-swim learning. It was brilliant for hypergrowth but the industry copied the microservices architecture without the organizational context. Orosz watched it work and learned the deepest lesson: understand the why before copying the how.
What separates successful engineers from those who plateau
When Orosz managed engineers, he noticed a sharp divide. The engineers who thrived were product-minded — they understood what the company was actually trying to do, tested competitor apps, asked why features mattered. They weren't just writing code; they were thinking about the business. These engineers understood testing, stayed curious about other teams' work, made friends across the org, and crucially, they set up regular one-on-ones with product managers without being asked. In planning meetings, when a PM described a feature, these engineers would ask clarifying questions: How important is that user interaction really? Could we ship without it? One engineer Orosz remembers pointed out that a state-change requirement, while nice-to-have, would add months of backend migration work. By questioning scope, the engineer turned months of work into weeks. This ability to prioritize ruthlessly — to say no to things not critical for the business — came from understanding the business, not from algorithm mastery. The engineers who plateaued were technically solid but treated engineering as an isolated discipline. They executed what they were told but never asked why. In today's market, Orosz argues, this product instinct matters more than raw coding ability because AI is handling the raw coding.
The grief of coding becoming commoditized by AI
Orosz felt genuine grief watching AI writing code as well as humans do. For over a decade, he'd invested in becoming really good at debugging, deploying to production, knowing all the intricacies. He'd struggled through memory allocation errors in C, spent nights dreaming through code problems, and finally reached a point where he could pick up new languages and frameworks confidently. This mastery was hard-won, and hiring reflected it — coding tests made a huge difference. At Uber, when revamping interviews, Orosz and his manager designed them around what developers actually did: 50% coding, so the interview was 50% coding-focused. All of that is now gone. Between September and December last year, AI shifted from glorified autocomplete to writing code as good as humans — better in unfamiliar frameworks. What stings is the speed. The 10,000-hour mastery concept, the grinding that separated good engineers from amateurs, the grit selector in hiring — all of it vaporized in months. Most people give up on hard problems. Orosz has seen it happen. Coding was a selector for persistence and problem-solving. Now AI lets everyone generate working code on the first try. Orosz understands there will be good things about this shift, but the loss is real. It was hard to do. It required showing up, failing, debugging, learning. And suddenly, everyone can do it.
Why expertise still matters even with AI at the helm
Orosz tested this tension with a legal question. He had an important case and asked ChatGPT, Perplexity, and Claude the same question he was paying a lawyer to answer. All three AI systems gave the same answer with compelling reasoning backed by regulation citations. He wondered why he was paying a lawyer at all. Weeks later, his actual lawyer came back with a different answer — outcome B, not A. When Orosz pushed back asking why the AI's logic didn't work, the lawyer explained: the regulation is written that way but judges never interpret it that way. The AI trained on the text but had no awareness of real-world interpretation. As a novice, Orosz would have trusted ChatGPT completely. As someone now armed with expert knowledge, he could see the gap. The lesson transferred to software: if Claude generates great code and your business depends on it working flawlessly — manufacturing software running your operations, moving millions — will you trust pure AI output or want an engineer accountable when things break? AI says sorry, I'll fix it. A human engineer you can hold accountable, discipline, and rely on for institutional memory. For anything with money or stakes on the line, Orosz argues, expertise creates accountability. This suggests that even as AI gets better, hiring experienced engineers won't disappear — it might become more essential.
The death of the engineering manager career ladder
Starting in 2023, after zero-interest rates ended, companies eliminated middle management positions across Meta, Google, and beyond. Teams got flatter and smaller. The two-pizza team standard of five to ten engineers is becoming one-pizza: two to four engineers per lead. Remaining managers became more hands-on. What Orosz is seeing now is a return to the startup model: for 30 engineers, you have one director, a bunch of tech leads who don't do people management, and lightweight people management overall. The traditional career ladder of engineer to manager to senior manager to director is collapsing into engineer to tech lead and maybe director. There's far less mobility and far fewer options. Many of his friends — either stuck at large companies with enough scope or actively transitioning to staff engineer roles — are feeling the squeeze. This shift has profound implications for anyone currently in management. At Uber in 2016, you needed a manager for every five to eight engineers partly for the math, partly because weekly one-on-ones prevented attrition. Now that math is gone. Orosz notes a paradox: the best managers and directors at Uber were deeply technical. They could talk implementation details of the build system while managing 200 people. Amazon's leadership principle of dive deep — going deep into problems — is now table stakes. With AI, Orosz argues, there's no excuse for managers not to be technical. The old model where you can climb into pure management is becoming untenable.
Career myths that cost engineers millions
Orosz challenges two pieces of conventional wisdom. First: jump jobs frequently to maximize salary growth. This worked phenomenally well during the 2015-2022 hot market when every company was hiring and title increases came with each move. It might still work at AI companies right now. But for long-term leadership trajectories, jumping every two years becomes a red flag. Hiring committees for director or principal IC roles now ask: why can't you stay anywhere longer than two years? When markets cool, these chronological job-hoppers face brutal offer droughts because they haven't put down roots, haven't shown impact over time, haven't built trust. Second myth: show up, do great work, and you'll get ahead. While true in spirit, Orosz learned the hard way that visibility matters, especially at larger companies. At startups, you can show your work directly to the CEO. At a 10,000-person company, you need awareness. Some of this is as simple as sharing wins with your team; some is as calculated as posting on internal social networks so the right people see your impact. This isn't self-promotion in the pushy sense — it's ensuring that people making decisions know what you've contributed. Smaller companies naturally surface good work. Larger companies require intentional communication.
The generalist's advantage and the boring engineer who ships
Orosz was surprised when he learned that one of the best hiring signals Michelle Hashimoto uses is the opposite of industry lore. The best engineers aren't always the ones with sprawling GitHub profiles full of open source contributions and flashy side projects. In fact, Orosz argues, the best engineers are the ones with empty GitHub profiles — people who leave work at six p.m. to pick up their kids, show up at eight a.m., and put in eight focused hours of incredible work. These engineers are fast, efficient, and often outship the midnight grinders who spend half their energy on career branding. Most hiring managers miss them because they seem boring or unpassionate. But when you measure actual output, these boring engineers ship better code faster. They're not trying to prove anything. They're just doing the work. This connects to why generalists beat specialists now. With AI capable of handling the narrow, deep technical challenges, adaptability matters more. Someone who's done iOS, backend, and Android — who's uncomfortable with new tech but willing to learn — ships faster than someone stuck in their Java specialty. Orosz would hire the person who shifts stacks and learns quickly every time. He's lived it: he jumped from iOS to backend to Android to management and came out better at each stage.
What actually matters in five years: adaptability, ego removal, and the abstraction leap
When asked what will matter most for engineers in the next five years, Orosz zeroes in on three things: adaptability, curiosity, and the ability to let go of your existing beliefs. There's going to be enormous change and it's already happening. If you hold tight to your existing knowledge and how things used to work, you'll get run over. Orosz cites Grady Booch, creator of UML and object-oriented programming, on what he calls a leap of abstraction. This isn't the first time it's happened. In the 1960s and 70s, programmers worked on mainframes with specialized assembly languages for each machine. You trained on machine X and coded in its low-level instructions. Then compilers and high-level languages like Basic and Fortran came along. The old-timers said: nonsense, a compiler will never generate code as efficient as we write by hand because we know the registers, the memory jumps, the rules. It took them ten years to master this. The next thing you know, compilers matched their output and they had existential crises. The newcomers who didn't know the past just got good at high-level languages and ran circles around the old-timers who got stuck. But the old-timers who said, I'll learn this new thing, now had both the new and the old. They became significantly better than the pure newcomers. Orosz sees the exact same pattern happening now. Coding might be something machines can do, but building reliable software, building it quickly, shipping it — that's not going away. Boris Churnney of Anthropic is the archetype: a world-class engineer who broke both arms in a motorcycle accident, switched to functional programming when it was hard to type, and now uses Claude Code to generate 100% of his code while still being objectively one of the best engineers in the world. The difference is he lets go. He doesn't cling to how things were done. He embraces what's there and adapts. That's the pattern winners follow.