00:00

So this week on trying to product we're going to talk about some of our interview experiences. And some of the things that we've observed as product managers going through interview isn't actually doing interviews ourselves. So far, what has been some of your interview experiences as a PM? Yeah. When I think about pm interviews, I feel I've gone through so many varieties of

pm interviews, I've had ones which were very, very unstructured, depending on my resume, and depending on some previous qualifications, and then I've also had interviews which have been very structured in nature, we have a specific set of questions, and go through each one of them, making sure that ticked all the boxes. And I feel like I've gone through both of those types of interviews, and I can talk about my experiences as well. But I want to know, have you faced the same thing as well of like both? Or have you seen one more than the other? Oh, yeah, I think some companies clearly know how to interview for product managers, and some don't really quite get it as much. When I think about my experience, I think I've had things I've enjoyed the most have been the ones which were slightly unstructured. Just because I think it was easier, not easier. But it was better for me to actually, like, bring out a bit more in terms of like how I've handled problems in the past, or how they handled situations in the past as a PM. And I think sometimes that ends up being useful in terms of sharing with the hiring team, because instead of just trying to answer a very specific question, which you could prepare for, I think these types of interviews have been more of a good conversation and actually digging deeper into my pm style, my pm skill sets, and both technical and soft skills. I always prefer the unstructured, I think it feels less like you're kind of almost on an assembly line, so to speak. Essentially, if you imagine a lot of these bigger companies are essentially just kind of asking the same questions to the same people or if you wanted people, and then kind of sending them on their way. Whereas like unstructured is, it's just like, yeah, he said, it's just a conversation, it feels like a lot lower pressure, you get to learn a lot more about the company itself about what they're kind of thinking about and how they're thinking about products and their future roadmap. So yeah, I feel like I get a lot more out of it, as opposed to just kind of just like me spending three hours and not really getting anything back. Something like yeah, I spent three hours I had a good conversation and was able to learn something, even if it doesn't go forward doesn't feel like a total waste as much. Yeah, no, that's actually a great point. I feel like those type of interviews that I've done have been both like me sharing my ideas and my thoughts, but then also learning from the respective people on the other side of how they handled that kind of situation and how they've been thinking about that problem. And as he had that conversation, we start thinking about how we could have approached it differently. They share some of their ideas and their thoughts on how they will ever post a situation. So I think you're

right, even if it doesn't go anywhere you come out of those conversations really learning much more than I think in a structured interview, or when they have a specific set of questions. I do see the benefit of that from a hiring perspective. Also, how that kind of structured set of questions can remove some biases can help sort of find the right candidate based on hard concrete questions and sort of understanding of the have the base skill sets to answer them or not, and actually tackle those issues. So I see the benefit there, too. But yeah, I guess both of us are kind of on the unstructured side, both as both giving that type of interview. And then I think also conducting that type of interview. Oh, yeah. Because like, it's always a give and take when you're in structure. When you stay in those questions, we stay within that time limit, you don't get to really learn about the candidate or the as a person interviewing you don't really get to learn about the company. So it's definitely really nice. But yeah, I totally agree from a hiring standpoint, it's, it's tough to standardize, it's tough to eliminate bias doesn't really make sense for these bigger companies. How's your Pm interview experience been so far? Like? Do you have like a favorite interview question or like a favorite interview that you had so far? I've definitely done my fair share of interviews. I think it's kind of a muscle that you have to work, I think, as we always say, putting in those reps. So yeah, I'd say like, I've done a lot of interviews, most of them have been the unstructured variety, just because I mostly was working in and applying to startups. So startups don't typically have structured interviews really even know how to ask a PM. Right questions. In terms of like, the questions that I like the best. It's mostly, I really liked when the company will talk about something that's not specific to them. So I think a lot of company has always tried to ask you their problems that they've been thinking about and they've been struggling with, and they're trying to seek an answer. I always liked when the company will go beyond think about what this industry might be in 10 years, and how that industry would react in 10 years. So I think one of my favorite questions was, like, autonomous car company I was interviewing at, and they asked how I would think about breaking into and creating a flying car company. So it was like maybe their company in 10 years, but it's like such a pie in the sky thing that there's no like limitations, which is really nice. Like when you have something in the short term. I think there's a lot of limitations you artificially put on yourself. But when it's something that's so in the future, I love like kind of the unconstrained brainstorming that can happen and that's such a

05:00

