The Peterman Pod - GoogleX Chief Scientist On Imposter Syndrome, Career Growth, Project Taste

Episode Date: July 18, 2025

Carey Nachenberg was a Chief Scientist at a GoogleX moonshot, a Fellow (senior most eng at Symantec) and a professor at UCLA. I interviewed him about his career story and we discussed:• Story behind his growth to IC10 (VP equivalent)• How high-level IC recruiting works• How imposter syndrome held him back• How to develop “project taste”• How AI is affecting his studentsTimestamps:(00:00) Intro(00:54) Growth to Fellow at Symantec (13:13) The most complex malware(16:13) Why C was faster than assembly(17:17) Imposter syndrome(21:28) What matters more than intelligence(28:03) Experience at GoogleX(34:24) Leaving GoogleX(37:43) Experience at Lyft(43:40) Getting credit on collaborative projects(46:53) Becoming a professor at UCLA(49:13) How to speak well(53:23) How AI affected his students(1:03:53) Career regrets(1:07:16) Finding work you enjoy(1:09:03) Advice for younger self(1:11:04) OutroWhere to find Carey:•  LinkedIn: https://www.linkedin.com/in/carey-nachenberg-14bbb03/Where to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman

I got to work on whatever I wanted for my entire career. This is Kerry Notchenberg. He's a cybersecurity expert who is a fellow at Symantec, which is four levels higher than staff. I look for things with big business impact. I look where there were gaps. From there, he joined Google X as a principal engineer and fought imposter syndrome. And what if, like, I'm not good enough for Google or meta or something? As a professor at UCLA, he's seeing firsthand how AI affects the classroom.

I allowed students to use LMs in retrospect. You know, that was a bad idea because I think they were using it in ways that hindered learning. How do you even tell if they're using LMs, though? One way you can tell is... I learned a lot from his career stories and hope you do too. I get this called. A frantic call from UCLA. Can you still teach?

Because our lecturer bails on us. I have PTSD from that experience, I have to say. Before we get into all the juicy parts of your career, like working at Google X or autonomous vehicles with Lyft, I want to start by kind of laying the high level groundwork. So you worked at Symantec for a long time and became their senior most, you know, similar to a chief scientist type of role. I kind of wanted to go over that and all the lessons you might have learned there and, you know, anything interesting that came up there.

So could you share the high level story arc of you working at Semantic and how you grew to Fellow? Totally. So I actually started back in, I think. like 1992 was an intern at Peter or Norton Group. And so Peter Norton Group was later an acquisition by Symantec, but some of your viewers are going to remember Norton Antivirus,

from Norton and Norton Utilities and so on. And so I think I was the first intern at Peter Norton Computing. And they didn't even have a desk for me. So I literally worked in a QA lab with the QA lab manager who was a guy that used to sell knives for a living. Because like back then in engineering age two, they weren't professionally trained software people, right? So basically they would just get whoever knew something about computers.

And this guy knew something about computers to run the lab, and I would work in one of the test computers. And so that was my first summer internship. And then fast forward when I left in 2016, I had become the senior most engineer in the company. So from the junior most person, the first intern to the senior most person at Symantec, which had acquired Norton. So it was a long ride, but that's the high level of work. Was cybersecurity something that really you were focused and really wanted a job in cybersecurity or it just by chance?

Yeah, so at the time when I was working at Peter Norton Group, I wasn't working on cybersecurity. I was working on something called Norton Commander, which was like a file utility manager. So I didn't actually work on cybersecurity until my third year, my third year of internships, at this point, of Symantec where they had acquired a product called, I don't remember what it was, but it was an antivirus product that they renamed Norton Antivirus. So that product was acquired and rebranded, and they had a team of people analyzing computer viruses. So my third year of internship, that's when I got into cybersecurity. I had no experience. They just needed an intern and they threw me on it. Like what does the career ladder look like? Because I think Google and those

companies came in at some point and said, hey, this is L3. This is. is L4, this is L5, and then kind of a lot of companies copied that. At semantic, what did career progression look like? I would say the levels generally track to companies like Google and Facebook or meta, going all the way from like a junior, you know, software engineer through software engineer, senior software engineer, staff and so on. So the levels are very similar. The difference was for me at the very high levels of distinguished engineer and fellow, it's Mantec, you know, when I went to Google, they basically said, you know, we can't just hire fellows, you know, we haven't experienced you. We don't know if you're going to do well here.

So effectively, I was downgraded to a principal engineer at level eight from what would have been probably a level 10 at Tamanek. It was a vice president role at Symantec. What does the hiring process even look like for people so high level? Was that a tailored, bespoke process? When I went to Google, basically the former chief operating officer of Symantec, guy named Stephen Gillette, had recently transferred into Google X. And they were starting a stealth project in Google X, which we could talk about. He had known me from my time at Symantec and basically said, hey, why don't you talk to the team and see if there's a good fit? And so I didn't have to apply.

I was just, you know, brought in. And we had one meet and greet with the team's founders in Venice. And then we had an interview, a day's worth of interviews, probably about eight interviews. And six weeks later, I had my offer letter. You know, for a lot of software engineers that are in the lower levels, the interviews are leak code, their system design, and there's, you know, some generic behavioral interview. For at the high levels, what does that loop even look like? Is it mostly behavioral?

Are they asking you leak code stuff too? So I don't believe that I had any coding problems during that interview. I don't know if I recall correctly. There was one design problem, but mostly these were leadership-like questions. Like, how would you solve a hard problem? How did you solve a hard problem in your career? How do you deal with conflicts? You know, tell me your thoughts on, you know, where are the fields?

is going. You know, Google X is a forward-looking, or X rather, as a forward-looking organization. And so some of the discussions were focused on that. Some of the discussions were literally sales pitches. Like, I didn't really have to say much. They went and talked to me about where they thought the world was going to try to get me excited. So I think it probably depends on the person, but in my case, I think they thought there was a good fit. And it was really about sort of going through the motions of, you know, having interviews and selling me on the role. Okay. So then going back to Symantec, I mean, you know, getting promoted to fellow, what do those highest level promos look like? At least at Semantic, most promotions up through

what was called technical director or senior technical director, which would be the equivalent of, let's say, staff engineer or senior staff engineer, probably at other companies. Most of that was done just within the organization. So as long as, as a vice president or senior vice president was okay with a promotion, it was, it was allowed. At higher levels for distinguished engineer and fellow, it was, there was a basically core group of technologists led by the CTO of the company. We would meet once a quarter. We would get applications from those people and we would then review their applications and actually have them come talk to us about their work and then make a decision based on that.

And so the reason that we do that way is that we'd have consistency across all divisions, all teams of what it meant to be a distinguished engineer or a fellow for the organization. So that's the process we went through. And it wasn't just per division. It was for the company. So when you got promoted to fellow, was that one of the happiest moments of your career or was it something you expected and not a big deal? You know, it's very interesting. So I did not have to go through that. through that process to get promoted to fellow. So I was a distinguished engineer at Semantic,

and they had that process. I wasn't part of it because I wasn't a distinguished engineer at the time. The team that does promotions is made up of distinguished engineers at the time. We had acquired a company called Veritas, and Veritas had a notion of a fellow, which Symantec didn't. So basically, after the merger between the two companies, they said, okay, we need a level set, the role because the people to Mantic have never had this kind of role, who would belong there? And I was nominated without my knowledge, and it just happened.

