Carey Nachenberg grew to some of the highest levels of tech despite his imposter syndrome: a Chief Scientist at a GoogleX moonshot, a Symantec Fellow (their highest engineering rank), and a professor at UCLA. In our conversation, he shared the story of his rise to IC10 (VP equivalent), how top-level IC recruiting works behind the scenes, and how imposter syndrome affected him. We also explored his thoughts on developing “project taste” and how AI is reshaping the way his students learn and build today.
Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.
Timestamps
(00:54) Growth to Fellow at Symantec
(13:13) The most complex malware
(16:13) Why C was faster than assembly
(21:28) What matters more than intelligence
(43:40) Getting credit on collaborative projects
(46:53) Becoming a professor at UCLA
(53:23) How AI affected his students
(1:07:16) Finding work you enjoy
(1:09:03) Advice for younger self
Transcript
(00:54) Growth to Fellow at Symantec
Ryan:
Before we get into all the juicy parts of your career working at Google X or autonomous vehicles with Lyft, I wanna start by kind of laying the high-level groundwork. So you worked at Symantec for a long time and became their senior most, similar to a chief scientist type of role. Kind of wanted to go over that and all the lessons you might've learned there and anything interesting that came up there. So could you share the high level story arc of you working at Symantec, and how you grew to fellow?
Carey:
Totally. So I actually started back in, I think 1992 as an intern at Peter Norton Group. And so Peter Norton group was later acquired by Symantec, but some of your viewers are gonna remember Norton antivirus from Norton and Norton Utilities and so on and so, I think I was the first intern at Norton of Peter Norton computing.
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 back then in 1992, 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 of 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 work.
Ryan:
Was cybersecurity something that really, you were focused and really wanted a job in cybersecurity or it just by chance?
Carey:
At the time when I was working at Peter Norton Group, I wasn't working in cybersecurity. I was working on something called Norton Commander, which was a file utility manager.
I didn't actually work on cybersecurity until my third year, my third year of internships, at this point at 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.
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.
Ryan:
At Symantec, 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 L4, this is L5. And then kind of a lot of companies copied that. At Symantec, what did career progression look like?
Carey:
I would say the levels generally track to companies like Google and Facebook or Meta, going all the way from a junior software engineer through software engineer Senior, software engineer Staff and so on.
The levels were very similar. The difference was for me, at the very high levels of distinguished engineer and fellow at Symantec, when I went to Google, they basically said, we can't just hire fellows. We haven't experienced you. We don't know if you're gonna do well here.
Effectively I was downgraded to a staff, to a, principal engineer level eight from what would've been probably a level 10 at Symantec, a vice president role at Symantec.
Ryan:
What does the hiring process even look for people? So high level. Was that a tailored bespoke process?
Carey:
When I went to Google, basically the former Chief operating officer of Symantec, a guy named Steven 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 brought in and we had a one meet and greet with the company, 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.
Ryan:
For a lot of software engineers that are in the lower levels, the interviews are Leetcode, they're system design, and there's some generic behavioral interview. For, at the high levels, what does that loop even look like? Is it mostly behavioral? Are they asking you Leetcode stuff too?
Carey:
So I don't believe that I had any coding problems during that interview. If I recall correctly, there were some design. There was one design problem, but mostly these were leadership questions where, how would you solve a hard problem or how did you solve a hard problem in your career? How do you deal with conflicts? Tell me your thoughts on where the field is going. Google X is a forward looking, or acts rather, as a forward-looking organization. And so, some of the discussions were focused on that. Some of the discussions were literally sales pitches, 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 going through the motions of, having interviews and selling me on the role.
Ryan:
So then going back to Symantec, getting promoted to fellow, what did those higher level promos look like?
Carey:
At least at Symantec, most promotions go 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 a vice president or senior vice president was with a promotion. It was allowed, at higher levels for distinguished engineer and fellow.
There was basically a 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 did it 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 interesting the process we went through. And it wasn't just per division, it was for the company.
Ryan:
So when you got promoted to fellow, was that one of the happiest moments of your career or was it something you expected, not a big deal?
Carey:
The story was very interesting. I did not have to go through that process to get promoted to fellow. I was a distinguished engineer at Symantec, and they had that process. I wasn't part of it because I wasn't a distinguished engineer at the time that team was made.
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, we need to level set the role because the people at Symantec have never had this kind of role.
And I was nominated without my knowledge and it just happened. And then I kind of got a congratulations or maybe my boss Phil be and said, Hey, there's some discussions going on, and then you're a fellow. So they basically took the portfolio stuff and gave it to the team that did the evaluations. And that was the end of that.
Ryan:
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?
Carey:
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.
They move the needle for the company. I had so many of them under my belt at that time that they just said, the criteria are, this many projects should be done of this scope. And I had plenty more. And so they basically said, you're above the bar. 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 I did them.
Maybe a quick step back. At Symantec, it was the Wild West. There wasn't an engineering culture per se, there were just people working on stuff. And projects would often run really late because it was a little bit more of a wild west. We didn't have an agile process.
We didn't really do our own unit and integration tasks. We'd probe 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, do this. Here's a boxer on the project.
They basically said, Carey, you already know the technology 'cause you've been working on it as an intern. Go figure out what to do and do it. Which was amazing. 'cause here I am a junior software engineer and I got to work on whatever I wanted for my entire career. Semantic never assigned work to do.
It was crazy. Which was great. So I got to just pick projects that I thought would be impactful. I guess I got picked because 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, oh, I did increasingly. Bigger scope projects that somebody gave me.
Ryan:
So how'd you train that project taste? Because impact typically leads to career growth everywhere.
Carey:
That’s a good question. And it's, I look for things with big business impact. I looked where there were gaps. So way back when, this is old news now, but it's interesting. 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 they, there could be 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.
The problem with that is it worked really great, except it took six months. 'cause we shipped a new product every six months. And so it took six months to discover, to handle a virus. And then the next day somebody released three new viruses, which were slightly, slight variance or different viruses, but mostly the same.
And then all of that work would not work anymore. And so, I would look at that problem, I'd 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 using a Regex. You can't just search for a string to find these things.
That seems a really interesting, hard problem. So I picked it and then I started working on it. That was my master thesis, and then eventually transferred to the product.
Ryan:
If you were to think about the things that you took on, there were a series of, I guess, side projects or, whatever you wanted to take on where you'd take on this new thing, maybe something else would come in, you take that on. Is that kind of how you were working?
Carey:
I would say there were probably six or seven times in my career where I'm, oh, the company needs this type of thing. Let me go spend six weeks, two months, five months, figuring out what that looks, building prototypes, talking to engineers and figuring out what they need.
And then, building that. And there were other times, which is probably 80% of my career, where I was just 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, and improving. Those were incremental improvements on those systems. But it's one of those two things generally.
(13:13) The most complex malware
Ryan:
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. I think that's such an interesting story. Can you tell me a little bit about Stuxnet?
Carey:
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 Mac machines or Windows machines. It infected, I think, windows machines, but also microcontrollers that would actually run centrifuges and so on.
So it was probably the first multi-platform piece of malware we had discovered. Used zero days in order to break into systems. Basically 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 six different vulnerabilities to spread, many of which were zero days. Oh my God, it would literally stealth itself. So on your computer, if you were to look at a thumb drive, which had Snapchat on it, and look in your, your finder application or your Windows file system application, you would see 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 controller that ran the frequency converters, you would not see any of the textile 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 piggyback on back and forth stealth itself. It was just amazing. And then of course, how it disrupted the centrifuge is super interesting as well.
Ryan:
It's so complicated and sophisticated that it makes me wonder who wrote it and I saw something: it was 50 times bigger than the average virus. Incredibly complicated software. And I was reading into Wikipedia a little bit before, it kind of, it said, no one has claimed credit for who wrote this thing. Who do you think wrote this thing?
Carey:
I think it's pretty good. You'd be pretty safe to say it was the Israelis and the American government. My understanding or recollection is that there are, not watermarks, but coding styles or things in there that implicate both governments.
Ryan:
Have you ever looked at the source code?
Carey:
I have not. I didn't do any analysis on Stuxnet. My career was focused early on analyzing malware literally looking at the machine language and dissembling and so on. But later on in my career, it was mostly about detecting. So it was, how can I build algorithms to detect that malware rather than hands-on analyzing the malware myself? So I never looked at Stuxnet.
(16:13) Why C was faster than assembly
Ryan:
You mentioned a little bit about assembly code. Did you ever write assembly code when you were working at Symantec?
Carey:
I did, yeah. I wrote Assembly Code as an intern, and, although back in those days it was mostly C. 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, this really needs to be a C so it's more maintainable. So we actually made it faster because the people back then, people didn't know algorithms. They didn't understand what a big O was, they would do linear searches.
And so we were able to go and take something in assembly language, move it over to C, have less code, and it would be five times faster.
Ryan:
I see. So the speed ups moving from assembly to C was due to better algorithms and things like that. It wasn't because of a compiler or something.
Carey:
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.
(17:17) Imposter syndrome
Ryan:
You worked at Symantec for a long time and, I think in the tech industry it's common for people to move around here and there. What do you think kept you at Symantec as long as you were?
Carey:
That's a great question. If I have to be perfectly honest, I would say imposter syndrome. At Symantec I didn't really have imposter syndrome because I had done a lot of stuff and I was regarded.
I was known in the company and so I had a good, safe place, but I always worried, what if it is just because I'm at Symantec and I grew up here and I learned this stuff here. What if I went somewhere else, I wouldn't be able to learn this stuff. Or what if people had different standards and what if, 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 after, to be honest with you, I wasn't doing things that made me happy. When you get more senior, you do a lot more BS. 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 go to meetings and 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 Symantec, but I was afraid that I wouldn't be able to do it or I'd fail the interview process. And so I just stayed. And it was comfortable.
Ryan:
Throughout your career there were so many promotions and you had so much impact for someone like you to have imposter syndrome, I feel that shows it's a very natural feeling for a lot of people. Eventually, you did leave Symantec, so was there anything that helped you overcome imposter syndrome?
Carey:
The thing 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, I'm probably gonna fail this interview. I'm sure I'm not good enough, but I'm gonna do it. And so I just did it. And so that, 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 in my head, I was, I wasn't competent to do that job.
Ryan:
You mentioned, also that at the highest levels there's a lot of BS and, I guess it sounds like meetings. Do you have any tips on how to be less involved in the BS? Because I think that's a natural pull for anyone.
Carey:
Yeah, it's natural, definitely. It depends what you're doing. Some tech 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 an IC through my entire time at Symantec.
Other people would actually manage teams and work closely on projects. It's just, it's inevitable. In other words, you're having more strategic meetings, right? 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 posturing for power. There's a lot of garbage that comes with being more senior, unfortunately. 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 are you doing? And I, and I'm just cranking and trying things. That doesn't work, but that does. Super exciting.
Then you get into a room with seven people, and we've agreed that this is our new company strategy. One of my last roles in the company I did was actually define the company technology strategy for the whole company.
And everybody agreed to it. The CE had agreed to it, and then we'd get in a room and everybody would say, oh sure, but, we have to make money on our projects or products. And so, adding those features to align with the technology strategy that's gonna set us back. And we've been told we have to make this much top line revenue. And so, you end up having debates and discussions and it's very draining.
(21:28) What matters more than intelligence
Ryan:
So you said you were pulled into Google X and you ended up taking the interview. I'm curious, entering Google or this FAANG style big tech, were there any cultural differences that stood out to you?
Carey:
Fewer than you would think. I would say the biggest difference that I saw there was there were really, really smart people. 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, it was more a little looser or busier than 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 it were, there were many people in Symantec who didn't have good 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 that were feasible, at least in my opinion.
So I think that's an attribute of engineers no matter what company, no matter how intelligent people are. But it was, it was startling how much, how much brilliance there was. Right. And I do remember, there was one guy who was clearly over 200 iq. The guy was just, he'd talked to him and he was just astoundingly brilliant.
And he was still in L four. Why was it in L four? Because he had a lack of communication skills, worked on really interesting stuff that was interesting to him, but not necessarily had a business impact. Didn't collaborate apparently. There were things, whatever it was. And it didn't matter that he was brilliant, he was twice as smart as I was.
But, just because you have intelligence doesn't mean you're gonna be successful. I saw the same thing there.
Ryan:
If I'm understanding correctly, if you are very ambitious and you really want 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. Is there anything else that comes to mind?
Carey:
There are definitely people who are less intelligent. At Google, we didn't have too many of those people. Most people were really quite smart.
So I would say you need to have a baseline level of intelligence. But I, for instance, don't think I'm a really intelligent person. I take forever to learn new things. I have this ramp, which is this, at least internally, that's how I feel. You don't need that much intelligence.
Be successful, but enough. 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 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. 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 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. They know about the technology they wanna build, they know that they wanna make it 10% faster or whatever it is or, 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 gonna 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. There are requirements that are unimportant, requirements that are super important. So focusing on the most important requirements and doing that work. Focusing on the most important outcomes for your division or company is gonna get you far, much farther than being intelligent, I would say.
Ryan:
I think you have an interesting perspective because you're in academia, 'cause you're lecturing at UCLA, but you've also had a lot of success in the industry. When I was in school, everything was very obviously intelligence based.
There’s a test. You either get it right or not. Aside from group projects and things that, obviously coming from that place, intelligence feels everything. And then you get to industry and I agree with you a hundred percent. Intelligence is not everything in industry. Because in college it's very obviously meritocratic, whereas in industry there's other things too. Would you say that career growth is meritocratic in industry?
Carey:
In my experience, there were cases where people were being promoted because a vice president basically pushed really hard, or the SVP pushed really hard and said, they need to be promoted, period, otherwise we're not gonna be able to keep them.
And that's never a good reason to promote somebody, right? Because you don't uphold standards there for everybody else to look at. And then you end up with a bunch of people that are not great and everybody's like, why should I be promoted because that clown is promoted. But by and large I would say it was meritocratic.
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 communication skills. We looked at, for instance, patent portfolios. Were they helping the company with intellectual property?
Which was important back then. I dunno how important it is now. It was generally pretty fair. And I saw Google too. It was very fair. There were very reasoned discussions about each person. So I think it is, You ever see those charts where they have a circle and then they have a polygon inside? And it shows how your intelligence is versus how your technical work is. And it had to be pretty rounded for the senior levels or at least be really good in some areas.
(28:03) Experience at GoogleX
Ryan:
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. Which was then reacquired by Google Cloud. Could you share a little bit more about that story?
Carey:
Sure. So we started as a stealth project. Nobody knew we were doing cybersecurity. Initially. The project name was Project Lantern and this is inside of X.
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 gonna build. We then basically converged on an idea. We started hiring a bigger team, started working on building prototypes of the product.
Finally got to an MVP, started shipping, working with partners, which was great, actually seeing real customers use it was super useful. And seeing that we would, 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.
It was really interesting actually watching cybersecurity teams work. Some of the people who really liked Stone, they're clearly out of it. These are the people that are using your product, for better or worse.
Ryan:
So the product was a product that cybersecurity engineers would use?
Carey:
Yeah. The best way to think about in a nutshell about Chronicle's product, which was called Backstory, was basically cybersecurity. Today is a big data game. And what you wanna 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 gonna 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 locks. Firewall will have every connection. The source IP, the target IP, what protocol web proxies will tell you what websites were visited, what machine visited them.
You have telemetry DHCP, that tells you what machine. IP is associated with a Mac address associated with a machine name. You have email logs, you have client logs. What software was installed, right? All that data is super valuable for identifying attacks.
But there's such a 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. 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 and storage. How could we totally turn this around? And what we did was we built a product that would ingest all that data, petabytes of data literally some, for some companies, a, petabyte a week or a petabyte a month, a huge amount of data of, every device, every connection, every file, installation, every settings change all that kind of stuff.
And then we indexed it. And that's what I worked on. That was my addition. So that it would be more, 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 it 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 could say, oh this file had a different name even though it had the same hash, let's say. And so we did a better check for this name. Because this might be on some other computers. So you could pivot, we could tell you how many devices were impacted in your environment, whose those devices were, when was the first infiltration?
When's the last infiltration? Is it still active? And do that in two seconds. Those kinds of use cases. As opposed to 30 minutes. Hopefully that gives you an idea.
Ryan:
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's the benefit of doing that stuff? Why not just do it, within Google?
Carey:
That's a great question. So I think X's initial goal was to create viable businesses that could spin out and be world changing.
We're following that playbook, which was: Hey, let's incubate it. Let's get really good people to work on it. 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 fit it out.
I can't really talk about why they required it, partly because I only have a hypothesis 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?
So I think that for various reasons, which I can't talk about, after we spun it out, we were still an alphabet company. For Chronicle, I think they thought they had competing products, they wanted to integrate them.
There were a bunch of reasons that they brought it back in and integrated it. So we were, for a time, not part of Google.
I dunno if you've ever heard, but Google performance reviews 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.
Chronicle, we don't wanna waste time on that. We wanna build a project. So as soon as we spun out, we had one page performance reviews and I think they were in a Google slide. It wasn't even a big page of written stuff. We could move more quickly. That was great while it lasted.
(34:24) Leaving GoogleX
Ryan:
Why is it that you eventually left Google?
Carey:
That's another one which has to do in part with imposter syndrome is 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 Google environment. Whereas things are slower moving and there's more regulations and things you have to deal with.
Not that we didn't have to deal with. More so, part of me didn't feel there were interesting problems that 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.
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 Spanner, which was very heavyweight where I could have dived in and tried to solve those problems and they'd be really nice, big, juicy problems.
I didn't have the confidence in myself to do that and I was afraid, especially when you get to senior levels, there are very high expectations for you. And so if you go off and try to do something and then people are, what have you been doing the last couple months and it didn't land?
I didn't feel the confidence in our leadership that I could go off and take those risks and to have them have my back. It's semantic. I did, I knew my bosses for years and so I, they just knew that if I were gonna 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.
But at Google I didn't quite feel I had that. And they offered me other roles too. They said, oh, you wanna work on secure databases? There were some really interesting things there: how do you compute and do database queries entirely in encrypted space rather than decrypting and doing it? Basically taking private data and exposing it where malware or other attacks get to it or interesting things.
I really wanted to try something 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.
Ryan:
Before we get into the self-driving cars, I'm curious, 'cause 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?
Carey:
At Symantec, I could do whatever I wanted to and it didn't really matter. But at Google I had thought about those types of things actually, absolutely came to mind. The problem is that even at lower levels, there's certain expectations that I probably wouldn't have met if I wanted to go off for a couple months and just think about something, which is the way I've been most successful in my career.
I gotta be honest with you, I'm a loosey goosey kind of guy. I can produce prototypes and optimize algorithms and do really interesting stuff. But when it comes to dotting every i, 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, that's just, that's what you do. And so for me,that wouldn't have necessarily made a difference because I would've had to do the things I didn't want to do in order to do the things that I wanted to do.
(37:43) Experience at Lyft
Ryan:
Going into autonomous vehicles. So you went to Lyft. It sounds like that was mostly because of personal interest in the space. Can you talk about how you were hired in the story behind that?
Carey:
Sure. So at Lyft, I actually had a former student from UCLA that was working at Lyft. And he said, oh, you should come work here. It's really interesting. And I thought they'll never hire me because I actually tried to apply for Waymo when I was in Google, in X.
And, 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 try you, because you're very expensive. You might not have the skills that they need and they're paying somebody that they can't use.
So Waymo didn't want me instead of Google or Alphabet. So I said, they're probably not gonna want me 'cause I don't have any experience here, but why not? And so, my former student arranged a meeting with their president and we had coffee. And then I went through a set 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. Maybe in certain cases I can but I'll fail.
Ryan:
What were the projects? Or what was the thing you were most interested in working on that you did?
Carey:
So for me, the big project that I was proud of was transforming the architecture, from a classic robotics architecture. Even in Waymo, until probably the mid to late 2010s, it was largely handwritten algorithms. Not expert systems, but handwritten algorithms that would make decisions: 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 not initiate, those systems, in the mid 2010s were using neural networks, but they were only using it for vision. So in other words, recognizing vehicles, pedestrians, maybe their angle, and their velocity and acceleration.
But at Lyft, they were using that 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 look at that, especially during my time at X, seeing neural networks in Symantec. I said, there's gotta 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.
Do you switch out of your lane change algorithm in order to do an avoidance algorithm? Or do you stay in lane change and handle avoidance? It just made no sense. And so, the team was also hand, the stack was also hand parametrized. So literally, they’ll tweak something: how close do we wanna get to the curve? How close are we willing to get to pedestrians? What about bicyclists? What about what, 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 gonna hurt our curb distance. And so, there were a hundred parameters that all had to be tweaked and it was a really difficult problem.
And by the way, companies like Tesla were doing this until recently too. Waymo was doing that for a long time. It’s a dead end. And so the approach that I think that Waymo's probably using now, I don't know. But my guess is, and I know that Tesla is now using, they've announced it is, an end-to-end, neural network based, perception and behavior planner system and prediction.
There might be multiple heads on these neural networks and there are multiple functions that they're performing, but effectively it's a single or small number of networks working together to figure out the movement. 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 the, we know we need to go there, we know there's a left turn lane, let's, let's start maneuvering into the left turn lane and turning on the signal.
The project that I was most proud of there was basically designing with the head roboticists of the team. Who were old school by the way, an architecture which would accommodate basically an end-to-end or network based driver, but put guardrails on it. In other words, have a safety layer that would just 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 that collisions never happened. Basically bringing you to a safe stop or basically, following legal rules that the neural network may not do perfectly. Does that make sense?
I was very proud of that project. Unfortunately, this is a bit painful for me. I didn't get as much credit for that as I would've liked given the work I did, which is, one of the things I learned is, you really have to toot 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 there was no coding really. This was all about working with roboticists who did not wanna change the approach and getting them to consider a new approach working together to define the approach together rather than telling them how it should be.
Because I didn't quite know. 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. And that was all, influence and not. I had influence, but not based on my skill. Because I don't have any autonomous vehicle skills.
(43:40) Getting credit on collaborative projects
Ryan:
I think that's some 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. Maybe you could talk about that.
Carey:
I wish I had a good recipe for that. In general, when you're more junior, I think 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 yearly review packet, you have all those details, which you're gonna forget later on, and even two years later when you're going up for a more senior promo.
Having that I think is useful. To be honest with you, I never did that. But in retrospect, that would've been very useful for me. Because I would come out of it from my head and then ask people, what was that? How much faster was that? What are we able to detect that we couldn’t have detected before?
But I think that does help a lot. And you have to toot your own horn, when you're writing your performance review, without embellishing, I think embellishment is really bad actually. But, 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's reviewing your packet, they're gonna be, 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. Because I've been on those committees, right?
I've seen that happen. 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 influence. I was actually reluctant, 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 when it came to review time, they said, oh, their manager initiated this project.
Really? This is news to me. I have PTSD from that experience, I have to say.
Ryan:
Before we leave Lyft, I'm kind of curious, because that space is super competitive. There's, 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?
Carey:
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 years when I first started versus 10 years for Google and X working on that technology and then Waymo.
I didn't go in thinking that I would be building the next generation of self-driving car that would actually overtake 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.
I don't know if there was a plan necessarily, and the division was eventually sold to an alternative subsidiary. Great for them. And, at that point I said, I'm retired.
(46:53) Becoming a professor at UCLA
Ryan:
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?
Carey:
So, back when I was in my late teens, early twenties, 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 gardening, 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 'cause one of my friends was doing it and I really enjoyed it. And I was teaching people from DeVry. They used to have those commercials, right? They were trying to learn from me at Learning Tree so they could teach at DeVry back then.
Because they didn't even have a programming class there. I was teaching people and really enjoyed it and it felt really good, too. I get up in front of people and explain things and try to be really clear. And, so I had some experience doing that at UCLA when I was an undergrad. I would teach little classes, we would find a room in the evening and I'd just invite people who had problems with some of the material and we'd just go over it on the whiteboard together.
I'd enjoyed that kind of stuff. And when I was at Symantec, one of my colleagues was a guy who was a part-time lecturer at UCLA. We were having lunch and I said, oh, 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.
He said, let me bring you an application just in case. And I said, whatever you want. A couple days later he brings this application. I filled it out and gave it back to him. Didn't hear anything for months. I don't remember if it was six months, a year, I don't remember how long it was.
And two weeks before fall, quarter of 2001. In December of 2000, I got this call, a frantic call from UCLA. Can you still teach? Because our lecturer bailed on us. And I said, of course. So I had two weeks to plan a curriculum and basically teach an undergrad course at UCLA, and it's 25 years later now.
(49:13) How to speak well
Ryan: I'm very glad that they did end up picking you because you are one of the best lecturers and I think a lot of my peers think so as well. I kind of wanna ask you, how do you make these CS lectures so engaging and interesting?
Carey: First of all, it was very kind to you to say that.
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 that is, whatever level that is, helps me write better lectures because 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, but I try to teach for maybe the 30th percentile to 50th percentile.
And I think, what would I wanna know if I were being taught this for the first time? I try to have empathy. For the student. I think, where are they coming from? What have they learned about, do they even know this concept? Should I introduce this first before I do that?
So I think a lot about it. I try to put myself in their shoes and ask what would they know? What concepts were they gonna be fuzzy at? Versus concepts sell pretty f pretty solid where I can just use the concept and explain it. And so that's a lot of what goes into my lectures.
I'm literally spending days back and forth with ChatGPT o3 discussing concepts and trying to simplify it so much, but still get the essence. And then I'll go to Gemini and verify, see, figure out where they have differences, because there's not a lot of materials on the internet that are actually really good, to be honest with you.
And the textbooks all suck too. We talked about outcomes earlier, and for me, an important outcome is that students not only learn something, but enjoy the process. 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 joke or something silly?
Can I make them colorful or add 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 gonna see. Might be a little inappropriate, might be a little silly because I don't just want them to learn. I want 'em to learn and enjoy and want to come to class.
Ryan:
One thing I'm also curious about, 'cause I think a lot of people are scared of public speaking, but you're very good out of it. Do you have any tips on speaking?
Carey:
Practice. Just practice a lot. The more you do, the more fluent you're gonna get.
I even find when I'm not teaching, 'cause 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. That might just be 'cause I'm getting older or whatever.
But in general, I found this true, earlier in my career. 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 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, a story really quickly back to my time at Google X, I remember I actually had a talk that I gave to Symantec and I got permission. It was on Stuxnet, I think, and maybe malware detection. 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'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'll 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 I can go on endlessly about times in my career where communicating effectively helped my career. So it's super important. But yeah, practice.
(53:23) How AI affected his students
Ryan:
With all the LLMs and AI coming in, are you seeing people cheat more often with LLMs? Are people learning less or more?
Carey:
Last year in fall I allowed students to use LLMs, not to write the whole project, but for auto complete or to write simple parts of the project which weren't really relevant to the material that we recover.
I think in retrospect, that was a bad idea because I think people were auto-completing a lot more than just a function uppercase string or something, that kind of thing. They were using it in ways that hindered learning. I've recently been reading a bunch of papers about how it hinders learning and it actually, I dunno if you saw this recently, a study at MIT that synaptic connections are down from 70% to 50% or something.
I forget the numbers, but I 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'm going to allow LLMs for learning clarifying concepts, asking for what does this mean? But I will not allow them for projects because I believe that it did hurt understanding. And we saw that on exams. If you look at the exam understanding versus project scores, there's a big delta.
Ryan:
Perfect project scores, but getting everything wrong.
Carey:
Although I have to say the projects were not solvable entirely with LLMs, but you, the latest models now you could probably get a 95% on them, even with really bad code. But we were evaluating correctness, not code.
Ryan:
How do you even tell if they're using LLMs though?
Carey:
One way you could tell is that, often they'll auto complete. These elements will generate error checking, right? The error checking will typically have an exception with an error, a message and the messages will be very consistent across different implementations.
And so in fact, we have cheat checking software that checks everybody's project against every else's project. And we will have flags where it's 30% is coded, is similar, and a lot of it is word for word similar error messages and similar variable names, similar idioms. Pretty obvious people are using these things extensively.
Ryan:
A lot of people are worried about LLMs automating software engineering and, should they even get a software engineering degree anymore? What do you think about that?
Carey:
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 LLM, just like a junior engineer, and it would produce a component, which is largely correct, with tests, with security factored in, with proper modularity, DRY, 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 AGI programming for the time being.
Contrast that with what we have today, which is a model that can actually solve tightly specified sub problems, build tests for them, but you still need some supervision. Did it use a good algorithm? Did it do a deep copy when it should have done a shallow copy of a data structure?
I think if we stay in a world where we get really good, but not AGI good, based on that definition I gave you earlier. I think software engineering will still be a great field to get into because someone is gonna 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 to fix things, you still have to know what to have to fix. I do think that having that degree and having the skill of being able to write code and recode is super valuable. We could talk about it if you want. What about all the jobs going down right now?, Which may be caused by the LLMs 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 a L five job, it will do a really good job.
It might need a couple of tweaks, but they're minor tweaks. Takes on projects that would take weeks, just gets them done. I think the world's 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.
And I think it's a different set of skills that are necessary personally, and 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 a world where software can be written arbitrarily, complex software can be written, tested.
Good style. Everything is good stuff you'd expect of a senior engineer. To me, the world changes into a place where you're, where engineers are gonna be focused. And maybe they're not even engineers anymore on what we build, not how we build it. What problem are we solving? Why are we solving it?
I think 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 a consumer, might be a business. And exactly what pains they're facing and how they measure success and what gets 'em really pissed and what is hard for them to do now.
And you wanna make it easy. And then figuring out how to really clearly communicate to an LLM, those requirements to get to do all that hard programming work that you would've had to do over weeks and months. And that is a really hard problem in its own right. People who have really great clarification skills, it's really great.
Outcome analysis skills: 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 need it to do and to meet those requirements?
Because models will get some of it wrong. Those are the people that are gonna be successful. And in that world, I think you have big companies Google and Meta and so on Amazon, but you're gonna have 10,000 smaller companies that are gonna now be able to tackle problems building software for pet sitters.
It never was tackled before. Or building software for 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 that 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.
Ryan:
What you said, it sounds, and I don't know, the product management function, description too, but it sounds, it sounds like someone who's understanding the customer, the business communicating. It's almost the LLM is a software engineering team, but it's a little query engine.
Carey:
It would be a competent product manager and I, and I gotta say in my life, in my lifetime, I've met very few competent product managers. But yes, product manager would be a good name for it. Yeah. If program product managers work actually competent, most of them are not, I gotta say.
Ryan:
What makes a competent product manager, by the way?
Carey:
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 for instance, if you've heard of Jobs to be Done or Outcome driven innovation, these are methodologies which are a little more deterministic and then just touchy-feely. So they actually have methodologies where they say, this is how you discover a customer's outcomes. What jobs are they trying to get done during their day? Where are they struggling? How do they measure success?What metrics are important to them?
For instance, when I'm brushing my teeth, I drool, I don't know about you. Do you drool when you brush your teeth?
Ryan:
Sometimes, yes.
Carey:
Yeah, I drool a lot. I guess I got a lot of saliva. And for me one of the really annoying things about brushing my teeth is that the drool goes all down my arm and I have to rinse my arm after I brush, and it's going everywhere.
That's a metric by which I judge whether my toothbrush is great. Of course I haven't found a good one. Maybe I should design a toothbrush. But basically, you really need to understand the pain points 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, the customer doesn't care about. So I think most product managers are touchy feely. They’re, “I think I know what the customer wants and I think I saw a really cool feature in this product here, so I'm gonna go and do what they did, but do it a little bit better without really understanding what the customer is struggling with.”
Like, how often do they struggle with that thing? Is it important to fix? Or maybe it's not, maybe it seems cool to you and maybe they have that feature because they have some extra team members that could 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.
Ryan:
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, and all those things.
Carey:
That's right. But a lot of people think that's a touchy feely skill. It's something you just develop and you 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 get better at by feeling it can be repeated is what I'm saying. And very few product managers will do that. I see most of 'em just say, oh, I know this product. I've been working on it for five years. I know the customer. I talked to Joe last week at, customer name and, this is what they really need. You really know that. you think that, but what are they trying to get accomplished?
Product managers typically think in terms of features, not in terms of customer pain points and what they're trying to get done.
In my experience. I'm sure there are exceptions. I just never met any.
Ryan:
Coming to the end of the interview, I always love reflecting back on the careers. You've had a full career at this point, more. Retired at this point.
(1:03:53) Career regrets
Ryan:
So I'm curious looking back on your career, is there anything that you regret or something that you wish you would've changed that maybe others can learn from?
Carey:
Yeah, a bunch of things. I would say, first of all, I should have left my job at Symantec earlier. I feel 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, what if I fail occasionally have the space to try things and get 'em wrong, but to be, to be able 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 wanna leave. Not because 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 in 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 to 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 years, necessarily.
On the other hand, staying too long, you can get stale. It gets easy to just say, I'm comfortable. I'm not really having to be challenged. I can do my job. I can wake up and have some nice coffee in the morning and I do whatever I do. 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. I found that I had a pretty great career at Symantec. If you asked anybody at Symantec from the 21 years I was there, who I was, people would know me. They'd say hi to me in the hallway. I even had people come up to me on the street 'cause I would be on TV talking about Stuxnet and stuff, I was on Fox and MSNBC and Wall Street Journal, New York Times and all that stuff.
And it was really exciting. But then you go to Google and they're, what have you done for us? We don't care that you did those things. It only matters what you've done for us. And so that requires a lot of rebuilding up trust and building up a reputation and doing a lot of good work and that's stressful. It takes a lot more work than staying where you are. So if you do that, you gotta choose wisely.
Ryan:
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: you're golden handcuffed somewhere, you're no longer learning, but you're earning a ton. Do you, would you still advise that person leaves?
Carey:
I would never say, I would never say leave if there's a good package and, 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 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.
(1:07:16) Finding work you enjoy
Ryan:
Definitely. It sounds like early in your career you were lucky to find what you enjoyed. A lot of those early pros were super interesting. Do you have any advice for people who want to find what they enjoy in software engineering?
Carey:
Yeah. For people who are in college now and are graduating soon, I would say, try lots of internships if you can, and that might be difficult now, given the way things are going with jobs right now. Everything's cyclical though, but right now jobs are tough. I found cybersecurity entirely randomly, wasn't something I was, I wanna be in cybersecurity. I had an internship my first year, was doing file management. My second year was doing blah, blah, third year. Oh, viruses.
The more you can explore, the more you're gonna potentially discover a passion and. I think there are many jobs where you would think it's gonna be totally boring, but if you go and start working on the problem, you're gonna 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. 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. 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. You might find your dream job and that lasts 25 years.
Ryan:
So before you know what you enjoy, you're saying, search with breadth. Totally. And then once you find it, then you can kind of go deeper.
Carey:
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 breadth there. But I would say a greedy breadth.
(1:09:03) Advice for younger self
Ryan:
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 now, what would you say?
Carey:
It wouldn't be one thing. 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 listened to that. I would say focus on the outcomes. So whenever you're working on a project, think about who's gonna use it, what do they care about, what, how do they measure success? And then just optimize for that. Don't try to make the perfect thing or don’t try to make a very round thing.
If all you need is a little square piece here, often problems can be solved, without having to be perfect and still be really good. So focusing on people's outcomes.
Big one is when you're presenting, this I had to learn. I used to go into presentations and talk about the technology to senior leaders and, in retrospect, those senior leaders don't care how the algorithm works. They don't care. They just wanna know, is it gonna be faster? How much faster is it gonna generate more revenue? Fix a problem that currently takes 20 people to do it, make it so 10 people 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 outcomes. And then speak to their needs, not your own. So that's a big one. I said find a good manager. I'll just say that again. A manager can make or break your career and your life and your happiness.
A good manager that trusts you and gives you some rope is super valuable. Learn how to collaborate with people just. 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 with that, but, it's something's, it's a work in progress. Those would be big things.
Ryan: Thanks so much, Carey, 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.
Carey: It was my pleasure.
Share this post