Good question though, alright, because it gives the candidate an opportunity to go wild. But then as a PM, you're almost always in that situation where you can go wild. And it's an ambiguous situation and undefined problem. But you have to like take that and then try and find more doable solution are something that you can actually tackle and create deliverable steps within that bigger picture or that bigger problem. And I think so with this type of interview question A, you can give the candidate the chance to go crazy, think about more stuff. But then you're also trying to assess the skills of how does he take that big problem? And break it down into more achievable steps? And how can you actually create a strategy that gets them slowly moving towards that direction? It's a great way to assess the candidate while also Yeah, exactly like seeing how, yeah, I didn't have fun letting them think about things in unconstrained manner. Like you said, as PMS, we really can do just about anything, if you want to make it a flying car company, you probably could today, but we put so much baggage on ourselves from all of our assumptions that we often don't take the time to kind of peel these away. But when you go so far, in the future, when you do something so crazy. There are no assumptions because you don't know anything. Yeah. What's your favorites? Oh, I have questions that I always think about when I go back to my pm experience. And it's weird, they aren't really pm questions like the traditional product management questions. But I don't know like for me, they

all lead to good conversations in me getting to know the team and the people on the other side. One of them was distracting from my, during my internship, when I was trying to apply for a pm position as an intern, I actually got asked the question of it was around my resume. And it was not the content of my resume. But it was the design of my resume. I was asked, like, how did I come up with the structure and design for my resume? If you have a uniquely designed resume? Or was it just like a word, template, it wasn't a Word template, I was in school, and I was trying to apply and I wanted to stand out so and put some a little bit of flair. In the resume, like a little bit of color, a little bit of structured wasn't a traditional Word document that you might see it had like a grid structure, it was a two column resume. So and it had a little bit of color and little bit of different sort of elements to it. And my hiring manager at that time was like, Okay, I saw your resume. And I just wanted to ask you like, why did you design it like this? And what was your intent behind the design and like, we started talking about the resume, from a visual perspective. And I think that just led to such a good conversation around like design and usability, which was just such a good conversation to have on an interview. And still, you can assess and judge so much about how someone thinks about a product, that resume was a product of mine. And the question was like, Why did I design that product in that way? I love that question. And I really had a fun time answering that one. Wow. Yeah, I never really thought about but yeah, the resume and how people read it, help people scan it, especially because I think that puts it sounds like seven seconds per resume. So you really have to make an impact quickly. So that's a great question and a deeper way to learn about somebody. The other question that stands out, which I was caught asked recently was, as a PM, how do I get into flow? was just such a fascinating question. Because as a PM, you're always context switching. And you're always going from like, maybe one meeting to another trying to like go from one project to another one space from another, like moving from engineering to design and moving back to like, the legal side of stuff moving to the marketing piece, and you're going between so many different spaces throughout your day. And it was such a good questions like, with all that happening, how do you find yourself in a flow state as a PM? And I was like, taken aback? I'm like, that's such a interesting question. I've never thought about how I get into flow as a PM. But when I thought about it, I do have my ways of trying to achieve that flow state and and it's even harder as a pm to achieve that flow state. And I think that's why there's that slight brilliance of this question is that, can this candidate cope with all the different like juggle all the different things that are happening, but then also be able to get into a mode where he needs to, or they need to deliver on a certain thing? I actually was asked like a similar question, but instead of how to get in the flow is what puts you into the flow state, or just kind of

09:27

Yeah, well, I guess like one is focusing on like, are you able to discipline yourself in order to focus and get the work done and others like, what do you like doing? But it's interesting, I wonder if they were reading the same product interview blog post? It's such a good question. And again, these are all parts of unstructured interviews that don't necessarily get asked within a bigger companies set of interview questions. And they come up more in like these organizations or companies that are following their own sort of trends in terms of hiring a pm they have an understanding of

10:00

of who they want or what type of pm they're looking for. And they really cater and sort of

create those questions, or that interview sessions around that trying to understand and get the right candidate. So yeah, I mean, these were like super fun questions. And like, I still think about them now. And I think that's the nice part about some of these interviews is will ask profound questions that you could come back to think about, I still think about, like flying cars. I was like, oh, like, yeah, that industry that every year, we get a little bit closer to that being a reality.

10:29

I remember another question. I think it was. I'm trying to think it was like my first interview pm interview. I think that was a couple of years ago. And I was asked,

10:39