And I kind of got a congratulations. Or maybe my boss, Phil Behan, and said, hey, there's some discussions going on, you know, and then you're a fellow. So they basically took my portfolio stuff and gave it to the team that did the evaluations, and that was the end of that. I mean, with your growth to fellow,

something about the way you work sets you apart from other engineers. What do you think are those things for you? I think what helped me get to Fellow was working on really impactful projects for the business, not necessarily always the most technically difficult projects, although many of them were, but more impactful. Like they moved the needle for the company. I had so many of them under my belt at that time that they just said, you know,

the criteria are this many projects should be done of the scope. and I had plenty more, and so they basically said, you know, you're above the bar. So what was the key insight to doing those projects is finding things where there were gaps, things the company needed where people weren't stepping up to do them. And, you know, I did them. Maybe a quick step back. At Sanbanatech, it was sort of like the wild left. There wasn't an engineering culture per se.

there was just people working on stuff. And like projects would often run really late because, you know, it was a little bit more of a wild west. We didn't have an agile process. We didn't really do our own integration tasks. Like we'd throw over our code to QA and they would worry about it and we'd work on the next thing. And in fact, I had very unusual circumstances.

I didn't rise to a path where I was given a small project and somebody said, okay, do this. Here's a box around the project. They basically said, Carrie, you already sort of know the technology because you've been working on it as an intern. Go figure out what to do and do it, which is amazing. Because here I am, like a junior software engineer and I got to work on whatever I wanted for my entire career. It's semantic, never assigned work to do. Yeah, it was crazy, which was great.

And so I got to just pick projects that I thought would be impactful. And I picked well. I guess I picked well because, you know, project after project landed. They were integrated. We did tech transfers into the product. they shipped. So that's how I got there. It wasn't like, oh, I did increasingly bigger scope projects that somebody gave me. So how'd you train that that project taste? Because impact typically leads to career growth everywhere. Yeah, yeah, yeah. It's a good question. And it's, I look for things

with big business impact. I look where there were gaps. So like way back when, you know, this is like old news now, but it's sort of interesting. Like we had these computer viruses, which are emerging, which were called polymorphic viruses. They were self-mutating malware. And they were self-mutating in a way that there could be like literally quadrillions of variants. And the way that the teams were working on these things, but back when I was an intern, even,

is they would basically write a handwritten assembly language to go look for telltale signs of a variant in the mutation. Okay? And the problem with that is, it worked really great, except it took six months because we shipped a new product every six months.

And so it took six months to discover to candle a virus. And then the next day, somebody released three new viruses, which were slightly, you know, slight variants or differences, different viruses, but mostly the same. And then all of that work would not work anymore. And so, you know, I would look at that problem and say, oh, there's a need to be able to move more rapidly in covering new malware. And by the way, detecting these self-mutating threats is not like using a reg X.

You can't just, you know, search for a string to find these things. So I'm like, oh, that seems like a really interesting, hard problem. So I kicked it. And then I started working on it. That was my master thesis and eventually transferred in the product. If you were to think about the things that you took on, they were a series of, I guess, side projects or, you know, whatever you wanted to take on, where you'd take on this new thing.

Maybe something else would come in. You'd take that on. Is that kind of how you were working? I would say there were probably six or seven times in my career where I'm like, oh, the company needs this type of thing. Let me go spend six weeks, two months, five months, figuring out what that looks like, building prototypes, talking to engineers and figuring out what they need,

and then, you know, building that. And there were other times, which is probably 80% of my career, where I was just sort of tweaking those things. In other words, we built them. We were trying to either tech transfer it, so I was helping with that, fixing bugs, improving. Those were sort of incremental improvements on those systems. But that's one of those two things generally.

So you mentioned a little bit about viruses. And when I was doing some research, I saw that you had done some storytelling on top of Stuxnet and kind of compiled. I think that's such an interesting story. Can you tell me a little bit about Stuxnet? Maybe we can go into that. Sure. Stuxnet was at the time just unfathomable. It was just a very complex piece of malware, which was multi-platform.

So it didn't just infect like Mac machines or Windows machines. It infected, I think, you know, Windows machines, but also like microcontrollers that would actually run like centrifuges and so on. And so it was probably the first multi-platform piece of malware we had discovered, used zero days in order to break into systems that, you know, basically vulnerabilities, exploiting vulnerabilities that hadn't been patched because they weren't even known about. And it didn't use just one of those or two of those.

I think it used like six different vulnerabilities to spread. many of which were zero days. It would literally stealth itself. So on your computer, if you were to look at a thumb drive, which had stuck to it on it and look in your finder application or your Windows file system application,

you would see, you know, nothing there. But it was there. You'd stick that in your computer. It would auto launch. It actually had a payload to auto launch. If you were to look at the logic that was running on a centrifuge, or rather the control,

that ran the frequency converters, you would not see any of the Stuxnet logic. It was in that controller. But if you downloaded the logic from that controller onto a Windows machine, it would stealth and remove the logic from Stuxnet as it pulled it off. And then if you updated that logic, for instance,

it would reinsert itself into that logic to reinfect it as it went back. So it would actually like sort of piggyback on back and forth, stealth itself. It was just amazing. And then, of course, how it disrupted the centerfuge is a certain super interesting as well. Yeah. It's so complicated and sophisticated that it makes me wonder

who wrote it. And I saw something like it was, you know, 50 times bigger than the average virus, incredibly complicated software. And I was reading into Wikipedia a little bit before we kind of, it said no one has claimed credit for who wrote this thing. Who do you think wrote this thing? I think it's pretty good. You'd be pretty safe to say it was the Israelis and the American government. Yeah, my understanding of recollection is that there are water, not watermarks, but sort of, you know, coding styles or things in there that sort of implicate both governments. Have you ever looked at the source code or played? I have not. I didn't do any analysis on Stuxnet. My career was focused early on analyzing malware, like literally looking at the machine

language and disassembling and so on. But later on in my career, it was mostly about detecting sort of how could they build algorithms to detect that malware rather than, you know, and and hands-on analyzing the malware myself. So I never looked at the ducts at, yeah. You mentioned a little bit about assembly code. Did you ever write assembly code when you were working at Sventi? I did. Yeah, I wrote assembly code as an intern.

And although back in those days it was mostly C, but some assembly as well. And I remember the first antivirus engines were written in assembly for speed. And one of my first tasks as I joined full time was I said, you know, this really needs to be to see, so it's more maintainable. So we poured it to the thing to see and actually. made it faster because the people back then people didn't know algorithms they didn't understand what a big o was or how to you know they would do linear searches and so we were able to go and

take something in assembly language move it over to see have less code and it would be you know five times faster so i see so the the speed ups moving from assembly to see was due to better algorithms and that's right that it wasn't because of a compiler or something no the compilers weren't that great back then. But even without an optimizing compiler, if you use a hash table versus or binary search versus a linear search over 60,000 signatures, you know. I saw that you worked at Semantic for a long time. And, you know, I think in the tech industry, it's common for people to move around here and there. What do you think kept you at Semantic as long as you were? You know, that's a great question. If I have to be perfectly honest, I would say imposter syndromes. Really? So,

