Check out the conversation on Apple, Spotify and YouTube.
Intro (0:00)
Aakash: Everyone has interview advice. Almost none of it comes from someone who has sat on the other side of the hiring table. Gal Eshel was a PM at Google for six years and most recently was a principal product manager at Microsoft. What is Googleyness actually, and what are the stories interviewers are looking for?
Googleyness. It’s one of the most elusive words in the job search. Just about everyone wants to land a job at Google, but everyone’s kind of at a loss to explain what Googleyness is. That’s why I’m really excited to have Gal Eshel on. Not only was he a PM at Google for six years and sat on the hiring committees to see whether they should hire people and whether they were Googley enough, but he’s been a PM at Microsoft, at Melio, and now he actually coaches people, which gives him a level of insight that the average Google PM wouldn’t have, which is how do you actually take people from not scoring well in Googleyness to scoring well.
The first half of this video will be for anybody who’s interviewing for any role at Google. The second half will be specific to PM and AI PM. If you stay till the end, we will break down what Gal has been seeing in his coaching experience is the latest Google PM interview loop so that you can actually prepare for what you can expect in 2026, not outdated advice from a long time ago.
Gal, welcome to the podcast.
Gal: Hi Aakash, excited to be here.
Why storytelling decides the offer (3:26)
Aakash: Gal, one of the things that really stuck with me in our prep call was when you were talking about this book, The Storytelling Animal, and how more than memorizing different facts or frameworks, people being able to execute on storytelling is one of the keys to Googleyness. Can you break this down for us?
Gal: Yeah, okay, now this is something that I really stress when working with candidates. Candidates many times come with the idea that their interviewer is a really smart person, which usually is correct, but they also come with the idea that their interviewer kind of knows everything. And it’s enough to just dump a lot of facts and they will connect the dots together.
This is not true because no interviewer knows everything and they need you to connect the dots and actually tell the story. Now, if you don’t do it for them, they will do it, and not necessarily in the way that you want them to do it. Because this is what you mentioned regarding this storytelling animal, this is actually a theory that I really like to refer to. It was coined in the early 80s by a communication theorist called Walter Fisher.
Now what Fisher said is, we all know about homo sapiens. Homo sapiens is the wise man, the wise human. We are homo sapiens. But what Fisher said in the 1980s is that after evolving and after learning to speak and tell stories, we have evolved into something different. We are no longer homo sapiens. We are now homo narrans. Homo narrans is the narrative human, the storytelling animal. This later became more popular in a book in the early 2000s.
So basically we are a storytelling animal. What that means is we can’t really have random pieces of data held in our mind. The moment we see facts, we try to turn them automatically, in an instant, into a story.
As an example, I come to my kitchen, I see the refrigerator door open, I see a milk carton spilled on the floor, and I see my cat sitting happily in the sun. These are three facts. But I, as you most probably did, have a complete story now in my mind. I know exactly what happened. I know the timeline. This is not necessarily what happened. Maybe some other thing happened, but I always create a story.
Now, we don’t want the interviewer to create some kind of story out of random facts that we tell them. Let me give an example. The interviewer asks me to tell about myself. So I tell them I’m a computer science major. I finished third in class. I worked a bit as an engineer. Then I started working as a backend PM in a small cloud company, very edge heavy, very backend. I moved to Microsoft Azure and continued working in cloud with backend teams. Then I transferred to a more user facing role. I did that for a few years, and now I’m in this new company again, doing a user facing role.
Now, connecting these facts that I said together, I can imagine a few different stories. Someone who really loved computer science and somehow went with the flow to become a front end PM, a user facing PM, instead of what they love. I can imagine many different stories. But let me tell this same story in a different way.
While I started as a computer science major, I always was fascinated by how people perceive things, how users use products. So immediately after graduating, I worked a bit as an engineer, but immediately moved to a PM role. I was still at a backend role, but still was fascinated by how every action that I do influences end users. Eventually at Microsoft Azure, I got the first chance that I was really looking for, to work with an actual user facing role. Then in my last role, this is what I’m doing full time, and this is really where I was always aiming.
See, I added a story. I colored the exact same facts and turned it into a story that tells a lot about me, my passions, where I’m aiming my career, what drives me. This is really important, to turn the facts into a story.
Aakash: So if you just give people facts or data, they’re going to write the story themselves.
Gal: Yes.
Aakash: Can you walk this through for us, maybe the same situation, two stories, two different candidates, how this would look?
Gal: Yeah, okay, let me give an example. It’s not a career example, it’s a real life example. Maybe I’m being asked, tell me about something interesting that happened in the last week, something that you’re proud of.
I have this neighbor. Yesterday, I was coming to the drive-in, I saw the neighbor pulling 18 bags of groceries out of their car. Now, that neighbor lives in a four story apartment, and yesterday the elevator in our building was not working. What I immediately realized I want to do is offer my help, because we needed to go many times up and down. After the first trip, I realized this was going to take a long time. I saw another neighbor, a teenager, and asked them to join. So the three of us did it together, and it was a lot of work. We went four times up and down eventually, and we finished, and the neighbor was really happy.
Let’s summarize what I told here. I talked about 18 bags. I talked about a broken elevator. I described four or five trips up and down, which is a lot of work. I also told how I recruited a neighbor. Now, an interviewer listening to this story, what would they learn about me? They would learn that I’m good at heavy lifting, I’m not afraid to do hard work. Also, I’m good at project management, I realized we don’t have enough people, I recruited the neighbor. Interesting.
Now let me tell it in another way. The exact same story, but I’m pointing out two different things. Yesterday, as I was coming back home, I saw my neighbor who lives on the fourth floor pulling out 18 bags of groceries. Now, this neighbor is an 83 year old elderly widower. I know him for over a decade. His wife passed away 20 years ago. He’s very independent, he does everything alone, but still he’s 83 years old. So I immediately thought he might need some help. I politely offered to help him because I didn’t want to imply he can’t do it himself. He was actually very happy. I took most of the bags myself, because what to do, I’m a bit stronger. I also asked another neighbor, a teenager, to join. We did most of the lifting ourselves, and he was really thankful.
Now, what do you learn about me from this story? You learn that I’m a people’s person, I’m empathetic. Maybe a few other things. But you see, it’s the exact same facts. I just chose which facts to highlight and with which color to color my story. And we’ll talk a bit more about how to color the story in Google colors.
Aakash: What is the interviewer’s brain doing differently in story A versus story B?
Gal: They take the facts and build a story about who I am. In the first story, they build a story about someone who gets things done, someone who’s not afraid to take responsibility. In the second story, you have someone who can work in a team, someone who is a collaborator, someone who sees other people and takes note not to offend someone, although they are actually doing the work for them. So they build a completely different view of who I am.
Now, this is important. When you’re being asked these behavioral questions, you always say, let me take a minute to think, and dozens of stories start running in your head. So before choosing a story, it is important to take the interviewer’s question and break down what is the theme of this question, what are they trying to learn about me. What I suggest, maybe we can do a more career style demo of how this works.
Aakash: Yeah, I would love to. What if we took, tell me about a time you had a conflict with a coworker.
Gal: Okay, that’s the classic, maybe the most classic behavioral question. I’ll give a hypothetical example. I didn’t really work at Gmail, but I’ll give a Gmail example because everybody knows Gmail.
Let me tell you about a time that I was a PM in the Gmail core team and how I managed to push our team to deliver features which landed really well with our customers. We’re working on Q1 planning. We just recently launched an AI auto reply feature, and user reviews on the feature were mixed. I was already working for a few weeks with our tech lead on ideas for significantly improving that feature, and I wanted that to be the main focus for the team in the coming quarter. However, when I presented these ideas to the engineering manager, he strongly pushed back. He mentioned that over the past quarter, the rate of failed messages has been increasing steadily, and we said we would be working on it. Failed messages means an email is being sent, and for some reason it doesn’t reach the destination, and we do retries, which can delay the message for many minutes, sometimes up to an hour.
Now, we both had the same goal of improving user satisfaction in the coming quarter, we just came from different perspectives. I was really eager to launch these new AI features that users were eager to have. So what I did, I brought data showing that less than 2% of users have been affected by the failed messages issue in any given month. I also brought data that showed nearly 60% of our users have tried automatic AI replies at least once in the past month, and less than 50% of them said they would recommend it to someone. So we had a user satisfaction issue.
I looked at this data, and it seemed clear to me, but I didn’t stop there. I suggested that we both go to the VP and present both options fairly. This is what we actually did. The VP was convinced with my data, and we ended up launching the new features for automatic AI responses. Within 60 days of launch, we increased user satisfaction by 23%. But I also placed fixing the engineering issue as a P0 for the next quarter.
Now, what I learned is that convincing with data almost always works, but what worked really well was also paying attention to what the engineering manager came up with, and putting it as P0 for the next quarter, and making things work smoothly.
Okay, this was story number one. Intentionally, I didn’t do a really bad answer. It was an okay answer, above average. It was a good answer.
Aakash: Yeah, it was a good answer.
Gal: It was a good answer. I convinced the engineering manager with data, I took care of everything. But we will soon be talking about Googleyness, and let me demonstrate another way to answer this question.
Again, story about my hypothetical time as a PM in the Gmail core team. Let me tell you about a time when we were incorporating an experimental feature of an AI sorted inbox. Instead of showing you the mail as it came, we have an AI algorithm that shows which emails we will care most about. Solving the inbox problem might be considered one of the highest priority tasks for the Gmail team. So we knew we were going to put AI to this, and we came up with the sorting recommendation idea.
Now, the question was, are we going to build the feature completely in our team, which was the direction I wanted to go, versus using one of the many recommendation algorithms within Google, since the search team and maps team do this a lot. We could reuse a lot of knowledge from other teams. Now, for me, this would create a dependency I didn’t like, because I want to run fast. I thought the problem space we were discussing was really different, because they deal with endless data, whereas we deal with a few dozen, maybe a few hundred emails. These are very small numbers, and we can go through 100% of the data. It’s a completely different problem.
So this is what I presented, and I worked with our tech lead on this direction. What happened is that our engineering manager pushed back. He said this would take us three to four quarters to launch, whereas using other teams’ modules, we could launch within the coming quarter, with some limitations. He showed the numbers, the engineers needed, the time to launch.
I was still skeptical, so I pushed and said, let’s do a quick POC. What he did, he took one engineer, and in two days showed surprising results with a quick and dirty solution, and surprisingly not bad results. There I had to pause for a second, and I said, okay, I think he convinced me, I think his direction would get us to what we want much quicker.
What happened eventually is that we did launch using other models, and we added tooling so we would be able to swap in the future quickly. To cut a long story short, it was live for a few months, and two things became clear. The feature had very little traction, users kept turning it off, they didn’t love it for various reasons. And during these months, we came up with a totally different inbox solution, which was much better and ended up getting a lot of love from users.
What I learned here is that it’s many times important to not find the perfect solution. Two, really be open to your engineering manager, opening to different perspectives. This is something that is difficult for all of us, it was difficult for me here, I did push back a lot, but it was really worth it. It saved us a lot of time and got us much quicker to a better solution.
Aakash: So which one of these wins at Google, and what’s the difference between the two stories we just heard?
Gal: Let’s talk about the first one. We’re talking about auto reply new features versus missed messages. First one, really loved by users. Second one, less common. I brought all this data, escalated elegantly, I might say, because we did go together. Escalated elegantly, and the most important thing, managed to convince with data. Bottom line, I won, users won. Seems like a great victory story.
Aakash: Yeah.
Gal: Story two. We’re talking about AI inbox sorting, in-house versus external modules. The manager brought data. I asked for an experiment, asked for a POC, I was convinced, I really listened. Everybody won, users won.
So I think these are the main differences. And when we talk about Googleyness, we’ll see that the second one is much more Googley. Now, I can’t say for sure that in 100% of companies story B would be better. In Google, it would most probably be better. There are more than 100,000 Googlers, I can’t promise 100% of them would prefer story B, but most of the ones I know would definitely prefer story B, because it shows how you actually work collaboratively, how you listen to people, how you have intellectual humility, how you put your ego aside.
Now, an important thing to remember is that in this interview, I don’t want to see that you’re a really professional PM who knows how to work with data, how to work cross functionally. These things happen in other interviews. In this interview, I assume that you did well on the others. Here I want to see who you are, I want to see that you are a person I want to work with, who knows how to work with people. It’s important to understand what is being asked, what is the title of this interview.
What Googleyness actually is (26:04)
Aakash: Googleyness is a word that’s thrown around constantly, and I feel like there has been no real definition. Can you define it for us? How do we actually show that Googleyness?
Gal: Okay, now that’s a great question that’s being asked a lot. Googleyness is a term that has been around almost ever since Google has been around. Googleyness is a real thing, and is one of the really important reasons that people love working at Google. I can give an example. I landed in London to start working with a team in which I hardly knew anyone, we had a few email exchanges. Now, the moment you step into the room, everybody is listening, and everybody is assuming the other one has good intentions and knows what they’re talking about.
Another important thing that happens, if we come with conflicting ideas, I gave an example of an escalation, but escalations very rarely happen at Google. 99% of the meetings at Google end with a consensus. Now, this might seem surprising for people working at more competitive companies, but this can actually happen, and one of the important reasons that makes it possible is Googleyness, that everybody is Googley, and Google chooses Googley people, and they act in a Googley way.
Now, the official term, I think the first time it was defined officially, is back in 2015. Laszlo Bock was back then head of people operations at Google, and he wrote a book called Work Rules. There he mentioned a few things. The first one is intellectual humility. So when we talk about Googleyness, when I ask you a behavioral question, I don’t want to hear how smart you are, I don’t want to hear about the data you brought. I want to hear that you’re confident, you know what you’re talking about, but you never brag, and you never put down other people. You always come with humility to each task and each situation.
Another one is being comfortable with ambiguity. Not immediately jumping to the solution, taking time, maybe listening to other opinions, maybe running a quick proof of concept, a small experiment, and being able to stay in the state of not knowing for a long while, waiting for the data to emerge. You need to strive to find the best solution, not necessarily as soon as possible.
Collaborative spirit, this is another one. This really happens at Google, everybody works together towards joint goals.
Conscientiousness. Taking ownership of your work, maintaining high ethical standards, challenging the status quo but doing it constructively, always being guided by your conscience. In a way, Googleyness is a lot about just being a good person, doing the right thing. Google’s tagline for most of history was “do no evil.” So it’s a lot about that, and in a different perspective, it’s about approaching with integrity, and being respectful both to your coworkers and your users.
It’s saying nothing, but it’s not saying nothing, because many times we know what the right thing is, and we have many reasons not to do the right thing, we do the second best. So Googleyness is always being willing to pay the price for doing the right thing, because it is a core value.
Now, it’s really important, when you choose your stories, you don’t need to choose a Googley story specifically. The facts of what happened to you are fixed, the meaning is not. So as I demonstrated in the first story, you can paint the same story with different colors. In screenwriting, they talk about plot versus theme. The things that happen are the plot. As an interviewer, I am interested in the plot, but I’m interested in the theme not less than I’m interested in the plot, because you can choose many stories. Everybody in their career had good moments, bad moments, different things happened.
The theme of the story that you choose is really important, because it tells me a thing about you. Which theme are you choosing, which are the values important to you. In the example with my neighbor, if I choose to tell about how hard I work, this is one Gal. If I choose to tell about my heart going out to this 83 year old widower, this is another Gal. And choosing means, in a way, which of these is more important to me. This is why I say the theme is in a way more important than the plot.
Aakash: So if you’re not choosing Googley stories, you have a Google loop coming up, how exactly are you preparing to succeed on the Googleyness dimension?
Gal: Okay, first of all, it’s important to try and understand as much as you can what Googleyness is. A recommendation I usually give is prepare 8, 10, or 12 stories in advance. These have to be good stories, in which meaningful things happened during your career. The number of behavioral questions is endless, but the important thing to understand is, if you have 10 interesting stories from your career, they would most probably cover 95% of the possible behavioral questions.
While you practice, after you have these 8 to 12 stories, think about many different behavioral questions, and in your head, quickly try to think, how do I color this story in Googley colors to match this question?
Aakash: What’s the single most common mistake people make when they’re trying to demonstrate Googleyness?
Gal: That’s a good question. The most common pitfall is overfitting, and not being 100% honest, trying to really fit the story to what you think Googleyness is. It’s really important to do all these things while being honest. Do not invent a story, because it shows. You can choose any story, there are so many perspectives and so many ways to tell it, and there are so many stories in every career. You don’t need to invent anything. Be really honest. And if it’s a story about ambiguity, you don’t need to exaggerate how ambiguous the situation was. Don’t exaggerate, be honest. Because the five traits I mentioned are just an example, there are many traits, honesty is one of them. Many of them are about being a good person, and wherever you feel that you’re not doing the right thing and not being honest, you’re not being Googley.
Aakash: That’s a great point. So if Googleyness is actually testing for being a good person, let’s make sure we’re using those same high ethical standards in terms of choosing the story and representing ourselves. Now the final question I want to ask about Googleyness is, what’s the right way to prepare? Is it I go read Laszlo Bock’s book, Work Rules, I go read The Storytelling Animal, and I rewatch this video five times? Or is it I go practice and record myself, or interview myself with ChatGPT? What’s the right study practice plan to ace the Googleyness dimension?
Gal: Okay, technically, you need to practice these stories and see how you come out as Googley from them. But I think another really important thing to do, this is more on the soft side of preparation, is spend some time and write down what really is important for you as a person, what is really important for you as a product manager or engineering manager. Honestly ask yourself, do you really believe in what Google believes? Now, I’m not saying that if the answer is you feel better in a more competitive place, then drop the interview. But being honest and understanding how Googley you really are, and what the gaps are that you honestly have.
You might have been working at a company you’re not really proud of, that was not doing the right thing, that was using dark UX patterns. This is something you did in your career, and it’s obviously not very Googley. How honestly do you feel about that? Are you really proud of it? You probably shouldn’t be really proud of that in the Google interview, but understand how you want to tell it. This is a gray area. You are proud of it, but you’re not going to be proud of it here. So really look deeply and see how Googley you really are, and if there is a gap, how do you plan to honestly bridge it.
Aakash: Really awesome. Okay guys, so we just covered end to end how you can demonstrate Googleyness. We started with the importance of storytelling, we walked through what actual Googleyness is, we showed you how to prepare. Two things we want to quickly talk to you about. Number one, if you are loving Gal’s advice as much as me, consider going to igotanoffer.com, finding his page, getting some credits, a call with him is three credits to start, and you can get his wonderful coaching. If you want to work with me on how to land a PM job and how to create your LinkedIn and your resume and your GitHub and your portfolio, you can check out my coaching and cohort at landpmjob.com. Both of us have helped people through Google processes, and now we are going to shift into the next part of this video, which is about PM and AI PM.
The 2026 Google PM interview loop (40:14)
Aakash: So the first thing I want to understand, Gal, is you coach so many people, you get to see the market in a way that other people can’t see it. You get to see what’s actually happening here in 2026. And a lot of the information about Google is probably outdated. So can you walk us through, not revealing confidential info from when you were at Google, but what are you hearing on the ground now that you’re an interview coach about the Google PM process? What does it look like today?
Gal: Okay, first of all, many things have changed in the past two or three years. The PM loop was kind of steady for many years, at least for the decade that I knew it closely. We had product sense, we had analytics, we knew exactly how the loop would look like. In the past two, maybe three years, many changes have occurred.
Now the interview loop consists of, and this is not confidential information, this is what Google sends to every candidate who starts the process, five types of interviews currently in the loop in 2026.
The first one is product vision. This is what used to be called product sense. This is the most classic product question. How would you build maps for blind people?
The second one is product analysis. This is the classic analytics question. For instance, an estimation question might be, how many messages per second does Gmail receive? Or, you notice a 30% change in the usage of your product, what would you do? Or setting goals for the product. Anything that has to do with metrics, analytics, many times experimentation.
Next, we have the strategic insights interview. If in product vision you’re meant to be an L5, L6, L7 PM and solve day to day problems, in strategic insights you are more like the CEO or an SVP, and need to take a much higher level view, the forces that move the company, the things that keep Sundar awake at night. It might be a question like, should Google offer a StubHub competitor? The most common pitfall here is starting like the CEO, and after a few minutes becoming an L5 PM and solving tactical things.
Then we have execute with judgment, kind of similar to what used to be called cross functional collaboration. Here you have to show the ability to strike a balance between details and prioritization, and how you execute and work with engineers. For instance, you’re about to launch a product, one month from launch, internal feedback shows the app is really not ready, what do you do? So here it’s about how you work with the engineering team and solve day to day problems.
The last one, which is the newest one, which kind of didn’t exist and we have the least data about, is problem space understanding. The solution can come from many different directions. You need to be able, as a PM at Google, to strike a balance between the technical and business angles for solving something. For instance, we might have a bug that’s affecting a lot of users. We might go the engineering way and fix the bug, or we might go the UX way and just have a popup explaining the feature is experimental, so you might expect bugs. So how do you resolve conflicting product requirements? Really about defining the problem space.
Now, that being said, it constantly changes, every few months we see different things. The second thing is, there are many times combinations. Yesterday I worked with a candidate who had a hiring manager interview, and the recruiter told him it would be on product vision and problem space understanding, but also expect a lot of behavioral questions. So basically it was going to be about almost anything except product analytics, maybe.
So yeah, many times there are combinations, and it’s really important to be prepared for each and every one of these, because majority of the time, I don’t want to say a number, but majority of the time you will have a product vision interview and it will be about product vision. But one of the nice things about working at Google is that Googlers get a lot of freedom. This applies also to interviewing. When a Googler comes to an interview, they can basically ask whatever they want, they’re not tied to any question bank.
So I did see cases where a candidate came to a product vision interview and was asked something that was 90% analytics, hardly any product vision. And the opposite, a strategic insights interview can be really short and then become a really long Googleyness interview. So although majority of the time you will get the interview you expected, it’s really important when coming to Google, be prepared for the unprepared. Don’t black out if you suddenly came to an analytics interview and you’re being asked something completely different.
Aakash: That’s wild. I had gone through the Google interview process myself back in 2014 and 2019, I believe, and they had very specific case interviews that dominated everything. There was like a product sense round, a 45 minute case, they maybe asked me one question like tell me about yourself, but then spent the whole time on the case. Are any of these rounds dedicated case interviews, or are these all kind of hybrid rounds now?
Gal: No, what you described is usually what happens in product vision and strategic insights. The common thing is to have one specific case for the whole interview. This is very common. It doesn’t mean you spend 45 minutes in a monologue answering the question, we would probably finish around 30 to 35 minutes. The interviewer might interrupt you in the middle with follow up questions, they might interrupt you and completely change course, which is something I really like to do as an interviewer. But usually we stay on one case. For instance, you are a PM in Gmail, or design Google Maps for blind people, we would stay in the same area usually for most of the interview.
Aakash: So just to confirm, product vision and strategic insights are mostly a single case. Are product analysis, execute with judgment, or problem space understanding mostly a single case, or are those more multiple topics?
Gal: They can be either. Product analysis, many times it can be a single case where we dive deeper and deeper, define a North Star metric for Waymo, we can talk about it for three weeks, it’s a really difficult question, or we can talk about it for five minutes. So it can be that, but other times it can be a really quick question. As for execute with judgment, it tends to be shorter, because there isn’t that deep to go usually in this question, so it would tend to be two, three, but again anything can happen, it can be a very long one where we go deep.
Aakash: We’re kind of describing the 80%, but there’s the 20% of wildcard cases. Is there any vibe coding or AI prototyping in the interview, because there were some reports on Reddit and Blind, but then some Google director said no, it’s a very scripted process, we don’t have that. What is the truth that you’re seeing on the ground?
Gal: Okay, from all the data I have from candidates I work with, and here I will say also with Googlers who are friends, I didn’t hear anything about vibe coding interviews. But that doesn’t mean, as I said, Google is really changing the interview process really quickly these days, it doesn’t mean it will not appear tomorrow. Right now, to the best of my knowledge, it’s not a thing. Probably out of 100,000 and something Googlers, maybe a few of them do ask about live coding, I don’t know.
Aakash: So they potentially could have the authority, because Google isn’t giving you an exact question bank, but it is definitely not part of what Google is prescribing as the route.
Gal: To the best of my knowledge, yes. I’m not a Googler anymore, but to the best of my knowledge right now, it is not.
Aakash: What about technical and estimation rounds? Historically, there’s definitely been some content written out there. I even remember an IGotAnOffer article from 10 years ago or something that talked about how Google might ask these estimation questions, or system design or technical questions to PMs. Are either of those still up in the Google interview loop in 2026?
Gal: Okay, first of all, there used to be a dedicated technical interview. When I interviewed, I was actually interviewed by a software engineer, and I was actually writing Java code in my Google technical interview. This does not happen anymore. There is no dedicated technical interview, but technical knowledge is expected in a few of these, especially in execute with judgment, because you are working with engineers, you’re expected to know how to work with engineers. If I ask you a question about a latency bug in search, I expect you to understand how search works, what the possible causes are, because if you have no technical knowledge, you can’t do anything about it. What would you do, you would call the engineers. So yeah, you’d be expected to have this technical knowledge, but it’s part of a bigger question.
Aakash: Got it. All right, so that is the interview loop, guys. Gal is as close to it as anyone in the world, because he is regularly coaching people going through it. As he said, there’s 100,000 Googlers out there, what one Googler confidently says to you, there is some latitude out there. I was just speaking with Satyajit Salgar, he’s a director of product at Google AI, and he said, yeah, we have full ability if we are hiring for a specific role to sculpt the interview process for that specific role. So things at Google are changing. When I interviewed, I think 12 years ago, it had that technical round and they even asked me an estimation question. Now technical and estimation is out as prescribed rounds, but it’s up to your interviewer, they might ask you something along those lines, they might ask you something along vibe coding and AI prototyping.
We have put the five interviews that you are most likely to see, the five topics that should cover 80 to 90% of your prep. But with Google, never just assume this is exactly how it’s going to be. As Gal said, sometimes people ask analysis questions in a vision round. So you really want to be prepared for the whole gamut.
Live coaching “tell me about yourself” (53:31)
Aakash: Now, when I coach people on Google rounds, I tend to find that they are spending 99% of their time practicing product vision, execute with judgment, these case interviews, and 99% of people actually fail because of behavioral. Those are exaggerated numbers, of course, it’s not 99% in both cases. But if people are really failing in behavioral, which is what I see, I’d love for you, Gal, to live coach me. So I’m going to do the type of “tell me about yourself” that I frequently see in people I am coaching, and then I’d love for you to take my answer to a great answer. Are you ready?
Gal: Yeah, let’s do it.
Aakash: All right, we’re going to do sort of a character version of myself.
I’m really excited to be here, Gal, at Google today. My career in product management started back in 2008 when I was working in B2B SaaS at this company called Scout Force in Ann Arbor, Michigan. From there, I spent time as a founder working on an app called Wrap to Beats for a few years, and grew it to a couple hundred thousand monthly active users. It was an iPhone app, not an Android app, but really learned a lot about mobile development. And because of that, I went from B2B to consumer and continued down the consumer journey. I worked at ThredUp, where I joined as a growth manager, but eventually became a director of growth product. I moved over then to do my MBA, and started working at Epic Games, where I started as an associate producer, but eventually was promoted into lead product manager. Then I worked at a firm where I started as a group product manager, but was eventually promoted into head of growth product on the senior leadership team. And most recently, I was VP of product at Apollo.io, which was worth $600 million when I joined, and $2.5 billion when I left, we overall 4xed, and I led pricing and packaging, core activation, acquisition, retention, my job was to really own the product led growth funnel at Apollo. And I feel like Google would just be the awesome next step for me.
Gal: Okay, that’s really interesting, Aakash. This was a good example of how you walked me through your resume. Now, I did read your resume, and I didn’t learn anything new from what you just told me.
Now, I’m wondering, for which role at Google are you interviewing right now?
Aakash: Let’s say that I’m interviewing for, within Google Brain, there’s obviously research and apps. Let’s say I’m on the apps team, like the labs, like they created Notebook LM, they created Pomelli, they created Google AI Studio, AI prototyping, those types of roles.
Gal: Okay, so you’re working on the apps team. Now, I see your relevant experience for really app development, you were in mobile development in your early career, you might want to highlight that, sow the seeds of where you started wanting to go there. Then things happened, you moved to growth product PM, I’m not sure why, then you went to an MBA. I would really want to hear why you went in that direction. And I’m wondering, this current role is actually really not business oriented at all, so this makes me think you went into the MBA direction, but now you’re going back to really hands on, being a product manager in the apps team. Is this something you really want, or as an interviewer, I’m wondering whether it’s just an opportunity that you saw and you’re jumping on it because it seems interesting.
The most important weakness that I see, you did a lot of growth, you went from your last role, which was product led growth. And I’m wondering, is this a direction you’re no longer interested in? This is kind of a weakness, that you started a direction, you really managed to grow Apollo.io, why not continue in that direction? So this is something I would really want you to highlight in your story. Now, do you want to take a second try, or do you want me to try to do it?
Aakash: Let me try to incorporate your feedback, and let’s see if I need another round, guys. And by the way, I know that’s not how I actually answer, guys, but I wanted to show you how I, here, “tell me about yourself” from most people when I ask them, they restate their resume. So what I’m currently doing in my mind is, okay, Gal came up with these weaknesses, so what I want to do is probably flip some of these weaknesses. Gal said he already knew my resume, so what I want to do is add on texture beyond my resume. Let’s see if I can do a better job of this in this next response.
Gal, thanks for having me here today. I know my resume probably seems like I’ve done a lot of product led growth, worked in B2B and B2C, so you might be asking why I’m here today. And the through line I want to actually show you throughout all my background, whether it was B2B or B2C or growth, was that I was building a lot of core AI, or before it was called AI, ML products. So all the way back in one of my first growth product roles at ThredUp, which is now a public company, I had joined when they were Series C and went through Series E, and had gone from growth manager to director of growth product. I implemented ML algorithms to influence pricing, influence what is shown on the homepage. So I was building a lot of apps on top of ML models, and some of the results we achieved were pretty mind blowing. We doubled visitor to first purchase conversion rate, and as a result of doubling that conversion rate, we managed to triple our new customers, because once that conversion rate increases, we could spend more on ads, and that led to a tripling of new customers. My CEO actually called this out when he announced the Series D, he said the work that Aakash and the growth product team did really helped enable this raise.
So that was one example of using ML to build an app on top of it. At Epic Games, most recently, we built AI characters into the product. What’s the problem with Fortnite? Well, if you try Fortnite, you can often face people who are much better than you. So the AI solved this problem of getting people to face people at their level, so they don’t suddenly just lose the game and quit. It was a crazy launch as well, we managed to increase day 30 retention, which was our North Star metric at the time, on a relative basis, 50%. I can’t share the exact amount we went from X to Y, but we grew day 30 retention 50%, which was a game changer for the game.
And most recently, at Apollo.io, where I rose all the way to VP of product, we shipped an AI email writer, which was built on top of models like Gemini, and it helped people send cold outreach, because this was a tool for salespeople, and we were able to increase the amount of emails people were sending, the open rates, and the reply rates. So building all these AI apps throughout my career, I feel like what I want to do is this new trend in PM, away from managerial, middle management, into a senior IC role building AI apps.
How did I do?
Gal: That was much better. I would shorten it a bit, you went a bit too deep, specifically in Epic Games it was a bit too much information. All of them could have been shortened, really just highlighting in a sentence or two and keeping the theme of the ML algorithms you developed in each of these. That would make it almost there.
But another thing I usually look for, and I usually ask follow up questions if I don’t get it, is your personal passion. I see that you’re really about ML algorithms, I understand this is what you did, but I’m not sure why, why do you love it? And just adding, in the beginning or the end, depends how you like to tell the story, just a few sentences about why this specific problem really keeps you awake at night, why at 3am you suddenly come up with an idea for an ML algorithm to solve the Epic Games problem. Just really 20 to 30 seconds on this, on your personal passion. This really makes the difference for me, and I know for a few other interviewers.
Aakash: There you go, guys. So I probably started at like a three, it seems like I took it to like an eight, but there’s still room to go even further by shortening it, and by showing personal passion. Is that right?
Gal: Yeah, eight, maybe even nine. It was a really good answer, way to go, Aakash. You could have shortened it mostly, but that passion, I think, really, if you want to be a 10 out of 10, you need, in my opinion, to have that really personal touch, which never really comes up in the resume. I need to hear and feel why you really love doing what you do.
Aakash: There you guys go. So a great “tell me about yourself” is beyond the resume, it’s addressing weaknesses, and it’s showing passion. So pause the video now, try to iterate the same way we just did. If you want, throw the transcript of this video into an AI, and throw your recording of your “tell me about yourself,” and say, how would Gal improve it? Or you can book time with Gal or I, and we’ll help you with it.
How AI PM interviews differ (1:04:07)
Aakash: Now, Gal, I want to talk about AI PM roles. Based on what you’ve been doing coaching different people, how is Google looking for AI PMs? What are the things they’re looking at? Is the process different? Is the bar different for behavioral questions? Basically, what should people who are preparing for Google AI PM roles know?
Gal: First of all, an important thing to mention is that Google has only just recently started interviewing people for specific roles, and this is part of the reason. Until not very long ago, maybe two, three years ago, you would interview as a generalist, to become a Google PM or a Google engineer, and only then you would have the team matching process. Now, the vast majority of candidates actually start their interview round with a hiring manager interview. This means two things. One, you’re already assigned a team, you will not have the team matching process as before, it might happen, but not necessarily. But the more important thing is, since you’re already assigned to a team, you’re expected to have knowledge in that area. So if you’re assigned to an AI team, you are expected to have knowledge in AI.
Now, what are the differences? Let’s start by talking about the role itself. For a classic PM, I think the clearest difference is the classic PM would have a deterministic way to solve things, and an AI PM would have a probabilistic way of solving things. We never know exactly how the AI would solve the problem.
Next, what is the definition of done? Here, done means meets the spec, we did everything that’s written in the spec, it is done. But what does that mean in AI? In AI, I would say done is something along meets certain levels of accuracy and failure rates. So it’s actually ongoing, and even if it was done, it can become in a way undone. So you never really leave your product, which is something different.
Another thing, how do we even define the product? We used to know a product is defined by a product requirements document, the classic PRD that we all know and love. But now it’s more, we define the outcomes, we define guardrails, it’s not a classic PRD.
Next, how do we work with data? Data is a PM’s best friend, but data used to be mostly for analytics, understanding how your product performs. But now data is a super important part of the product itself, for the learning algorithm, data is crucial. So data becomes something very different, you need a deeper understanding of data.
A really important thing here, you had certainty, you would sit with your engineering manager and break down a project, and you would have certainty in execution, you would know it would take three months, but then it would take six months. Here, you have a much higher level of uncertainty, because you can never predict how the model will perform, you can never predict how many iterations will be needed. Maybe AI PMs 30 years from now will already know all these things, but for now the uncertainty is much higher.
Another thing is failure. Failure used to be predicted, we would write in PRDs what we do in certain modes of failure, and we would already offer solutions. Here, we can always be really surprised by the model, so risk and trust become much more important.
So all that being said, how does that map into a behavioral interview, because this is what we’re talking about, Googleyness. I think all the things we mentioned are most closely related, first of all, to being comfortable with ambiguity. This is something I would really look for in a candidate, number one, that they can accept ambiguity, that they can change course if nothing works. Ambiguity is the number one thing to stress in the Googleyness list.
The next thing I would mention is intellectual humility, because when you switch from being a classic PM to an AI PM, you need to let go, because you don’t control every single detail, you are working with an unpredictable collaborator, and you need to be humble, because that collaborator is really smart and really fast, and can learn and iterate, and can do a lot of things you will never be able to do. So intellectual humility in front of that collaborator is really important. You don’t have the control you were used to having as a classic PM.
Aakash: What are the most common failure patterns when you’re coaching people for these AI PM roles?
Gal: Well, actually, many of them, in the “tell me about yourself,” don’t have a good story like you had, a very good story about why you’re a good fit. Many times people miss it, and they don’t realize that they have actually been working with ML related work, because if you’ve been working in the past few years, then most probably your engineers were working with ML algorithms. You didn’t directly work with ML algorithms, but you did have some relation to them. And understanding, if you’re interviewing for an AI role, looking back and understanding where you actually did, in a way, work with AI, is really important, and this is something candidates many times omit, while they could really easily do it.
Aakash: And what if you feel like you really don’t have AI or ML experience? How do you interview for these AI PM roles?
Gal: Don’t pretend. This is a general rule, never pretend, never try to hide your weaknesses. This is also true in product vision questions, analytical questions, many times candidates realize they made a mistake, they forgot something, and they try to hide it. I tell them, you are in the spotlight now, the interviewer sees you trying to hide something, you cannot really do that. So instead of trying to hide it, say it out front. The moment you sit down, in the first three minutes, say, actually I don’t really have deep AI background, but, and then the “but” can be many things, I really love this, I’m really interested in this, in my free time I do a lot of AI stuff, whatever is the right answer for you, but don’t hide it, don’t try to tweak the story. Just say it out loud, I don’t have official background as an AI PM, I’m really passionate about it, I’m really interested in it, I really learned about it. Be honest about it. Again, honesty is really important in these interviews.
Aakash: Amazing, Gal. If I were to take away three things, guys, from the overall talk we just had today, number one, tell a story, or the interviewer will build a story for you. Number two, Googleyness is fundamentally about doing the right thing and being a good person, so hold that same standard for your story selection and your answers. And then number three, don’t make your behavioral answers too long, don’t just restate your resume, but actually tell the story to help people see your passion and see why you are a fit for the role. Is there anything else you’d add, Gal?
Gal: Not exactly add, but I want to finish again with what I started, the story. Remember that you’re always telling a story, and you’re coloring it with very specific colors. So before starting the story, understand the question, which colors is it looking for, and understand how to color your story with those exact colors. And then the job of your interviewer, to pass you, would be really easy. They just need to fill in all the rubrics, because you prepared everything for them, and that’s it, you’re good to go.
Aakash: All right, guys, he just dropped so much alpha. Go support him. If people want to find you online, where can they find you?
Gal: IGotAnOffer.com.
Aakash: All right, guys, find him there, and we’ll see you in the next episode. Bye.