What's your favorite product? And I had spent time talking about a fitness app. And at that time, now that think about it, I feel like fitness wasn't such a big thing. And I felt like all the answers that I was giving. And the way I was thinking about that problem didn't really resonate with the interviewer. Because didn't really think of fitness as such a big thing or a problem worth solving at that time. And I look back to that interview and that question, and I think about it right now. And I'm like, Well, isn't that like one of the biggest things that you're trying to solve right now? That's like the biggest driver for so many of these big companies products these days? That's, you're right. In the end. Yeah. But I didn't get the job, though. So well, they were wrong. It's not that you weren't right. They weren't right for you. Yeah, it wasn't right for them. That's always what you tell yourself. But I mean, what do you think about just interviews in general, when you think about structured versus unstructured, I feel like, as someone who is preparing for a pm interview, there's so many different things that you can focus on so many different aspects of the pm interview process that you need to sort of brush up on and prepare for. And I think it'd be nice to just talk about what those different types of questions are type of interviews are, and hopefully give a sense of like, what are some of the different things that we should be focusing on when we're preparing for our interviews? I know, we used to talk about this a lot when we were preparing for our interviews, just looking at the different type of questions, a different type of structure that we see out there. And making sure that we're preparing well, it is a muscle and sometimes preparation is key. Yeah, absolutely. I think, yeah, there's so many questions out there. And I think also, when you have especially bigger companies with their structured interviews, they'll typically give you a very clear understanding of what those steps are, what the questions that they're asking are, essentially give you the whole test, and just hope that you study and that you can pass it because they want you to pass. So it's just kind of nice. I think the unstructured is more fun. But also like one experience with a lot of startups is that you don't just do like three interviews, like a structured interview is like these bigger companies, they'll do maybe like six, I believe, six interviews, and then they'll make a decision. But these unstructured ones are essentially startups, it could be I think I did 13 interviews at one startup, because they don't have a structure. They don't really know what they're doing. They have the initial thing where they have the screener with like maybe the hiring manager or hiring manager like she, they go to the next person. Next person likes you. Okay, great. Now they do a super day with their whole team design, engineering. Everybody, everyone likes it. Great. Now you talk to the VP. But nobody really had any question like meaningful question like, what's the engineer going to ask you? Are they not really better you they're kind of more doing cultural fit. So I think he's kind of behavioral questions that are a

little bit more wishy washy that a lot of startups ended up doing. With the unstructured side. Like there's kind of the pros and cons of those unstructured behavioral questions where the person just like, doesn't really know what to ask you doesn't really think they're part of this

interview process. But is part of it just because they're part of the team? And they should they have a say in hiring. Not that they really necessarily want to be part of that hiring process. I think it's a little bit of a kind of a downside to the structured side, and especially from the candidate side of how many hours are invested in this process. Before you hear rejection? Yeah, I can see that. But I do also think that the unstructured interviews do have a component, then that's a little bit more scarier than structured interviews, because as you said, there's not necessarily a know how of like, what questions are going to get asked, when it's an unstructured interview, it could be very, very different from your previous interview, each round could be very different from the previous round. And sometimes it ends up being as he said, because of the nature of the interview, or the interviewer might not want to be there at the right time. It's just like, it's not working out. But I do think like, with startups, and with these type of organizations, which are following a more unstructured interview, they really know what they're looking for. And I think they always want to base their questions based on how the conversation is going, trying to make sure that they can get a sense of the candidate and try and see if they have the skills that they really need. I think that kind of changes the direction of the interview certain times it changes, how the rounds go, who you're talking to how you're talking to them, and all of that kind of happens based on some of those things that they're trying to fill. And so that uncertainity and that

15:00

sort of like unknowns does make it a bit more scary or a bit tougher sometimes because you don't know exactly what to prepare for. And there's really, really focus on I think your experience, right? Like, what you've done as a PM before. And I think that's where I feel that it's a very strong thing in these unstructured interviews where, you know what, okay, you can answer a question that you might have prepared for, but like, let's look at a real life example, where you might have done something as a PM, how did you do that? Or like, how did you actually use your skills or your ability as a pm to actually get something off the ground? Or did you actually solve an issue like, so sometimes those kinds of like, even though they seem wishy washy, sometimes I feel there is a sort of lower intention behind those questions that relate and to get to who we are as a pm and what our sort of work style is, and what our way of solving those problems are. Yeah, I think that's a great point, I think you're able to go so much deeper and really assess, especially when you have the right person, I think, when you have people who are bought into the process, who are bought into really making sure that this is an effective interview for both, it turns out to be a good conversation and something that often stretches you and kind of makes you look at your past experience in ways that you may not have looked at it the same previously. But coming back to structured interviews, I think that's it's not going away. It's still a big thing. We see a lot of big organizations follow very, I wouldn't say typical questions across all of them. But there is a set of questions that we see that come up often, if you're searching online, or if you're like looking at past interviews, there are a certain type of questions that are common across IT organizations. And I think it'd be nice to sort of talk about some of those type of questions that we've seen come up in the structured interviews. When I think about some of those, I think the first one that comes to mind, and I think we talked about this one as well, a while back is the product design question. Right, which is, how would you design XYZ? I think that's a very, very common question that gets asked a lot in structured interviews, and sometimes also shows up in unstructured interviews as well, because it's a really meaty question in terms of thinking about how does one look at their