Well, yes and no. So at Symantec, I didn't really have imposter syndrome because I had done a lot of stuff and I was well regarded. You know, I was known in the company and so I had a good safe place. But I always worried what if it just is because I'm at Symantec and I grew up here and I learned the stuff here. What if I went somewhere else and I wouldn't be able to learn the stuff or what if people have different standards and what if like I'm not good enough for Google or meta or something?

And so I stayed because it was comfortable. And I complained. I complained all the time. I wasn't happy later on in my career. I have to be honest with you. I wasn't doing things that may be happy. When you get more senior, you do a lot more BS, right?

And you also have the opportunity not to do as much BS, but you have to push yourself not to do it because it's very easy to, you know, go to meetings and, you know, have broad discussions, and it's not really that necessarily fun. Right.

And so I wasn't happy near the end of my tenure at Semantic. but I was afraid that it wouldn't be able to do well or it'd fail the interview process. And so I'd just stay. And it was comfortable. Throughout your career, there were so many promotions and you had so much impact.

For someone like you to have imposter syndrome, you know, I feel like that shows that a lot of people, you know, it's a very natural feeling for a lot of people. Did you, eventually you did leave semantics. So was there anything that helped you overcome imposter syndrome? You know, the thing that is, that helped me was that somebody said, hey, we want to interview you.

We think you'd be a good fit. And so I said, you know, I'm probably going to fail this interview. I'm sure I'm not good enough, but I'm going to do it. And so I just did it. And so that, you know, I needed an external pull or push, I don't know what you would call it, but in order to get me to take the chance and then it worked out. But for me, like in my head, I was, you know, I wasn't competent to do that job, you know. You mentioned also that at the highest levels, there's, you know,

a lot of BS and, you know, I guess it sounds like meetings and things like that. Do you have any, I guess, tips on how to be less involved in the BS? Because I think that's a natural pull for anyone. Yeah, it's sort of natural. Definitely, it depends what you're doing. I mean, some senior technical directors and distinguished engineers, even fellows, were working day to day and building code and working with their teams. It just depended.

I was an individual contributor, vice president. So I was in IC through my entire time at Symantec. Other people would actually manage teams and work, club works closer on projects. You know, it's just, it's inevitable, right? In other words, you're having more strategic meetings. And then the problem is you're having a strategic meeting with a bunch of people, many of which, many of whom don't necessarily know that much,

but they have an opinion because everybody has an opinion. And there's a lot of debating and a lot of arguing and a lot of like, you know, posturing for, you know, for power. and, you know, it's just, there's a lot of garbage that comes with being more senior and force. Like, there was some joy, especially for me when I got to pick my own projects, to be able to just sit down and literally go two months with nobody asking me, what, what are you doing? And I'm just like cranking and trying things, that doesn't work, but that does and

super excited, right? Right. Then you get into a room with seven people and you're like, we've agreed that this is our new company strategy. One of my last rule, things of the company I did was actually define the company technology strategy for the whole company. And everybody agreed to it, the CEO agreed to it, and then we get in a room and everybody would say, oh, sure, but, you know, we have to make money on our projects or products.

And so, you know, adding those features to align with technology strategy, that's going to set us back. And we've been told we have to make, you know, this much top line revenue. And so, you know, you end up having debates and discussions and it's like very draining. So you said you were pulled into Google X and you ended up taking the interview and doing well. I'm curious, what was it like entering, you know, Google or this like Feng style big tech? And were there any cultural differences of stood out to you?

You know, fewer than you would think. I would say the biggest difference that I saw there was there were really, really, really smart people. Like Symantec had some smart people, but again, it didn't have an engineering culture. Even when I left in 2016, it was starting to develop one. But it was really, you know, it was more, a little loosey or gocier than at Google for sure. But the quality of the people in Google X and X were really very high quality in terms of intelligence. Now, what seemed about the same was that many people in X, as there were many people in Symantec, didn't have good taste, research taste or project taste.

And so a lot of people were really smart, but it wasn't clear that they were picking projects that would be, that would land or, you know, or that were feasible, you know, at least in my opinion. So I think that is an attribute of engineers, no matter what company, no matter how intelligent people are. But it was, you know, like it was startling how much brilliance there was. And I do remember, like, there was one guy who was clearly like over 200 IQ. The guy was just, he talked to him. And he was just astoundingly brilliant. And he was still an L4. Why was he in L4?

Because, you know, he had lack of communication skills. you know, worked on really interesting stuff that was interesting to him, but not necessarily had business impact, didn't collaborate well, apparently, you know, like there were things, whatever it was. And it didn't matter that he was brilliant. Like, he was twice as smart as I was. But, you know, just because you have intelligence doesn't mean you're going to be successful. And so that was, you know, saw the same thing there.

If I'm understanding correctly, if you are very ambitious and you really want a career growth, intelligence is not that important. It sounds like there are some things that are much more important. You cited communication, soft skills, project taste, picking things that actually matter. Yeah. Is there anything else that comes to mind? There are definitely people who are less intelligent. You're not going to, like, at Google, we didn't have too many of those people.

Like, there were people that were really, really, you know, most people were really quite smart. So I would say a baseline is, you need to have a baseline level of intelligence. But I, for instance, don't think I'm a really intelligent person. I take it forever to learn new things. I have like this ramp, which is like this. at least internally, that's how I feel. You don't need that much intelligence. Be successful, but enough.

So communication skills, collaboration skills are really important. Knowing how to work with somebody and not just piss them off because you're saying you're wrong, but figuring out how to, you know, how to give them what they need in order to get what you want, which, by the way, I haven't really mastered yet.

I've screwed that up a bunch of times too, but that's one. If we talk about business outcomes, I'll generalize that. I would think something that's really important to move up is focusing on outcomes. So this is like a really important thing. And I probably did some of it subconsciously or unconsciously and some of it after I learned about it more consciously.

It's very easy for people to focus on their own outcomes. In other words, they know what they'd like to do. They know about the technology they want to build. They know that they want to make it 10% faster or whatever it is. But often the outcomes of the company or the outcomes that somebody else is trying to meet are different than your outcomes. And if you don't project yourself into their shoes or the company's shoes

and identify what the company's outcomes or divisional outcomes are or the other team's outcomes are, people are not going to be interested in what you have to do, even if it's really complex and hard and interesting for you. And so I think what really helps

far more than intelligence is focusing on what outcomes need to be solved for a project or for the company, what metrics matter for those outcomes because often there are things that don't really matter that much. Like, you know, there are like requirements that are unimportant and requirements that are super important. So it's focusing on the most important requirements and doing that work.

And focusing on the most important outcomes for your division or company and then focusing on only the most important requirements is going to get you far, you much farther than the intelligence, I would say. I think you have an interesting perspective because you're in academia because you're lecturing at UCLA, but you've also had a lot of success in the industry as well. When I was in school, everything was very obviously intelligence-based. Maybe unless there's a, oh, aside from hard work, but, you know, there's a test, you either get it right or not, aside from group projects and things like that, obviously coming from that place, you know, intelligence feels like everything.

And then you get to industry, and I agree with you, 100%. Intelligence is not everything in industry. But because in college, it's very obviously meritocratic, whereas in industry, there's other things to like do people like you or, you know, other things like that. Would you say that career growth is meritocratic in the industry? You know, in my experience it was. There were cases where people were being promoted because a vice president basically pushed really, hard or SVP pushed really hard and said, you know, they need to be promoted, period. Otherwise, we're not going to be able to keep them.

