Invisible Work That Keeps Pinterest Running with Ryan Cooke

Matt Klein: Welcome to another episode of Beyond the Noise: Signals, Stories, and Spicy Takes, the show where we dig into the stories of the people shaping the future of app-based computing, with a special focus on mobile. I'm your host, Matt Klein, co-founder and CTO of bitdrift, as well as the founder of Envoy Proxy. Each episode we'll talk with engineers, founders, and technical leaders who've transformed the way their companies build and understand what's happening inside their systems. We'll dig into the challenges, the breakthroughs, the lessons learned, and we'll wrap it all up with their hottest takes. So let's dive in.

Matt Klein: Today I'm thrilled to have with us Ryan Cooke, who is a Director at Pinterest, where he manages the Client Foundations org. His teams are responsible for the behind-the-scenes work necessary for Pinterest's Android, iOS, and web apps to be successful. Welcome, Ryan. Thank you so much for joining us.

Ryan Cooke: Glad to be here. Thanks for having me.

[00:00:53] GETTING INTO MOBILE ENGINEERING

Matt Klein: You've had a pretty epic career working at a variety of companies. I'd love to learn how you got into mobile engineering, what excites you about mobile, and how you got to where you are today.

Ryan Cooke: I went to an in-state college and for my first couple years of my CS degree I was fine, enjoying it. But something clicked around my junior year when I discovered I could actually build websites. It went from just doing the assignments to every weekend working on some silly side project.

Ryan Cooke: The switch to mobile happened because I did not like doing UI. This was before Bootstrap was popular, and I was not very good at it — it always looked hideous. Mobile had a more constrained design system that gave me a simpler path to something presentable. That's also probably a spoiler for why I end up always doing behind-the-scenes work on mobile.

Ryan Cooke: I gravitated specifically toward Android because I was a poor college kid and didn't have a Mac. I enjoyed building the projects more than the idea of them being popular — it was half for my friends, half just for the love of building things.

[00:03:22] EARLY CAREER: STARTUPS AND THE MOVE TO SAN FRANCISCO

Ryan Cooke: Entrepreneurship seemed like an intuitive route after college. I did an accelerator briefly, then joined a startup in Miami as their first hire — doing full-stack work, though I flirted with building a mobile app. I learned a lot, but looking back, being the first engineering hire at a company with a non-technical founder wasn't the best learning ground. There were a lot of poor practices I didn't know were poor practices.

Ryan Cooke: After that I built a side project app that got a few thousand users, which felt huge at the time. I left and joined a Southeast accelerator — not Y Combinator, but helpful for the legal and business fundamentals. Eventually I went to San Francisco to meet the tech ecosystem, and it was night and day. The investors I'd been pitching in the Southeast didn't know anything about tech. In San Francisco, even the Uber driver was building a startup and had fascinating insights.

Matt Klein: Was there an app you were actively pitching at the time, or did you go out because you thought it would be a better environment?

Ryan Cooke: I was at the end of the rope with an app called Track It — a tool designed to let people log things in their daily life and generate insights, like correlating headaches with poor sleep. I was still pitching it a little, but I was also ready to transition to a normal job. What struck me about San Francisco was this infectious belief that you could change the world, combined with a lot of genuine talent. I decided that if I was going to be in tech, I needed to be there.

Ryan Cooke: I also realized I lacked the building blocks for entrepreneurship — all my mobile development was self-taught, and I'd never seen a successful fundraise up close. So I joined UrbanSitter as their first Android engineer, built their Android app, and eventually became Android tech lead. It was a great experience. I had some really strong technical mentors there who helped me catch a lot of flaws in how I was thinking about coding.

[00:12:37] JOINING PINTEREST

Ryan Cooke: A friend who had left UrbanSitter told me Pinterest was going international and suddenly cared about Android. Pinterest was pre-IPO and very well-positioned at the time, so the move made a lot of sense. It was a very different environment — I'd been used to being the person who made all the Android decisions, but at Pinterest there were around 30 Android engineers when I joined.

Ryan Cooke: I was probably one of the most annoying junior engineers ever. In my first six months I made this huge document of things we needed to prioritize as an app — very impractical things, like rebuilding all the architecture for testing. Now as a director, I'd try to channel that energy in the right direction rather than shut it down. Young engineers coming in with fresh perspectives can be valuable, even when they don't know all the constraints.

Matt Klein: People who tend to do well over time often have exactly that quality. They own it and think about what should be done, not just what they're asked to do.

Ryan Cooke: Exactly. Finding the right time and place to raise those concerns is itself a skill you develop as you grow. The Google Doc approach wasn't wrong — it was a referenceable piece — but the timing matters. I've had engineers who are the smartest person in the room blurt out in the middle of a bug triage that the whole system is wrong and needs to be rebuilt. The instinct is right; the moment is not.

[00:17:02] IMAGE LOADING AND EARLY WINS

Ryan Cooke: My first project at Pinterest was a very vague brief: make image loading better on Android. Pinterest does a lot of images, so it mattered. There wasn't great analytics at the time, so I took a non-analytical approach — placeholder images seemed bad, so I tried prefetching. Resolution wasn't great, so I experimented with a higher resolution. I ran about a dozen experiments combining best practices with guess-and-check.

Matt Klein: What were the biggest wins?

Ryan Cooke: Prefetching was by far the biggest. If you're not prefetching, just do that — it applies to the network too. Beyond that, we spent a lot of time on resolution. We were often fetching images larger than could actually be displayed, so we built a system that balanced image quality against network conditions and device resolution. We tried different formats but found the server-side re-encoding cost wasn't worth the marginal gains.