domain and sort of try and build something from scratch? Yeah, I guess it's a great question to assess a raw pm and how they approach problems. I think the kind of funny thing about these structure, like these specific kind of structured interviews is that they have specific frameworks you're supposed to use, and they actually in the packets will often give you the framework they expect you to use. So product design, I think I made my own but I think there's like circles, I think is the main one, but I can ever remember the very famous one. Yeah, it's a good one. Yeah. But they have these frameworks that they kind of expect you to fall. And they're looking for how you fit your knowledge into the frameworks. So it feels essentially, like kind of preparing for structured interviews feels like kind of studying for a test. But I guess it sounds like I'm a little bit cynical. But I think my experience with these is that it was an incredibly helpful experience as a PM, just structure your thoughts in these ways so that when you approach future problems, you're using a framework, so you don't necessary have to use a framework that they use, I ended up kind of making my own. But that's the framework I use today, when I approach the same questions, because as a PM, you're still like, yes. How would you design XYZ? That's something you do every single day in your job. So I mean, yeah, I tend to be a little bit negative towards structured interviews. But I felt like preparing for these bigger companies was foundational to me as a pm today, and how I understand metrics, how I understand how to design how I understand, like, keeping the user first I mean, we always say that I think there's a lot of lip service. But when you have this framework that literally says, What's my goal? Who's going to use this? What are the problems that that user has? Then it becomes a kind of ingrained, especially after your Sony the unstructured interviews over time? Yeah, that's a great point. I completely agree. I think the way we think about those frameworks they become so part of our thinking that what happens in real life is, it's that same question you're actually dealing with, how would you design? The difference in real life is that the constraints are different? Like, you'll have to think about resourcing trade offs, you'll have to think about, let's say, budget, you'll have to think about timelines and dependencies. But the core question is always still, how would you design? So having those frameworks in mind, actually, you're really right, that is that those frameworks just help give someone that starting point. And then you start applying those constraints to see what can actually happen? Yeah, exactly. So I think there's probably design that's a big one. But what do you think on the execution side? So these other technical questions that we see? Yeah, I think execution is also a big one that I've seen. I've been asked product execution questions, I think both in structured and unstructured, sometimes mostly unstructured ones. But yeah, I think a big one, there is a hypothetical scenario about you want to deliver a product. How do you talk about trade offs? Or how would you trade off X versus Y? I think that's a very typical question that gets asked in terms of product execution. Another one is around debugging. I know you mentioned that debugging was something that you'd been asked before as well. Would love to know how that was. Oh, yeah, debugging is a, of course is a framework

20:00

for debugging, but it's actually something I just use, like last week, because essentially, there's a problem with some metric is not lining up with what it should be. And then so you have to figure out where's the problem? So is it the client side? Or is it on your side? So if it's a client side, is it a technology problem? Is it a language or like, then you go through this whole framework, but it actually turns out to be pretty irrelevant when you're trying to figure out problems, because it just has a, again, like you memorize a framework. And it becomes ingrained after dozens of interviews, using that framework and reciting it prepping, and all the mock interviews, but it ends up being something that is genuinely really useful when you come across these kind of quirky things in the data. And you have to figure out where that issue is

coming from. Yeah, that's true. There is such an art to debugging, if you like, and as a PM, it's a very common thing where you will wake up one day and something's not working, right, you're like, okay, hey, team, let's find out why this is happening. How do we get to the bottom of it? I do think it's a very, again, such a critical skill that in real life, of course, you're trying to solve this again with another layer of constraints. And so as we think about these interview questions, I'm trying to draw that parallel between that unstructured piece and structured piece where an unstructured interview, you're essentially getting asked the same question, but with the caveat of how you've done it in real life with the constraints, whereas in the structured interview, you've kind of taken away those constraints on it's a hypothetical scenario where you get to apply those frameworks, it's I feel like both of them are attacking sometimes the same root thinking, just with like a different way of approaching it. I never thought about it that way. But you're absolutely right, like I've 100% been asked, but I resolved an issue. And I don't think at that point, I knew about the debugging frameworks. But there are just like, Yeah, I've totally been asked a lot of these questions. I just didn't have the framework to frame the answer of how we approached the problem back then. But I guess in terms of metrics, I guess, what have been some of the questions you've been asked about metrics and kind of as you approach those, when I think about metrics, the question that I've been usually asked are very specific to thinking about a feature or a product and sort of coming up with the right KPIs that would want to measure the right sort of testing frameworks for ensuring that you're measuring the right metrics, and like, figuring out which variant is better than the other kind of looking at. I'm trying to think there was one question that I remember, which was very specific to I was given a product like and hypothetical product, and I was told that we are going to be solving, like we want to solve for the metric of engagement. But how do we ensure that as we push the engagement metric for one feature, it doesn't impact the metrics for another sister feature in that same product? And that was a really good question around, not just generally, understanding, what are the higher level objectives of that product? Or what are the high level metrics that are to solve with that main product versus trading off against smaller metrics associated with each single feature? So that was one question that I remember which I actually really had a fun time chatting with my interviewer about. And it was part of a structured interview, if I remember correctly, I think as PMS, were always using all this data warehousing analytics. But I think it wasn't until I started studying for these structured interviews that I started had a better appreciation of how metrics kind of are very squishy, a lot of them and how they impact each other. Like he said in that in that example. So it definitely helped me a lot and just kind of getting a better appreciation for how kind of nuanced some metrics are, and how to go a level deeper to get exactly the answer you're looking for. Yeah, and I think like in the same line, if you think about like design and execution, and like metrics and debugging, I think another question that sometimes comes up here, and there is estimation. And that's like always a scary one. I'm personally afraid of estimation questions, because I feel like I'm horrible at math. And I feel like if I'm in front of an interviewer, and I'm asking estimation question, I'm gonna be like, blank. And it's funny, because I've been asked estimation questions quite a lot. And I think in the end seem to go well, but I just internally feel that I suck at those. But I know those also come up. I wouldn't say all the times, but 5050 I think that the question I was asked was, how much dip does a doorman make? To serving the front door at a hotel in Vegas? Classic? Yes. And