And that's never a good reason to promote somebody, right? Because you don't uphold standards there forever be able to look at. And then you end up with a bunch of people that are not great. And every reason like, well, why shouldn't I be promoted? Because that clown is promoted, right? But by and large, I would say it was meritocratic. Yeah. I remember when I was on these committees, we would look at the accomplishments and the

complexity of the accomplishments, the impact that they made for the company, we look at the communication skills. We looked at, for its patent portfolios, were they helping the company with an intellectual property, which was important back then. I don't know how to have been important to it is now. But so it was generally pretty fair. And I saw Google, too. It was very fair.

There were, you know, very reasoned discussions about each person. So I think it is. I think it is. It's not just, you know, you ever see those charts where they have like a circle and then they have like little, like a sort of a polygon inside. Right, right. And it shows like how your intelligence. versus how your technical work is.

And it had to be pretty, you know, pretty well-rounded for the senior levels. Or at least be really good in some areas. So then at Google, you went to Google X working in a new cybersecurity division. And then a company was spun out of that, right? Chronicle, if I recall correctly. But it's still under the alphabet umbrella of companies. That's right. Which was then reacquired by Google Cloud.

Could you share a little bit more about that story? Yeah, sure. So we started as a stealth project. Nobody knew we were doing cyber security initially. The project name was Project Lantern, and this is inside of X. And we literally started from zero. We didn't know what we wanted to build. There were lots of debates. And we knew generally what we wanted to do. But we spent, I think, a good six months trying to just figure out what we were going to build. We then basically converged on an idea. We started hiring a bigger team, started working on, you know, building prototypes of the product out, finally got to an MVP, started to start to see. you know, shipping, working with partners, which was great. You're actually seeing real customers use it was super useful. And seeing that we would actually go into customer sites before we had the product and just watch how they did their work and saw where they struggled, which was super useful. Really interesting, actually, like watching cybersecurity teams work. Some of the people who were like stone, you know, they're clearly out of it.

You know, like these are the people that are using your product, you know, for better or worse. So the product was a product that cybersecurity engineers would use. Yeah, so the best way to think about, in a nutshell, about Chronicles' product, which was called Backstory, was basically cybersecurity today is a big data game, okay? And what you want to do, especially if you're trying to discover attacks in your environment or investigate attacks, which is a big part of cybersecurity. Some of it's proactive. Some of it's blocking the attacks before they come in, but a lot of it is they're going to get in and we have to know where they are, when they got in, what assets they accessed, and so on. And so, as it turns out, virtually all software and hardware that's used in corporations today generates huge amounts of logs. A firewall will have every connection, the source IP, the target IP, what protocol, web proxies

will tell you what websites were visited. What, again, what machine visited them? You have telemetry like DHCP that tells you like what machine IP is associated with a Mac address associated with the machine name. You have email logs. You have client logs. What software was installed, right? All that data is super valuable for identifying attacks.

Okay. But there's such high volume of that data that people couldn't really process it. And so the customers that we were starting to work with would use a competing product, which I won't name. But they would literally go, they would ingest a certain fraction of that data, very little of it because it was so expensive to maintain it. And they would go for coffee for 30 minutes while waiting for a query to finish to look up just one piece of information in that data.

And so we said, look, we have Google planet-sized compute, you know, and storage. How could we totally turn this around? Now, what we did was we built a product that would ingest all that data, pentabytes of data. Like literally some for some companies, you know, petabyte a week or a petabyte a month, a huge amount of data of, you know, every device, every connection, every file insulation, every settings change, like all that kind of stuff. And then we indexed it, and that's what I worked on. That was my sort of addition, like, so that it would be more like at the speed of a Google search than a 30-minute, let's go get some coffee. What would be a use case? Let's imagine that you discovered a piece of malware on a computer.

You might have a hash for that malware. You might know the IP address where it came down from or was downloaded. You might have the file name. You might know the directory was installed. Our product would allow you to take any of those artifacts and plug it in. and then we would instantly tell you which devices also have that artifact on them. What related artifacts there were to that? You know, so you could say, oh, well, this file had a different name, even though it had the same hash, let's say.

And so we'd better check for this name because this might be on some other computers so you can pivot. We could tell you how many devices were impacted in your environment. Who's those devices were? When was their first infiltration? When's the last infiltration? Is it still active and do that in like two seconds? You know, those kind of use cases? as opposed to 30 minutes where, you know, hopefully it gives you an idea.

You know, when it comes to Chronicle, even just doing the research, I got a little confused. Sounds like it spun out and then it came back in. What is the benefit of doing that stuff? Why not just do it, you know, within Google and that's kind of that? That's a great question. So I think X's initial goal was to create viable businesses, you know, that could spin out. and, you know, be world-changing. Okay.

And so we were following that playbook, which was, hey, let's incubate it. Let's get really good people work on. We have really smart people. Let's not encumber the team as much as we might, a normal Google team. Let them work fast. Let them do what they need to do. And then let's spit it out. You know, I can't really talk about why they required it.

Partly because I only have hypotheses and I don't know. but let's just say that it was a tight fit with Google Cloud. In other words, Google Cloud offers services to customers. This was a cloud-hosted service. It used a lot of storage and a lot of compute, which, by the way, Google Cloud had and Google Cloud could bill for, right? And so I think that for various reasons

which I can't talk about, after we spotted out, we were still in Alpha Company like Waymo. Okay, so we were still like under the alphabet umbrella. We were the C in Alpha. that for Chronicle. But I think they thought, you know, they had competing products. They wanted to integrate them. There were a bunch of reasons that they brought it back in and sort of integrated it. So we were for a time not part of Google. You know, for instance, Google, if you ever heard, but Google performance are notoriously lengthy and time consuming. And you

have to write pages of stuff about yourself and what you did and PRs that you did and all the, all the stuff, right? At Chronicle, we're like, we don't want to waste time in that. We want to build the project. So as soon as we spun out, we have. had one page performance reviews. And I think they were in a Google slide. It wasn't even like a big page of written stuff. So we could move more quickly, you know. And so that was great while it lasted.

Why is it that you eventually left Google? That's another one which has to do in part with imposter syndrome. It's a regular thing in my career. And in part it has to do with wanting to work at a startup as opposed to in a bigger, stodgier sort of Google environment, whereas things are more slower moving. there's more regulations and things you have to deal with, not that we didn't have to deal with those things in Chronicle, but more so.

Part of me didn't feel like, like there were interesting problems I could have done. For instance, the storage architecture that we came up with, part of which I built, and I think my code's still in there, I feel very proud of that, you know, six, seven years later, whatever it is. Part of that was an architecture, which was very expensive. And there were ways to basically move that into different file formats

and get off of things like Spanner, which was, you know, very heavy weight, where I could have dived in and tried to solve those problems and they'd be nice, big, juicy problems. I didn't have the confidence of myself to do that. And I, you know, I was afraid, especially when you get to senior levels,

there are very high expectations for you, right? And so, like, if you go off and try to do something and then people are like, well, what have you been doing the last couple months? And it didn't land. And, like, you're like, oh, I tried. You know, I didn't feel the confidence in our leadership that I could go off

and take those risks and have them have my back. It's semantic I did. Like I knew my bosses for years. And so they just knew that if I were going to go do something, I'd either be successful or if I failed and it was for a good reason. And they'd just give me the rope. Okay.