Ryan Cooke: The results were significant — a big jump in impressions and engagement. I even gave a talk on it at ImageCon, which was an interesting experience as someone who had basically just run a series of experiments rather than done deep research. It gave me credibility internally: put this person on a project and they'll solve it.

[00:23:00] METRICS, DATA QUALITY, AND THE IPO

Ryan Cooke: The top item on my internal priority doc after the image project was that I didn't trust our data. Little did I know we were preparing to IPO, so that caught someone's attention. I was put on a tiger team tasked with making our metrics accurate enough to go public — specifically impressions and active users.

Ryan Cooke: The hardest step was just defining the metrics. Every platform had a different definition of what counted as an active user — which sounds like the most basic thing in the world, but it isn't. We found that our existing approach of counting API requests was highly vulnerable to being accidentally inflated, like by someone who had added a background prefetch.

Matt Klein: This still comes up at bitdrift. You'd think active users is obvious, but it doesn't match Play Store numbers or other sources. It's genuinely hard.

Ryan Cooke: Exactly. We standardized the definitions, moved to consistent implementations across platforms, and built data checkers to catch anomalies — like flagging an active user who somehow had zero impressions. One of those checks caught a case where Facebook was silently refreshing auth tokens in the background for Pinterest's web extension, triggering active user events for millions of users who hadn't actually opened the app.

Ryan Cooke: The high-level lessons: first, document the actual definition of every metric in a centralized, canonical place with the SQL query attached. Second, when you can move logging to the server side, do it — database artifacts are far more reliable than client events. Third, build data checkers that will alert you when something looks suspicious.

[00:32:55] THE MOVE INTO MANAGEMENT

Ryan Cooke: After the IPO work I became the tech lead for the Metric Quality and Test Tools team — I think I was the third choice, but the other two were burnt out on the space. I defined the strategy, was excited about it, and eventually grew to staff level as an engineer.

Ryan Cooke: I'd always been transparent with my manager that I was interested in management. My path to it was that I cared more about impact than the technical details at a certain level of complexity. I had a coworker who was deeply into functional programming and eventually left to build a functional cryptocurrency — and that seemed crazy to me. What I loved was making a one-line change that cut out-of-memory crashes in half. Nothing super clever, but a clear impact. Management felt like a way to scale that.

Ryan Cooke: My scope grew gradually — mobile builds came under me because we were the closest team to CI, other managers left and I inherited their teams. I went from one team to three to eventually managing eight teams indirectly. The biggest challenge in that growth is learning to lead teams beyond your domain. I was a strong expert on metric quality and mobile builds, but I'm not a staff-level iOS engineer. You have to find the right level of understanding to make good headcount and strategy decisions without being the expert yourself.

[00:39:06] AI, BUILDS, AND CURRENT CHALLENGES

Matt Klein: Now that you're managing all these teams, what are the big challenges you're facing — not just personally but across mobile engineering?

Ryan Cooke: Some of our challenges are classic: all our apps were written ten years ago and we never did a full rewrite. One big initiative this year is finishing the migration to Swift — getting to that last meaningful milestone of Swift code. On the opposite end of the spectrum, AI is everywhere now and we're figuring out where it fits.

Ryan Cooke: We've created a virtual group of engineers who are most enthusiastic about AI — the champions — and they help vet tools and share best practices via Slack. We do pair-programming demos. Being remote adds a layer of challenge because you can't just walk past someone and ask why they have ten terminals open instead of an IDE.

Ryan Cooke: Security is a real constraint. We can't just give engineers every tool as soon as it comes out. At one point we wanted to show how Cursor worked on our codebase while it was still in security review, so we had a developer work on one of our open source projects on their own device — that let us demonstrate the value without the code leakage risk.

Ryan Cooke: The most concrete win has been AI-assisted migrations. We were migrating Objective-C to Swift and gave an agent ten hours to work on a module we'd estimated at three weeks. It shipped. Everyone still read the code carefully — I'm not quite at the point of having the AI review the AI's work — but it was genuinely impressive. The bigger lesson is that using these tools well is a real skill. The people who get the most out of them aren't treating it as 'write all the code for me' — they're guiding it carefully.

Ryan Cooke: On the builds side: we were actually one of the first teams to run iOS builds on Bazel, and we moved back to standard tooling. Bazel can give you better results, but you need the staffing and expertise to maintain it — especially when each new iOS version requires extra work. We didn't have that, so we focused on what we could do really well with native tools. We've been generally happy with that trade-off.

[00:55:00] NATIVE VS. CROSS-PLATFORM

Matt Klein: Where do you land on the WebView versus native versus React Native/Flutter debate?

Ryan Cooke: As a default I lean native. At Pinterest's scale the tradeoffs justify it — better crash debugging, fewer mysterious issues, a richer ecosystem. If I was starting my own startup today I'd probably use Flutter for the speed of iteration before finding product-market fit. But once you've found it, native is still compelling.

Ryan Cooke: The area where we're reconsidering is metric quality code specifically — we need it to behave identically across all platforms, and that's genuinely hard to maintain in native. So we're exploring whether a shared layer makes sense there. But native is the default where we are.

Matt Klein: That's a great place to end it. Thank you Ryan — that was an awesome conversation. That's a wrap for this episode of Beyond the Noise. Huge thanks to Ryan for joining and sharing his story. You can find this and all past episodes on the bitdrift YouTube channel.

Ryan Cooke: Thanks for having me.