24:25

that was sufficiently vague. Yeah. And then the other one I remember was it was an ecommerce company. And they asked me like, how much does this organization donate in charity each year, which was like, that was the most vague starting statement for me. But of

course, the big thing about estimation questions is that you have to ask questions, to drill down and so I remember that one as well. And I don't think that one went well. I had one where I had to estimate like, how much like if you were making a new city, how much water would that new

city? Yeah, estimation questions, I think are a little bit of a crapshoot, though because like, yes, you have to drill it

25:00

down. But like, you're expected to have base information like population sizes, I think mine had, I needed to know cost of a gigabyte. So to honor like, as a server, like that's, I mean, I ended up like dividing the cost of like a terabyte hard drive. And then just cutting in half, like some of these things is you have to be rare.

25:20

How much is a doorman get tipped, uh, you need that baseline, kind of ballpark, which like sometimes kind of, I think screens people out. Right? If you're from like, a country that doesn't do tips at all, you have no background at dips? And how would you have any way to guesstimate that? I remember answering my question. And then thinking back, I was like, oh, boy, I think I had completely missed the answer. But I think you know, the good thing about estimation questions is that sometimes it's not the actual value that they're judging you on or they're trying to evaluate. It's more about the your thinking process of how you're like, looking at assumptions, asking the right questions, coming up with the right parameters to sort of like, bring together as you estimate an answer, I think that's an important thing to highlight is that almost all of these are looking at your process, not the end result, you could have like, the craziest product idea ever. But as long as you have the right process, it's all there. So yeah, I think that's a very important thing. Because estimation questions? Yes, they're intimidating. But even if you got like a few orders of magnitude off, it shouldn't matter, as long as your process was clear. Yeah. And I'm there to attest to that. I think, yeah, it was off by, I don't know, like 10 to the power of four, or something.

26:33

And I remember the interviewer asked me like, so this is the value that you said, you really think that's how much it's going to be? And I was like, Yeah, gut check. And they're, like, 40 thing. I'm like, Yeah, you're right. Probably, I'm off by a lot. But I actually got the feedback that he was really impressed with the variables that I thought about in the process that I'd shown. So it ended up going well. But yeah, and I think like, so when we talk about structured interviews, we talked about those product design questions. We talked about specific execution questions, and then we had like the estimation, but I think when we take away these three sort of formulaic, structured pieces to these interviews, I think we're still left with two categories of questions that are still always part of a structured interview ones, I think it's always asked, which is like your favorite product. I don't think I've ever been an interview where I have not been asked this question. Yeah. This is always a tough question. I guess it depends on how they're asking you. I had one interview where they essentially were basing the entire interview

off of my answer to that question. So I ended up saying backpack, and then they're like, oh, because I use my backpack a lot. I spent a lot of time looking for the best backpack in the world. I found it. And I told them that and they're like, No,

27:41