But at Google, I didn't quite feel like I had that. And they offered me other roles to, they said, oh, you want to work on secure databases. There were some really interesting things there of like, how do you compute and do database queries entirely in encrypted space, rather than decrypting and doing it, you know, basically taking private data and exposing it, where malware or other attacks can get to it.

There were interesting things. I really wanted to try something, you know, sort of over cybersecurity. And while I was at X, I was talking to all the Waymo guys, especially before Waymo even became Waymo. And I was learning all about self-driving cars. And so that was what I really wanted to do. And that's why I decided to leave. Yeah, before we get into the self-driving cars,

I'm curious because I talked to someone who felt the high expectations of the highest levels was a little bit limiting or kind of put too much pressure on them and they requested a demotion. Did you ever consider something like that? Not semantic. Is it semantic? I could do whatever I wanted to and it didn't really matter. Right, right. But at Google, I had thought about those types of things. Actually, you know, absolutely came to mind. The problem is that even at lower levels, there are certain expectations that I probably wouldn't have met if I want to go off for a couple months

and just think about something, which is the way I've been most successful in my career. And so, you know, I've got to be honest to you, I'm a loosey-goosey kind of guy. Like, I can produce prototypes and optimize algorithms and do, you know, interesting stuff. But when it comes to dotting every eye,

crossing every T, making sure I test every edge condition in my unit test, that's not my thing. I don't enjoy that. But at Google, well, that's just like, that's what you do. And so for me, that wouldn't necessarily made a difference because I would have had to do the things I didn't like to do

in order to do the things that I wanted to do. Okay, going into autonomous vehicles, so you went to Lyft. It sounds like that was mostly because of personal interests in the space. Can you talk about how you were hired in the story behind that? Sure. So at Lyft, I actually had a former student for UCLA that was working at Lyft. And he said, oh, you should come work here. It's really interesting.

And I thought, well, never. hire me because I actually tried to apply for Waymo when I was in Google in X. And, you know, again, this is another problem with being very senior. When you're very senior and you don't have domain expertise in a new space, they're less likely to say, oh, we'll take a, we'll try

you because you're very expensive, right? And, you know, you might not have the skills that they need and, you know, they're paying somebody that they can't use. So Waymo didn't want me instead of Google or else of that. So I said, well, they're probably not going to want me because I don't have any experience here.

but why not? And so my former student arranged a meeting with their president. We had had coffee. And then I went through an instead of interviews again, seven, eight interviews. Those did have some coding and design problems. That went fine. Fortunately, there was no dynamic programming because I can't do that. I mean, you just can't. Like, you know, maybe certain cases I can, but, you know, I'll fail every dynamic programming interview question. And I was hired. What were the projects like or what was the thing you were most interested in working on that you did. So for me, the big project that I sort of was proud of was transforming the architecture from one which was a classic robotics architecture, like you would have seen in the, you know,

even in Waymo until probably the mid, mid little 2010s, which was largely handwritten algorithms and, you know, sort of not expert systems, but handwritten algorithms that would make decisions like, oh, it's time to do a left turn. Let's run the left turn decision-making system and figure out, is it safe? Do we initiate? Do we initiate? Those systems, you know, in the mid-2010s,

we're using neural networks, but they were only using it for vision. So in other words, you know, recognizing vehicles, pedestrians, and so on, maybe their, you know, their angle and so on and their velocity and acceleration. But at Lyft, they were using that sort of earlier, approach, which I'm sure came up through places like Carnegie Mellon, where a lot of it was hand-coded. And to me, I looked at that, especially during my time at X, seeing neural networks and semantic,

even seeing neural networks and said, there's got to be a better way. Because if you start hard-coding an algorithm to figure out how to do a lane change, and then somebody swerves in front of you, now you're doing an avoidance maneuver, right? Now, avoidance maneuver, do you switch out of your lane change algorithm in order to do an avoidance algorithm or do you stay at lane chain and handle avoidance it just made no sense and so you know uh the team was also hand the sap was also hand parameterized so literally you know we're tweaks something how do how close do we want to get to the curve you know um okay how close are we willing to get to pedestrians what about bicyclists what okay so if we get too close to a bicyclist today let's tweak it and make that bigger but wait a second now it's

going to hurt our curb distance and so like there were you know a hundred parameters at all to be tweaked and it was a really difficult problem. And by the way, companies like Tesla were doing this until recently too. That approach and Waymo was doing that for a long time is a dead end. It's a dead end. And so the approach that, you know, I think that probably Waymo is using now, I don't know, but my guess is. And I know that Tesla is now using.

They've announced it is, you know, an end-to-end neural network-based perception and behavior planner system and prediction, you know, basically all and, you know, there might be multiple heads on these neural networks and there are multiple functions that they're, they're performing, but effectively it's a single or small number of networks working together to figure out the movement. And so figuring out and doing a lane change is not necessarily a lane change algorithm, although there may be a little bit of that, but it's mostly about, you know, we know we need to go there. We know there's a left turn lane. Let's, you know, let's start maneuvering into the left turn lane and turning on the signal.

And so my project that I was most proud of there, was basically designing with the head roboticist of the team, who were old school, by the way, an architecture which would accommodate basically an end-to-end or old network-based driver, but put guardrails on it. In other words, have a safety layer that would ensure that if the network went off the rails and told it to go through a red light,

we would slam the brakes. The safety layer would take precedence over the system. But the safety layer was there only for basically ensuring you know, the collusion has ever happened, basically bringing into a safe stop or basically, you know, following legal rules that the neural network may not do perfectly. Does that make sense? Right. That makes sense. And so that was, that was, I was very proud of that project. Unfortunately, this is a, this is like a bit painful for me.

I didn't get as much credit for that as I would have liked given the work I did, which is like one of the things I learned is like, you really have to cheat your own horn. You have to really talk about what you're doing. Somebody else took credit for a lot of that. but the hard and really great part of that was this was no coding really. This was all about working with roboticists who did not want to change the approach and getting them to consider a new approach, working together to define the approach together rather than the telling of how it should be. Because I didn't quite know, but by the way, I thought I had a better idea,

but they didn't want to hear that because I had no degree in robotics. And then eventually coming up with a product that was a collaboration, where they were able to buy in and push it themselves, if that makes sense. Right, right. And that was all, like, you know, influence and not, because I, in influence, but not based on my skill, because I don't, they didn't have any Thomas vehicle skill.

I think that's so common topic that people wonder when they're doing shared projects is how do you make sure you get credit for what you worked on? And so maybe you could talk about that. I wish I had a good recipe for that. I, you know, in general, when you're, when you're, when you're more junior, I think it really makes a lot of sense in the moment when you finish a project or you're almost done with it to take notes on what you did and what the big accomplishments were and what the metrics were so that when it comes time to write up a promo packet or even your sort of yearly review packet, you have all those details which you're going to forget later on. And even like two years later when you're going up for more senior promo, right? So having that, I think, is useful.

To be honest to you, I never did that. But in retrospect, that would have been very useful for me because I would come out of it from my head. and then ask people like, what was that? How much faster was that? Like, what now were we were able to detect that we could have detected before? But I think that does help a lot. And you have to shoot your own horn. Like, you know, when you're writing your performance review without embellishing,

I think embellishment is really bad, actually. But, you know, really state what you did and the value added and the sections that you worked on. Don't claim credit for everything. Claim credit for the parts that you worked on. Because I guarantee you when a committee is reviewing your packet, they're going to be like, wait, why are they taking credit for all this when we know that so-and-so did all of this great work?

And then you lose credibility. So because I've been on those committees, right? I've seen that. I've seen that happen. So, you know, be very specific and granular about what you did, what the benefits were, how you collaborated. I think that helps a lot. When you're more senior, it's more difficult because it's a lot of soft power.

It's a lot of, you know, influence. I was actually reluctant. Like, I didn't even try to take credit because, I didn't want to alienate my co-collaborators who also were part of this. And so I didn't go around and start talking to the president saying, we've come up with a new approach. I let them talk about it. I let their boss talk about it.

And that actually hurt me because I never got, you know, when it came to review time, they said, oh, their manager initiated this project. I'm like, what? Really? This is news to me. Oh, no. So. Yeah, right.

Yeah. So that was very, I have PTSD from that experience, I have to say. Before we leave Lyft, I'm kind of curious, because that space is super competitive. There's like, I don't know, a billion different self-driving companies, especially back then. What did it look like for Lyft to kind of win in that space? You know, it wasn't clear that we had a strategy to win in that space. We were definitely a nascent organization. I think they'd been around a couple of years when I first started versus like 10 years for Google and, you know, X working on that technology.

and then Waymo. So I didn't go in, for instance, thinking that I'd be building the next generation of self-driving car that would actually overtake a Waymo. I went in thinking, this is an opportunity to learn something new and work with really smart people. And that was my outcome that I was trying to achieve.

So I don't know if there was a plan necessarily. And the division was eventually sold to a subsidiary. So they got the IP, that's great for them. And at that point, I said, okay, I'm retired. You know, I'm kind of curious because how did you get into actually becoming a professor at UCLA and lecturing there? I know you get a lot of joy out of it.

What's the story behind going back and lecturing? So back when I was my late teens, early 20s, I was teaching programming in a place called Learning Tree, which you probably have never heard of. But Learning Tree is a for-profit school where they will teach you, guitar, knitting, and back then they started teaching programming. And it wasn't very easy to find people who could teach programming because it was early.

That was probably in 1990, 1991. So I applied because one of my friends was doing it, and I really enjoyed it. And I was teaching people from DeVry. You ever heard of DeVry? Oh, I've heard of that. These of those commercials, right? Well, they were trying to learn from me,

a learning tree so they could teach at DeVry back then because they didn't even have a programming class there. Right. So I was teaching people and really enjoyed it. And it felt really good to get up in front of people and explain things and try to be really clear. And so I had some experience doing that. And at UCLA when I was an undergrad, I would teach little classes. We found a room in the evening.

And I just invite people who had problems with some of the material and we'd just go over it on the whiteboard together, a blackboard. So I enjoyed that kind of stuff. And when I was at Samantha, one of my colleagues was a guy who was a part-time lecture at UCLA. We were having lunch, and I said, oh, you know, I really enjoyed teaching. And he's like, oh, you should apply. And I'm like, UCLA would never hire me. I don't have a PhD. It'll never happen.

And he said, you know, let me bring you an application just in case. And I said, okay, whatever you want. And a couple of days later, he brings this application. He's like, here, filled it out, gave it back to him. Didn't hear anything for months. I don't remember if it was six months. I don't remember how long it was. And two weeks before fall quarter of 2001, so like December of 2000,

I get this call, a frantic call from UCLA, can you still teach? Because our lecturer bails on it. And I said, of course. So I had two weeks to plan a curriculum and basically teach an undergrad course at UCLA. And, you know, it's 25 years later now. I'm very glad that they did end up picking you because you are one of the best lectures. I think so. I appreciate that.

A lot of my fears think so as well. And that's why I kind of want to ask you, how do you make, these CS lectures so engaging and interesting? Well, first of all, very kind of you to say that. So there are a couple things that go through my mind. So first thing is, remember I told you, I didn't think I was that smart.

So I think whatever intelligence I have and whatever level that is, helps me write better lectures because I feel like, unless I could understand something myself, being, I think, sort of slow, other people can't understand it too. And so I try to design lectures for what I think is,

one of the lower common denominators, which is myself. And I don't try to teach to the top 5% of the class. Maybe that's a problem for some people that I try to teach for the, maybe the 30th percentile, a 50th percentile. And I think, like, what would, what would I want to know if I were being taught this for the first time? I try to have empathy for the student. I think, like, where are they coming from? What have they learned about? Have they do? They even know this concept? Should I introduce this first before I do that? So I think a lot about, like, I try to put myself in their shoes and ask, what would they know, what concepts were they going to be fuzzy at versus concepts all pretty, pretty solid where I can just use the concept and explain it. And so that's a lot of what goes into my lectures.

And so just for now, like I'm trying to prove some slides. I'm literally spending days back and forth with chat GPT-O-3 discussing concepts and trying to simplify it so much, but still get the essence right. And then I'll go to Gemini and verify and see you figure out where they have. differences and then all, because there's a lot of materials in the internet that are actually really good, to be honest to you. And the textbooks all suck, too, I have to say. We talked about outcomes earlier. And for me, an important outcome is that students not only learn something, but enjoy the process. They don't, I want them to have a good time. And so I'm always thinking when I'm making slides, can I make them funny? Can I make some, some joke or something silly? Can I

make them like sort of colorful or, you know, add like an emoji or something to make it a little bit more fun so that there's just a little bit of surprise when they come to class. They never know what they're going to see. Might be a little inappropriate. You know, might be a little silly because I don't just want them to learn. I want them to learn and enjoy, I want to come to class. One thing I'm also curious because I think a lot of people are scared of public speaking, but I, you know, you're, you're very good out of it.

Do you have any tips on speaking well and practice? Just practice a lot. The more you do, the more fluent you're going to get. I even find, like, when I'm not teaching, you're not teaching. because I'm part-time teaching right now. I'm retired. I'm taking my dog for walks and working on side projects, playing with LLMs and stuff.

And I find that my speaking deteriorates over time when I'm not actively using it, even over the course of a year. And that might just because I'm getting older or whatever. But in general, I found it too, like earlier in my career. So if you want to get better at presenting, if you want to get better at communicating, you have to practice a lot.

And so that might mean getting a lunchroom and giving a talk about a project you're working on so that you can explain to other people, people what you're doing, even if you don't need to. You're not doing it because it's required to transfer over your project or to integrate some technology just to do it. And people love that, by the way. And you'll probably screw it up the first couple times. You'll get better and better at it. And eventually, you'll find that people will listen to you and take you more seriously if you're a great presenter, a great communicator. And in fact, story really quickly back to my time at Google X,

I remember, I actually had a talk that I used to give it to Man Tech. And I got permission. It was on Stux stat, I think, and on maybe malware detection. I had another one. And I got permission from Symantec to give that talk privately inside of X. And I remember people coming up to me afterwards and saying, wow, you know, you're one of the smartest people I've ever met. I'm like, literally, you really don't know. But people will think you're intelligent and they will give you more credit and they'll introduce you to other opportunities based on your ability to communicate, because people associate that with intelligence, if that makes sense. And like I can go into endlessly about times of my career where communicating effectively helped my career. So it's super important.