I'm a huge backpack fan. And I love spending money on backpacks. What's the Osprey Radio 26. I was like, talking to manufacturers in Vietnam to make my own custom backpack, because I like was that desperate for a good backpack? And then I ended up finding this one, and it's perfect. I've had it for like four years. But that was like my answer. And like, I like my, I mean, he was interested. He's like, I need you to answer like a sophomore question. Okay. And you have software app for this? So I don't know, what's your experience with that question? Yeah, I mean, I've had my fair share of interviews, where I've come up with a product that I've shared, which the person on the other side has heard of, and has used. And I think when that happens, when there's that common knowledge for the product, I feel like it's an easier answer to give then. But when when the other person is completely in the unknown of what product you're talking about, and like, what's the problem it's solving, then it's really hard to bring them into your story. And I think it's hard to like make them think of the problem and empathize with that user base, and then show them how this product is actually solving that problem really well. So I think it depends on like that product, and if the other person has used it or not, or knows about it or not. Yeah, I think that's a big point. Because I think sometimes like I answered, like, esoteric app, and the person said, okay, and then I think for me, like a smart, there's like a news app. And then they're like, Okay, it's a news app. What's so great about it, like, that kind of falls flat. So it's a nuanced question. There's like, different ways of answering this one. But I think my go to is now like, think of a product that's a little bit famous, or at least the other person would know about. And then figure out like, why it's a good product and why it's your favorite product. Yeah, but not too famous. And don't say no to famous Yeah, or not too famous. Yeah. Not too famous. It's very important, because then you're just like, I just generic, especially if you're a product versus you're supposed to have a more nuanced kind of understanding of what a good product is, and who makes good products besides like the big companies. Yeah. And then I think the next one, which is always part of an interview set, along with the others is the behavioral ones. When you talk about collaboration and conflict resolution, I think those in a structured interview are the closest that you can get to unstructured but again, there's still always a specific set of

30:00

Question sometimes like, how would you resolve a conflict with the engineering team? How will resolve a conflict with the design? Like, has there been a situation where you had to do that? And I think like, that's also a big part of these interview questions that comes up a lot. Is that behavioral side of being a PM? Oh, yeah, absolutely. I think this is also like a place where preparation is important, but also can kind of hurt you. I don't know. Have you had any experiences where you prepared or over prepared? Or well scripted? Like any of these questions? Yeah, I actually got the feedback. For one of my interviews where I was told that it seemed that I had made up because I practice it so much like I knew it was going to be asked, and it was such a good situation, that I really wanted to be sure that I could get the story across. And so I practiced it. And when you practice it, it sometimes does come off as scripted.

And I remember the interviewer is like, oh, that sounds like you might have added a few elements. I'm like, I know, it sounded scripted. It's a big thing that happened for me as a PM, and it's come up a lot. So I've talked about it a lot. And

31:03

you do want to be a little bit cautious of sounding completely scripted. We all know this, like this question is going to be asked because it's asked on just about every interview. And the thing is that sometimes they because you kind of have to have like a nice kind of wrap everything up with a bow, which is not really real life, I think I had one interview or a couple of interviewers who, like, they took the same story I always use, they ask the question that went a step further. Like did this really happen? Like what how did the like engineer who was idea wasn't implemented actually feel? And I'm like, I just told you, you know, I don't believe in it's like, Well, you're right, because that's not how it works. This is real life, the guy was pissed. I can tell you that. No. But now, when I look back, when I think about those questions, the ones that have gone the best, and not from an interview perspective, but from an actual conversation prospective have been the ones where it's been like, yeah, it didn't work out. Like, I tried my best used methodologies of conflict resolution negotiation, and like collaboration, we tried to get to a point where it was working for everyone. But you know, it didn't. And I think that sometimes being able to see and admit that, as a PM actually ends up being very strong quality as a product manager. Yeah, absolutely. I think being able to, like demonstrate you knew what the right thing was, or like, it doesn't necessarily work is 100%. I think in the interview, that definitely didn't do that. But it was also a few years ago, when I was a little bit more junior. We've all been there. Yeah. I mean, you also panic, and there's always nerves in these interviews, especially after 13 hours invested, or money. Yeah. But I think if you wrap up the structured pieces, I do still think we need. We've talked about so many different elements of this. There's always like those few things that are still happening in the wild with pm interviews that you hear about often enough, but they aren't necessarily part of the structures. And I think one of them is a panel presentation. I've seen that happen more and more often. Have you experienced that as well, or any others, like similar to a panel presentation? Yeah, I think like there's always like I found is more of the startups is like, give you some type of take home assignment, like create this strategy deck, and then present it to like a panel of different folks in their office. So yeah, definitely had those. They're a huge time suck. Like, I feel like I spent like 20 hours on the Taiko on making the deck and then you present it to the all the folks. And you know, there's sometimes have a good conversation. But often, at least in my judgments, they've always tried to have me answer a question that they're trying to answer, which I think is really tough, because they've spent lots of like, this is a kind of a big pet peeve of mine is when interviewers ask questions that they're trying to answer, and hope that you magically answer it without having any context. So oftentimes, that's what I find the take homes are there around specific problems that that company is facing. And then they're looking for you to present that even though they've already thought about 1000 ways to Sunday to solve that same problem. So it's something that is kind of a red flag to me. And I actually just, I haven't taken those in a couple years at this point. But what about you? Have you ever had experiences with take homes or any other types of things that you've seen in the interview process, I've had take home assignments as part of my internship hunt, I had quite a few in recent times, I've not had take home assignments, but I feel I've had a panel presentation in each one of the interviews that I've done after graduating, except for like, some of the bigger organizations where it's a bit more structured, as we talked about outside of that, each time I've had to like, do a panel presentation. And it's been both like I've had the prompt beforehand, or I'm given the prompt then in there and then I get 30 minutes to prepare a