But yeah, practice. You know, with all the LOMs and, you know, AI coming in, are you seeing people cheat more often with LLMs? Are people learning less or more? Last year in fall, I allowed students to use LLMs, not to write the whole project, but for autocomplete or to write simple, you know, parts of the project, which weren't really relevant to the material that we were covering. And I think, in retrospect, you know, that was a bad idea because I think people were auto-completing a lot more than just like a function of uppercase a string or something, you know, like that kind of thing. You know, they were they were using it in ways that hindered learning. I've recently been reading a bunch of papers about how it helps and hinders learning. And actually, I don't know if you saw this recently a study at MIT that like synaptic connections are down from like 70% to 50% or something. I forget the numbers, but like it just saw a blurb.

when people use LLMs to solve a problem rather than working through it themselves. So I'm actually, this coming fall, I'll go to allow LLMs for learning, like clarifying concepts, asking for what does this mean? But I will not allow them ideally for projects because I believe that it did hurt understanding. And we saw that in exams. Like if you look at the exam understanding versus project scores, there's a big delta. Perfect project scores, but getting everything wrong. Although I have to say the projects were not solvable.

entirely with LMs, but you know, with the latest models now, you could probably get a 95% on, on, on them with really bad code, but we were, we were evaluating correctness, not code. How do you even tell if they're using LMs, though? One way you can tell is that when they auto-complete, often they'll auto-complete, the L-Ms will generate error checking, right? The error checking will typically have an exception with an error message. And the messages will be very consistent across different, implementations. And so, in fact, we have cheat checking software that checks N squared different,

you know, everybody's project against every else's project. And we will have flags where it's like 30% of this code is similar. And a lot of it is like word for word similar error messages and similar variable names and, you know, like similar idioms. And so like pretty obvious people are using these things extensively. You know, a lot of people are worried about LLMs kind of automating software engineering and, you know, should they even get? get a software engineering degree anymore. What do you think about that? It's a great question, and I think that it depends on what these models evolve into.

Imagine you could literally give a project to an LN, just like a junior engineer, and it would produce a component which is largely correct with tests, with security factored in, with proper modularity, DROI, all the other good stuff you want. if we get to that point where bigger and bigger tasks of more complexity are solved correctly with good style and no code smell and all the other good stuff, that is, let's call that like AGI programming for the time being, for the time being. Contrast with what we have today, which is models that can actually solve tightly specified sub-problems pretty well, build tests for them, but you still need some, you know, some supervision.

You know, did it use a good algorithm? Did it like do a deep copy when it should it on a shallow copy of a data structure, like all this stuff like this, right? I think if we stay in a world where we get really good but not AGI good, based on that definition I give you earlier, I think software engineers, software, you know, software engineering will still be a great feel to get into because someone is going to have to go and look at that code and understand the mission of the company and understand the standards and so on and then make sure that it's doing the right thing. And that requires real thinking and introspection and corrections.

And even if you have the model fixed things, you still have to know what to have it fixed. And so I do think that having that degree and having the skill of being able to write code and read code is super valuable. And we could talk about it if you want, like, but what about all the jobs going down right now, which may be caused by Elam's probably in part. So that's one situation.

The other situation, if you truly have an AGI where you can go and delegate something to it and it will do like a L5 job, it will do a really good job. It might need a little bit of a couple tweaks, but they're minor tweaks, takes on projects that would take weeks, just gets them done.

I think the world is a lot different. And in that world, where literally all the software of whatever complexity can be written correctly, securely with right tasks, I think all bets are off. I think it's a different set of skills that are necessary. Personally, I can tell you what I think those are, but I think it's different.

What are those skills? Project management, soft skills, those things? So in the world where software can be written, like arbitrarily complex software can be written, tested, you know, good style. Everything is, you know, good stuff like you'd expect of a senior engineer. To me, the world changes into a place where you're, where engineers are going to be focused, and maybe they're not even engineers anymore on what we build, not how we build it. Okay. So what problem are we solving?

Why are we solving it? I think of in that world, the greatest engineers will be people who really understand a problem that they're trying to solve for a customer. That might be an internal customer, might be a customer that you're like a consumer, might be a business. And you know exactly what pains they're facing and how they measure success and what gets them really pissed and what is hard for them to do now and you want to make easy. And then figuring out how to really.

clearly communicate to an L.M. Those requirements to get to do all that hard programming work that you would have had to do over weeks and months. And that is a really hard problem in its own right. So if people who have really great clarification skills, really great sort of

outcome analysis skills, like what outcomes is the customer trying to achieve? What are the metrics by which the customer measures success? What's important to them? What's not important to them in those outcomes? How can we communicate to a model in a way that tells a model what we needed to do

and to meet those requirements because models will get some of it wrong. Those are the people are going to be successful. And in that world, I think you have big companies like Google and meta and so on Amazon, but you're going to have

10,000 smaller companies that are going to now be able to tackle problems like building software for pet sitters that never was, you know, tackled before, you know, or building software for like doggy daycare. I think about that because our dog goes to a doggy daycare and the software just sucks that they use, right?

It's really bad. If you have a bunch of domain experts who can use these tools, now you have a million small businesses each solving a problem in a way that's really perfect for those customers and not having to worry about the engineering. Does that make sense? So it's a different world. Still a lot of software engineers, but different skills. What you said, it sounds like, and I don't know the product management function description too well, but it sounds like it. It sounds like someone who's understanding the customer, the business, communicating well. It's almost like the LLM is like a software engineering team, but it's, you know, a little query engine.

It would be like a competent product manager. And I got to say in my lifetime, I've met very few confident product managers. But yes, you could call it product manager would be a good name for it. Yeah. If product managers were actually competent, most of them or not, I got to say. What makes a competent product manager, by the way? You know, I think a competent product manager, a lot of them are good at communicating, although many are not. But a competent product manager in my mind is somebody who.

really understands, again, customer outcomes and customer metrics. So, like, for instance, if you've heard of jobs to be done or outcome-driven innovation, these are methodologies which are more deterministic and then just touchy-feely. So they actually have methodologies where they say this is how you discover a customer's outcomes. Like, what jobs are they trying to get done during their day? Where are they struggling? How do they measure success?

Like, what metrics are important to them? Like, you know, maybe, you know, like, for instance, when I'm brushing my teeth, I drool. I don't know about you. Do you draw any brush your teeth? Sometimes, yes. Yeah, I drew a lot. Like, I guess, like, I got a lot of saliva in it, okay? Yeah, yeah. And for me, like, one of the really annoying things about brushing my teeth is it, like, like, the drool, do I all down my arm, and I have to rinse my arm after I brush,

and it's, like, worn everywhere. And, like, that's a metric by which I judge whether my toothbrush is great. Of course, I haven't found a good one. Maybe I shouldn't design a toothbrush. But basically, you really need to understand the pains that customers go through and what they care about and what's really not that important because a lot of things that you might think are important internally, customer doesn't care about. So I think most product managers are touchy feeling. They're like, well, I think I know what the customer wants. And I think I saw the really cool feature in this product here. So I'm going to go and do what they did, but do it a little bit

better without really understanding what the customer is struggling with. How often they struggle with that thing? Is it important to fix? Or maybe it's not. Like, you know, maybe it seems cool to you and maybe they add that feature because they have some extra team members that can do it, but that's not necessarily the right thing. And so, yes, it would be a very competent product manager who really understands the customer, maybe worked in that environment, knows the problems, has suffered through the problems, and can then basically tell LLM how to solve that problem. I see.