complete presentation and present a panel never seen that one. I think that was a little better. Like I mean it's probably more stressful but at least your your time kept. He was he was really stressful. I remember like when I presented when I was given the prompt in person and I had 30 minutes. I was pretty good deck together and you could clearly see how the aesthetics of the slides just kind of slowly stopped like slowly degrading across like the first slide is

35:00

Beautiful second slide. A little lesson by the time I reached the last one is just pure text because I just didn't have time. Yeah, well, maybe a little cruel. But also, I don't know if that's better than letting you waste 20 hours on something that I can afford. But yeah, I mean, but I think banner presentation, the take home assignments are becoming way more common in the pm interview. And I think that's something that we should definitely have on our radars. When we're preparing for pm interviews. I have like a hard policy against them at this point, just because oh, man, that's so many bad experiences with those. But I think especially at the beginning of your career, like beggars can't be choosers, I think, was my initial policy. And I definitely did a lot of these. Do you have any personal tips on preparation? Like anything that that's your go to, or something that you do when you're thinking about preparing? Yeah, I mean, I definitely think I spend a lot of time during the whole interview prep game, I think my go to was watching a lot of mock interviews. And then actually, so when I was doing this, a couple years back, I was actually hired a coach to do mock interviews with me. So that way, I was able to put in like, three hours of interviews a week without actually doing interviews. So essentially, like three hours of mock interviews for the coach and then able to like, they had a lot of really good feedback. So I was able to level up and accelerate my learning. So something that would have taken me maybe, like three or four company interviews I could do just in a few weeks. So that was kind of my little hack. I think he was like maybe $100 an hour, we 100 hours a week might sound like a lot. But I guess what is the opportunity cost is every week that you don't have a job that will take some of these more structured pm interviews, and help you level up into the higher paying emulators. So that was kind of my justification. I was cheap. And I just asked my friends to take my mock interviews. I think I didn't really know any PMS back then. I was like the only pm in the startup. So yeah, that makes sense. Yeah, it was until later in my career like now. I feel like it was my friends or PMS. But back then it was just gonna, mostly designers, I think. But yeah, like friends are a great way. Friends. I think listening to YouTube interviews, especially for the big companies actually had the same questions that I saw on YouTube on the mock interviews. Well, I think I have three out of four are identical in my actual interview. So I think those were super helpful. So they definitely like reuse a lot of their same questions. And a lot of those questions are on YouTube and online. So just practicing these online resources like Lucky. Oh, yeah, I guess it seems like you're only looking back on like my injuries. I'm just like, Yep, I know what their product was. Oh, the estimation. Yeah, I literally listen to this estimation, like this morning before when I was preparing.

37:35

Yeah, I definitely got really lucky. But I think I've heard the same stories from a lot of folks. So I think it's pretty well known that all these bigger companies are using a core set of questions. And you can find those questions online. Like I had a software engineer friend, he did like the first three questions on like, whatever the code testing, or code learning, like test prep, and like the first few questions, were the three questions he had in his interview, it's definitely

something that happens fairly often. But the more you prepare, the more likely you're gonna have seen one of these questions that they're likely to ask for these big companies. How did you prepare for yours? For me, I think the biggest thing that I do a lot when I'm preparing is like, write stuff down. I think the most prepared for that whenever I'm looking at, like how we design or if it's like thinking about like, past experiences and everything, I just put everything on paper, I come up with the framework that I want to use, I come up with the flow that I want to use, not that I would write the exact like answers. But I really, really would like to look at every different combination of question that's possible. And then like, put in the reps to like, Okay, think about the problem, put the framework on paper and see if it's actually solving it. I remember for like one of my previous interviews, I went online, and I looked at like different type of product design questions, which included like, how would you design? How would you improve, like, metrics gone haywire, like all of those things, and I would just, like, open up a notebook and jot down like, the main points that I would have for all those answers. And I will just like, look through them again, and again, just like prepare and think about it, like improve. But yeah, that was something that I did quite a lot. I did not have the luxury to get a coach, and like someone on this podcast, but I did a lot of that like sort of writing down and putting my thoughts on paper. And then just like, looking back to it again and again, like recording yourself. That's such a good point. I haven't when I feel like that's actually used, I can see that being useful. I don't know why I haven't tried it. Maybe I just feel like, I don't want to listen to myself because my I hate hearing myself. So maybe that's why but I can see that being really useful. That was one of the things that I did to prepare, but exactly what you're saying I just couldn't bring myself to like, listen to myself, talk through the questions. But I think I mean, if you're okay with listening to your own voice, and you can go through that agony percent. Yeah, that's a pretty effective way. But really, it just, it's like putting in these reps. I mean, I've always spent like over 100 hours, just on like these structured interview questions, and just doing again and again, like we always say it's just like putting in the reps and