So competence, if I'm understanding correctly, is user empathy. It's knowing what actually matters for them and building for that and communicating for that and measuring that. That's right. But a lot of people think that's a touchy-feely skill. Like it's something you just sort of develop and you sort of have intuition

about the customer. I think it is a repeatable process done through interviews, done through observing the customer. It's not something that you just sort of get better at by feeling it. It can be repeated, is what I'm saying. And very few product managers will do that.

I see. Most of them just say, oh, I know the product. I've been working on for five years. I know the customer. I talked to Joe last week, you know, a customer name, and this is what they really need.

You really know that? Like, you think you know that, but what are they trying to get accomplished? Right, right. You're typically thinking in terms of features, not in terms of customer pain points and what they're trying to get done. I see. In my experience. Right.

I'm sure there are instructions. Yeah, yeah, yeah. I'm sure there are. I just never meant any. Yeah. Okay. You know, coming to the end of the interview, I always love reflecting back on the careers. I think you've had a full career at this point, more retired at this point.

John, I'm curious, like looking back. on your career, is there anything that you regret or something that you wish you would have changed that maybe others can learn from? Yeah, I mean, a bunch of things. I would say, like, first of all, I should have left my job at Symantec earlier. I feel like you should stay in a job as long as you are learning new things and building new skills. And as long as you feel empowered to grow and try things that might be uncomfortable for you and not have to worry about your, you know, what if I fail occasionally? Like, have the space to try things and get you. get them wrong, but to be to build to create great things.

And I had that during a lot of my time at Symantec. But there was a point where I just wasn't growing anymore. And I was stagnant. And I didn't want to leave not because, you know, it was interesting, but because I just didn't have the confidence to go somewhere else. And so I would say there's a lot of value in staying in a job as long as you're growing. And that means maybe switching teams and staying in the same company. There's a lot of value of having that institutional knowledge of a platform that you're

working on or set of systems of your reputation. reputation goes a long way. If you were really good in one area, you switch through another team. You can use that reputation to help you in the other area often. And so I think staying in a job for five years, even 10 years,

can be, as long as you're learning, can be really great. I don't advise people to switch every couple of years necessarily. On the other hand, you know, staying too long, you know, you can get stale. It gets easy to just say,

you know, I'm comfortable. I'm not really having to be challenged. I can do my job. I can wake up, have some nice coffee in the morning and I do whatever I do and it doesn't really, you know, when you get more senior, often you can just do that. And so when you get to that point, it's time to leave and challenge yourself some more. And the problem with that is when you do leave, you do start over. Like, I found that I had a pretty great career at Symantec. If you asked

anybody at Semantic from the 21 years I was there who I was, would know me. They'd say, hide me in the hallway. I even had people come up to me on the street because I would be on TV talking about Stuxnet and stuff. Like, you know, I was in fall. and, you know, MSNBC and Wall Street Journal, New York Times, and we all that stuff. And it was really exciting. But then you go to Google and it'll like, what have you done for us? We don't care that you did those things. If only it matters what you've done for us.

And so that requires a lot of rebuilding up trust and building up, you know, sort of a reputation and doing a lot of good work. And, you know, that's stressful. And it takes a lot more work than staying where you are. So if you do that, you got to choose wisely. I hear I'll probably misattribute who said it, but there's some quote about you should either be learning or you should be earning in your career. What are your thoughts on your golden handcuffs somewhere? You're no longer learning, but you're earning a ton.

Would you still advise that that person leaves? I would never say, I would never say leave if there's a good package. And, you know, we have to optimize for multiple things in our life, right? Learning is definitely important, but also being financially stable and different. people need different amounts of money to feel comfortable about being safe in their life and having enough to take care of their family or themselves. I think there is a place for both and it can be okay to be comfortable and making a lot of money for a while. But I think that if you're solving for enjoyment and fun and hard problem solving, which a lot of people are, that can be toxic over too much time.

Definitely. It sounds like early in your career you were lucky to find what you enjoyed. A lot of those early problems were super interesting. Do you have any advice for people who want to find what they enjoy in software engineering? Yeah, for people who are in college now graduating soon, I would say like try lots of internships if you can. And that might be difficult now, given the way things are going with jobs. Everything's cyclical, but right now jobs are tough. I found cybersecurity entirely randomly. You know, wasn't something I was like, I want to be in cybersecurity. It's like, I had an internship. My first year was doing file management. My second year was doing blah, blah, blah. Third year, oh, viruses. The more you can explore, the more you're

going to potentially discover a passion. And like, I think there are many jobs where you would think it's going to be totally boring. But if you go and start working on the problem, you're going to realize there's really interesting problems to solve. And you might find a passion for a field that you would never expect that you would enjoy. And then you're like, wow, this is really interesting. There's really fun problems. Like the people I'm working with. customers are interesting or maybe they're a pain in the ass, but that's interesting to deal with. Like, I would say just try things. Don't try to wait and find the perfect job.

Find a job where you have a good manager. There's some hard problems to solve. And you don't know anything about it and you'll learn. Like, that's, you might find your dream job in that less than be 25 years. So before you know what you enjoy, you're saying, you know, search with breath. And then once you find it, then you can. can kind of go deeper. That's right.

I mean, look, you might get lucky. If your first year internship is really interesting and you're doing well, I would stick with that. You could try breath there, but I would say like a greedy breath. The last question I have for you is if you were going to go to yourself right when you were graduating from UCLA and give yourself some advice, knowing what you know now, what would you say? It wouldn't be one thing.

I mean, the biggest thing would be don't let fear of failure hold you back. you probably can do more than you think you can do. I might have had a richer career had I listen to that. I would say focus on the outcome. So whenever you're working on a project, think about who's going to use it, what do they care about? How do they measure success?

And then just optimize for that and don't like try to make the perfect thing or don't try to make a very, you know, round thing if all you need is a little square piece here. Like often problems can be solved without having to be perfect and still be really good. So like focusing on people that outcomes. Big one is when you're when you're presenting, for example, like this had to learn.

I used to go into presentations and talk about the technology to senior leaders. And like, in retrospect, those senior leaders don't care how the algorithm works. They don't care. They just want to know, is it going to be faster? How much faster? Is it going to generate more revenue? How much revenue? Is it going to, you know, fix a problem that currently takes 20 people to do it? Make it 10 people to do it. And so you really need to get in people's heads and think about what they're solving for. Again, this whole idea of this whole idea of, outcomes and then speak to their needs, not your own. So that's a big one. I said, find a good manager. I'll also say that again. A manager can make or break your career in your life and your, like,

happiness. So, you know, a good manager that trusts you and gives you some rope is super valuable. Learn how to collaborate with people just like, don't assume that you're right and just tell people they're wrong. You have to really learn to work with people and understand their point of view. I still struggle at that, but, you know, it's something. It's a work in progress. Those would be big things. Yeah, yeah. Well, thanks so much, Carrie, for your time.

I really appreciate it. I was really looking forward to it. I think there's a lot of stuff in here that people are going to benefit from. So thanks so much for your time. That was my pleasure. Hey, thanks for watching the show. I don't sell anything or do sponsorships, but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify.

And I'm always looking for new guests to interviews. So if anyone comes up who you think you really want to hear their career story, let me know, and I'll try to reach out to them and get them on the show. Thanks for listening as always, and I'll see you next time.