40:00

also, I think having some throwaway interviews, like there's always a company that you really want to work for. And if that's your objective, don't just apply there will apply to a bunch of smaller companies to put in your interview reps. And when you get an offer to one of the smaller companies, then you're ready for the actual objective company is kind of my recommendation. Yeah, that makes sense. Like, it's the reps, we always come back to it again, get whether it's being a PM, or whether it's actually preparing for an interview with the reps, like just putting in that hard work. I think all the PMs that you see who are in these big companies in big positions, they all went through this kind of meat grinder of process. So I figured out how to answer these questions properly, and to kind of show the right face to the interviewer. So what do you think are some of your worst interior mistakes?

40:47

I think one that I brought up earlier was like, sounding overly scripted, which is even more painful as a mistake, because it was the real story. And I don't know if that's a mistake, or it was just like, I prepared too much. And it sounded scripted. But I don't know, I can think about as a mistake, maybe not, maybe it's just not the right story. And for that time, but maybe that one, the second, I think was not actually picking, it goes back to the question of your favorite product, like not picking a product that I actually liked, and was passionate about, but trying to

pick a product that I thought my interviewers would like, and talk about that. I think that was a very big mistake. Because I did that in like a few interviews and the questions that they would ask after or like build off of that favorite product, like I just, it wasn't a space that I enjoyed that

much. I was just trying to do like fanservice and hoping like it's a product that they would like and they would enjoy. And so I brought it up as a favorite product. But it wasn't something that I was really passionate about. So when we came down to like the set of questions that were built on top of that, I wasn't able to do such a good job of it from a product perspective. Yeah, I think it's a point. I think a lot of times that question is often to lead towards additional questions. If you don't know the product.

42:02

You're kind of

42:05

Yeah, you should effing use the product that you're going to talk about. Like, if you're going to talk about your favorite product, you better make sure that it's your favorite product. Yeah, because I think often like, the next question is, how would you improve that product? And if you don't know their product, that's a very hard question to answer. Yep. How about you like do you have, like, worst interview mistake? Oh, I mean, the one that I mentioned earlier, where the guy is like, I don't believe that that happened. I was like, Oh, my God.

42:33

Yeah, there's been a couple of times where the interviewer so often, like, like we talked about, we have like these scripted answers, I've only had two interviewers who asked a question, like one more question, like, they went one level deeper, beyond the facade. And that's one of the things had a crack. That happened to me twice. And I think ever since that I just stopped kind of embellishing or making a nice story only, like just kind of ended up telling the truth, like we

talked about earlier. But it's just like, it's such an awkward thing, because like, the interview was basically over as soon as I made that mistake, where I couldn't adequately answer the question is like, Well, yeah, it was like, after eight interviews, like, eight hours of like, just interviewing and like preparing, and then like everything else, and now I'm like, well, GG. So I think that's a bad feeling. It's funny how both our mistakes, like the one that we think about and look back at aren't really in the typical structured questions like design or execution, but more on like, the behavioral aspect, or like the unstructured question around like your favorite product, which is, like, it's just something that does, I noticed, and I'm wondering, like, why that is? It's funny, right? When you think about the mistakes you're making, you're making in the ones where, which are more based on experience based on your actual, the way you think, and not necessarily something that you could prepare for, through like, answering and like reading, etc. Yeah, I think the structure ones like we have that structure to fall back on. But when you just kind of hogging and you try to make an unstructured thing, a structured thing, like a structured answer, and that's where things kind of go awry. I think my biggest takeaway from those two mistakes is not is always to allow for a question to go deeper, because it's grounded in truth. And what like, in every I think what I found is the good interviewers, they really truly like VP level, folks who are interviewing you, as you get further in the funnel. They're the ones

who are gonna are the other ones who are asking this question are always going a level deeper. So and that's how you're a great PM. Like that's also something about being great Pm is that you go that one level deeper, you ask that one question that no one else has asked in the room? Like that's a sign of a good PM, and that's a sign of a great interviewer as well. Yeah, exactly. And so you can't be asked these folks. So if you're just lying, if you're just like making like a story, by the time you get to that level you would have if you just do the same thing, you would have wasted all of your getting there. 100% It's so true. Oh man, this was a fun one. Going back to all those different interviews. Oh,

44:59

yeah. Jensen

45:00

interviews over the years

45:02

it was a fun one but yeah I'll see you on the next one thanks so much yeah