TPM at Google: Preparing for TPM Interviews at Amazon, Microsoft & Google – Part III

Technical Program Management Podcast with the author of the popular blog Engineer Seeking FIRE. He has been a Technical Program Manager at Microsoft, Amazon, and is currently working as a TPM at Google.TPM at Google: Interviewing at Amazon Google Microsoft

Check out some of his best posts:-

• Career Advice for Software Engineers
• Salaries for Software Engineers are On FIRE!
• Inside the Culture of the Top Tech Companies

In this podcast series, we talk about:-

1. The speaker’s Blog.
2. The Impact of Covid on our current work environment 
3. The TPM role at Google 
4. How the TPM roles compare across – Amazon, Microsoft, Google 
5. Interview prep for TPMs ?

The podcast series is divided into three parts.

• TPM at Google: FIRE & COVID Part I
• TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google – Part II
• TPM at Google: Preparing for TPM Interviews at Amazon, Microsoft & Google – Part III

This is Part -II of the series, and we discuss the speaker’s blog, how it all started, we talk about FIRE, and the importance of financial planning and close this episode with the impacts of covid on our work as TPMs.

Thank you,

Mario Gerard

Podcast Transcript

 

Hello and welcome to the TPM podcast with your host Mario Gerard. This is part three of the podcast with the author of the blog engineer seeking fire. He has worked as a TPM at Amazon, Microsoft and is currently a TPM at Google. We discussed the author’s take on how to prepare for interviews, and what are the types of various interview questions you could hear at any one of these tech organizations. So do stay tuned.

Preparing for TPM Interviews – Insider’s Guide

Mario Gerard: Now, why don’t we take a little different route and I’m going to ask you about how I saw a blog and how you said how to prepare for interviews. So let’s move into a topic where we’re going to talk about, in your opinion, how should a TPM prepare for TPM interviews for any of the tech companies in the United States or anywhere else in the world? How would you approach this? And maybe you could go down into a lot more detail about that.

Mr. ESF: Sure. So the way that they say about this is that there are three types of questions and kind of six main areas where a TPM needs to know how to answer in interviews. So the three types of questions are factual, behavioral, and hypothetical. So a factual question is something that requires prior knowledge. For example, if the technical question like what’s the difference between a struct in C and C++ that might be, for example, a factual question, you might you need to know the answer in order to answer this. Then there is a behavioral question, which is, tell me about a time when you did this.

Tell me about a time when you managed a very complicated project, for example. And then there’s a hypothetical question, which is, okay, what would happen if you had a project plan and suddenly two of your developers left, for example that’s a hypothetical question. So these are the types of questions, the factual, the behavioral, the hypothetical, and then we have the areas, so the topic of those questions, if you want to call them.

Project Management

So one is the project management area. So that’s probably one of the top areas. So that’s the core part of the project of the TPM. So how can they plan, organize, execute the project? How can they create, manage, and improve business processes? So how can they function as a TPM? And again, in order to look at the project management knowledge, you can ask all three questions like a factual for example, what is agile? Behavioral, tell me about the time when you were organizing a project using the Agile methodology, or a hypothetical, if you had to structure a project using the Agile methodology, what do you do?

Mario Gerard: Wow, super cool. I just love the way how you map that out and categorize that, that’s really cool.

Mr. ESF: Yeah, that’s the way that I see these. And then, because many people say, okay, it’s just behavioral question, or it’s only in certain behavioral questions, just to have a top, right. So that’s the project management, that’s the area. So the first area would be, let’s say, the project management area, then the second area is kind of them the technical depth. So again, I say, as a TPM, you need to show your technical judgment. So the questions are related, how able is that this person to participate in technical discussion with engineering team? How can they contribute to a technical discussion?

For example, again, you might have different sets of questions, for example, a factual question, you know, I said, I asked about the difference between the struct in C and C++. It could be a behavioral question. For example, tell me about the time when you were facing a very complicated, when you had to work with a very complicated stack, and the design the stack for me. And all hypothetical, it could be for example, if you were the TPM on, let’s say the next, let’s say Amazon project, how would you create this? The next Amazon VR headsets. Again, I’m not sure if Amazon creates one, but it’s the next Amazon VR headset. How would you design the stack?

Mario Gerard: There is no inside information. You are just pulling a rabbit out of a hat.

Mr. ESF: Yes, just pulled there. It could be a Facebook, it could be a Google one. So I’m just pulling, I have no idea about Amazon inside. But these are the types of questions that they might ask in order to understand the general technical judgment.

Evaluating your technical depth in an interview

Mario Gerard: And I think you very initially pointed out a very, very important point here, the whole technical depth, the fundamental concept there is to understand how good would a candidate be when they’re having a technical discussion. It is not that the TPM is going to write the design document. It is not that the TPM is going to lead the architectural discussion. It is whether you understand one and are able to participate and maybe add value to a technical discussion. That’s the core concept of evaluating your technical depth in an interview is for those three factors.

Mr. ESF: Correct. The goal is not to, at least in the position that I have seen, I haven’t seen any case where somebody asked the TPM to write complicated code on the whiteboard, it’s mostly about how would you design things? And then try and understand from the perspective of the interviewer, they want to say, do you understand the concepts that you’re talking about? They might, even if they asked you to design something, they will probe on different areas just to understand that you’re just designing a box and putting out of there or do you understand what a scalability problems they are, for example. So that’s what they want to get from the interviewer side. And then a third area, that also depends, might be optional. But sometimes, there might be questions, specifically on the position.

So if you are interviewing for a specific position, they might ask you questions for that specific position just to see if you’re the best fit or not. So some companies do that, some companies don’t do that. So the domain knowledge questions. For example, if you are interviewed for a networking position, they might ask you about something about networking protocols. Or if they if you are, let’s say hardware TPM, then they might ask you about the hardware lifecycle like EVT, DVT, or PVT, what are they, you know, stuff like that.

Or if you’re working in ML, machine learning, so they might ask you questions about machine learning models. So these are not always there. But sometimes things might ask those types of questions, just to judge your knowledge. So going, not only on the technical depth level, but going a little bit more deeper on the domain specifically for that particular question.

Domain Knowledge

Mario Gerard: I think that happens in two cases. One is it’s a senior or a borderline senior to a senior principal type of a role, number one. Number two is if you’ve already worked in that particular field, if you worked in ML and you are coming into an ML team, or if you worked in building out regions, for example, and you’re interviewing other organization or a team, which is building regions, then people want to know, like, how deep is your knowledge? Or are you depth focused? Or are you breadth focused, and where your strengths and weaknesses are.

I see a lot of that, especially in the b2b in the cloud area, I think, under the ML space, you are definitely. And in other spaces, like I know, TPMs who are moved from organization to organization and they only do payments, for example. They’re experts in payments. Amazon, they’ve worked on payments, they’ve gone to Google on payments, and now they’re on stripe on payments. So there are people who have certain domain knowledge. And if you have that, you ideally would like to showcase that and, you know, get some brownie points for that.

Mr. ESF: That’s great. Then also, I forgot to bring one of the differences between the companies that we mentioned about Microsoft, Google, Amazon is the way that they hire, for example, as I mentioned before,  at Google, you’re hired to become a Googler. So you’re not trying to be in let’s say, this particular position, let’s say in Google search for example, you’re the hire to be Googler and that’s why it’s easier to switch between things. Whereas for example, at Microsoft, you are hired for that particular team.

So there they might ask you specific questions that might be related to the team. And the person who makes this decision in Google is a hiring committee versus Microsoft, it’s the hiring manager for the team. So that changes things quite a bit. Amazon is kind of makes for NBA recruiting, where you’re hired for Amazon, but if you’re not, then maybe you’re hired for the team. So it’s a little bit of mix there. But that also plays a role about whether you will get asked domain knowledge questions, or if you’re or not, or is the questions will be more generic.

Analytical ability

Mario Gerard: So you said six areas, we’ve covered product management, we’ve covered domain knowledge, and we covered technical depth, and we have three more to go.

Mr. ESF: So the next one is the analytical ability. So this is about giving the interviewee an ambiguous problem and figuring out if they have a methodical thought process. So this can be different types of questions. For example, in estimation questions like how much let’s say storage does this particular product use? And then you’ll have to, instead of just saying in numbers saying, it’ll use five terabytes or gigabytes or whatever, you have to show that you have some methodology to calculate this number. Or another set of questions is they ask a problem. So let’s say, you know, you’re working on this particular product, and suddenly you see outages in Spain, what do you do?

So again, instead of throwing random ideas, it’s about how do you figured out this in a methodical way, so that you have structure in your thinking process. So that’s the idea behind the analytical abilities. Make sure that you’re structured, and you just don’t throw ideas like that on the wall and see what sticks.

Mario Gerard: I think for something like that generally what I tell people is, take a step back and maybe take a minute to think about it. And before, like just regurgitating all the answers and all the things that come to your mind, like compartmentalize the problem, and, you know, then attack the problem and form a story around it, like, how do you start? What’s your body going to be? And what’s your end going to be, especially in an analytical problem, because it’s going to be a new problem, you’ve probably not heard of it before. So it’s kind of important that you take a little bit of time there with the answer that.

Mr. ESF: If you think about it, for example, let’s say they asked you, you know, you’re working on this particular product, let’s say you’re working on YouTube, and they asked you how much storage will YouTube need for this particular scenario? If you are the TPM, you might be actually asked to do this. And then you might need to get some input there, you might need to ask yourself, how many users will be using this? How much is the average let’s say storage per user, stuff like that. So you need to get this number. Even if you don’t have the actual numbers, just writing down what you need, and then making some assumptions and then putting some  stuff makes sense, that will help you calculate the number that, you know might or might not be logical, right?

So if you say that, okay, YouTube will use five megabytes for the next month of storage, then obviously, at some point, somewhere, you made the wrong assumption, right? So you need to explain Okay, this is totally wrong. It’s not only using five megabytes, for example, I made a mistake and then explain where might be the source of the problem. So it’s not only calculating a correct number, it’s making some assumptions that makes sense. And then based on those figure out if the final number again, makes sense or not. So you have to evaluate every step in the way as well as the final result.

Mario Gerard: Got it. You have two more.

Leadership & Collaboration

Mr. ESF: So the next one is the leadership. So as a TPM, we lead things. So again, this is about how can we show to the interviewer that we can lead and influence the team. So this is mostly a behavioral exam. So they might ask you, you know, tell me an example where you lead the team or how you influence some person or maybe if there was some conflict resolution or maybe how did you engineering team as a TPM? So this is mostly behavioral examples. And then the same thing with the last area, which is collaboration.

So it’s about, collaboration is about how well can the interviewee work in teams. So as a TPM, you’re embedded as part of the team. So you need to have examples about how well you work there. So they’re trying to figure it out from the interviewers perspective, how well you work there. So in summary, I know it’s a long answer. So there are six areas where project management, domain knowledge, technical depth, analytical ability, leadership, and collaboration ability, I have way more details in my blog as well. But I try to capture the whole process.

Preparing for the TPM interview from a Project Management Standpoint

Mario Gerard: You can definitely, if you’re listening in, you can definitely look at engineer seeking fire the blog, I’ll put a link to this particular post, in particular, at this juncture. Also, there’s going to be a full transcript of the podcast published on the www.mariogerard.com podcast site. So you can go there, and it’s going to be much more easy for you to read through this. So that you know, it’s all better structured, in a written format. So the next, what’s the next topic? How do you prepare for the TPM interview from a project management standpoint?

Mr. ESF: So there are, we covered questions. So I think, if you think about them, the answers belong in specific groups, for example, first of all, you need to know the project management fundamentals right. So you need to be able to speak about the different methodologies, you need to know the correct key words when you’re answering there. So you need to know the project management fundamentals. And for this one, I suggest that it might be very useful to review the material for a PMP class. This is not about becoming certified as a PMP. I’m not sure. So PMP, by the way, is a project management professional.

Mario Gerard: Are you certified?

Mr. ESF: I’m not certified, no. And I actually don’t know many people who are certified.

Mario Gerard: Exactly. I tell people, I tell all my listeners do get certified especially if you’re starting out as a young person, starting your career, I think it will be very valuable. But even if you don’t get certified  as author here mentioned, it’s definitely good to look at the material.

Mr. ESF: The goal is to kind of put a structure around your way of thinking. So the PMP does great in putting lots of structures and helping you think about things. So you have checklists, for example, I can give a very quick, very easy to understand example. So somebody might say to you as a TPM, what tools do you use? And you might say, Okay, I’m sending emails, I am using, let’s say, maybe outlook, and I’m writing documents, I use Word, and then, I don’t know, I do some calculation. So I’m using Excel. And that might be an answer, right?

But if you think about it from let’s say, from the PMP perspective, okay, you have stakeholders. So what do you need to do with those stakeholders? Okay, I need to communicate. So my communication plan has email. So I’m using, let’s say, the email to send emails to stakeholders. I’m also creating presentations. So I use the PowerPoint or Google Slides to create the presentations to those stakeholders, I might be doing all sorts of other things with those stakeholders. And then how do I create the project plan, so I might have a specific software for Gantt charts, stuff like that. So that’s how the PMP material held so that you can codify your answers in your mind and then make it easier for you to go through the checklist and provide those answers in the interview.

Because in most cases as a TPM, we know these answers, but it’s very difficult in any time to think about all these answers. And then, so knowing these project management fundamentals, I think the PMP class, I think helps. And then the other part is, there are lots of behavioral questions. So you need to think about all your equations and write them down in Star format. So the star format is situation task action result. So that’s how you kind of answer your, so if they ask you tell me about an example of where you did x, you need to have examples about how to, from your previous experiences about when and how you solve this problem. And the star format is great.

There are also lots of hypothetical questions. And then that’s when you think about, you need to think about tradeoffs. The most important tradeoffs in your answers should be time, resources, and scope. So for example, you have a project plan, a developer left, what do you do? You need to think about the tradeoffs there. And then the other part, the last part is the technical side. So there shouldn’t be any coding in technical interviews for TPMS. So I wouldn’t suggest that you spend a lot of time for coding preparations. But there are two things that you should do at least. So one is think about it very technically challenging projects that you did and create a design diagram, be able to talk about this, talk about tradeoffs, answer all sorts of detailed questions about what happened there. Why is this component connect to the other one? Why did you make this decision to use that component? So be very focused on explaining that.

Mario Gerard: And I think when you do that, you can also ask yourself, put yourself in the interviewers shoes, and ask those questions to yourself. I think sometimes people do part one, which is they create the entire diagram and draw the whole technical challenge. But they leave it at that they don’t take it one step further of putting themselves in the interviewers shoes, and saying, hey, what are the things, if somebody presents this particular diagram to me, what are the questions I would probably ask them, right? And that is one extra step you can take when you think about your previous project, to you know, close the loop on that.

Mr. ESF: Correct. And then the next thing again, is also apart from your own project, think about other projects. For example, how will you design Airbnb? How would you design Lyft, how do you design Twitter? So there are all sorts of design questions that are there, and you have a great design class, so I highly recommend it. I think it’s a great class to help others learn about design. So understanding how to design, how something else is designed, is great. And spending the time there to learn how to do these things will definitely pay off in technical design interviews.

So these are pretty much the, so from a technical perspective, looking at previous projects, and seeing how you would design some product that already exists, that these are the types of questions will get asked there. So that’s what you should prepare, or maybe some other types of questions or technical questions like what happens when I type it’s a www.Google.com or amazon.com or Facebook.com what happens?

So, this is something that you should be you know from a very high level technical perspective, you should be able to answer. These are the types of questions to answer so. So just to summarize this long answer, we have the project management fundamentals, which is Go to look at the PMP class, the thing about all your stories, talk about your experiences, and then the technical side, which is looking at previous projects, and how to design your project. So these are the three big areas on how to prepare.

Mario Gerard: And then there are also probably, there’s one more aspect of how you’d prepare, depending on the organization you’re choosing to go into, like, for Amazon, you might look very, you might spend more time on the leadership principles, for example. Microsoft, you might prepare both for the product management side and the TPM side. Because unless you know, and that’s a good question to ask your recruiter as well, right? When you talk to a Microsoft recruiter, you can always ask them, is this going to be more product management? Or is this going to be more TPM centric, the role itself. And you can prepare more for that. And then Google, do you have any tips for Google as specifically as a TPM that you’d want people to focus more on?

Mr. ESF: I think one of the things with Google is that there are, if you think about it, there are five, let’s say around five interviews at Google.  And then you’ll get asked at least two or three questions, where interview. So many of those will be about a previous experiences. So think about as many stories as you can about previous experiences, and about how you solve problems in the past and have multiple answers there. Because you might get asked the same thing multiple times, you might think, Okay, I have 3,4,5 stories. But then if you think about it, if you have five interviews, they might ask you, each one might ask you three behavioral questions. So you might need 15 stories. So it’s very easy in Google to run out of stories. I think that was one of the things that I’ve seen a few times.

Mario Gerard: You don’t want to repeat the stories across multiple interviewers. Ideally if you can, depending on your experience, of course. If you have four years of experience, I think if you repeat a couple of stories, I think you’re okay. But if you’re on the other hand, if you have like 7 to 10 years of experience, or 15 years of experience, ideally, you have enough stories to talk about.

Mr. ESF: That’s correct. And one of the things with Google is that there is a hiring committee. So every interviewer will write down all the responses that you told them, and then they will provide some valuation. Either they are a hire, no hire, leaning no hire. And then all of this goes to the hiring committee. So let’s say you use the same story multiple times, maybe once per interviewer.

So the interviewer might say, Okay, this is a great story, you know, hired, but then if it goes to the hiring committee, and then the hiring committee, let’s say you’re a senior role. And then every time they ask you a question, you only have one project, they might say, okay, has this person, you know, throughout, let’s say, 15 years of experience, or 10 years, or 20 years of experience, have they only worked on only this one project?

And then they might say that person doesn’t have enough experience, let’s say to work at Google. So that’s why it’s important to have, it’s not only about providing the stories, it’s about showing that you have worked in multiple different areas, you have lots of experiences. And again, as you said, the more senior somebody is, the more stories they have, the more projects they’ve worked on.

How is compensation structured in these top tech companies?

Mario Gerard: That’s really good to know. And since we started off this whole podcast, talking about fire, I wanted to sidestep and see if we can talk a little bit about compensation. How is compensation generally structured in technical organizations? I think a lot of people who are already in tech organizations probably know this. But for people who are in a non tech organization, and or trying to move into tech organization, I think this would be a good segment of understanding like, well, how is compensation generally structured?

Mr. ESF: So let me give you a little bit of a generic, the general answer and then see how this applies into say, Amazon, Microsoft, and Google because that changes a little bit between the companies. So when gets hired, at any company, your offer is the salary, so the base salary, and then you have some a, for example, this might be a $100,000 per year or $150,000 per year, then the sign on bonus. So let’s say it’s $15,000 $50,000, you know, some part of the, which you get is during the first month when you start and then there is some type of stock, which let’s say might be $100,000 in stock, or $500,000 in stock or a million dollars in stock, depending on the interview.

Mario Gerard: Sorry to interrupt you, generally I think it is units and stock, just to be clear, right?

Mr. ESF: So the way that they’ve seen it is that they tell you a number when you get the offer, they might tell you you’re getting, let’s say, $200,000 in stock and then at some point, this gets converted into company stock. So they will tell you, this $3,000, Typically, after your start, at some point, after you start, based on the current stock price, it gets converted into, let’s say, 2000 units of stock, or 500 units of stock, based on the company’s stock at the time of the conversion. And then this gets allocated for the next three to five years, depending on the company. Some companies give it for within three years, others within five years.

So for example, if they give you $300,000, in stock, this gets converted to stock, then at the end of the first year, you might get 1/5, at the end of the second year, the other fifth, etc., etc. And then as the stock increases, or decreases, then this part of the compensation increases and decreases. So that’s the sign on part of the, so that happens, that you get this when you sign to a new company, at the same time every year, when you’re working in a company there is valuation, so you go through a performance review. And based on whether you have good performance or not, you get another additional cast as part of the performance cycle, and then additional stock that gets wasted in the next, let’s say four years. So you might get, let’s say $50,000 as cast, now and then another, let’s say $200,000 in stock, the best within the next 40 years.

Mario Gerard: And this kind of so much varies across different organizations. And also the rules sometimes change, like you could have a particular rule today and then generally doesn’t change. But it also sometimes I’ve seen it change, like vesting schedules change. Some companies, you get your vest throughout the year, like every quarter, some companies, you get it every six months, some companies you get once a year. So the vesting schedules is also another important thing to kind of keep in mind when you’re comparing various tech organizations.

Mr. ESF: Correct. And agree and I think you’re very right. So when you get, especially the stock or the stock, we talked about how much stock you get. But we didn’t talk about when you get this stock, sometimes you get the stock every month, sometimes twice a year, sometimes once a quarter. So depending on the company, and depending on maybe even the amount of stock sometimes this changes.

Mario Gerard: And that’s the vesting schedule, right. So the vesting schedule changes throughout the, depending on the company. So that’s something to keep in mind. So on average, what do you think is, in Seattle or in California, What’s the average salary, you know, or total compensation, of a TPM, a senior TPM and a principal TPM? Like what are the ranges that people should be kind of looking at.

Mr. ESF: So it varies a lot. So Seattle California even more, it’s a very vast range, between different companies. So just some very high level numbers. So for example, if you are looking at Google or Facebook or maybe even Amazon, if you think about them, the intermediate TPM, because most of the, it’s difficult to find the most companies an entry level TPM. So most of the TPMs will be kind of intermediate. So like, at Amazon, sorry, Google or Facebook. So total compensation would be something like a $230,000, $240,000 around that range. If you go into the senior role, so that could be around $300,000, maybe a little less. If you go into the principal role, maybe you get close into the $400,000 range. So total compensation. So I think these are the numbers, approximate number. If you have sometimes you have competing offers that might get more. So it depends on the, that’s pretty much the range.

Mario Gerard: I agree to that. Sorry you were saying, Sorry I cut you off.

Mr. ESF: So I think this applies for the high paying companies, I guess, Google, Facebook, and Amazon, I think because these are kind of the ranges, you know, from a very high level perspective. And I know for example, other companies, even Microsoft, might be even less for example, Microsoft, for example, let’s say for a senior role you might get even though it’s senior, you might get $200,000 total or maybe 220. So it changes, obviously you get other things at Microsoft you got maybe better work life balance, stuff like that.

Mario Gerard: Good food, very subsidized good food. I love food at Microsoft. I’ve not worked at Microsoft by the way. But whenever I go to meet my friends there, they have fancy restaurants in campus, which are very subsidized. And then you get very good maternity and paternity benefits. So I think each company is different. Before I forget, one important thing when you look at salaries has fantastic information by the way for people who are listening, that’s almost gold standard. But very recently, so every two years, I publish a TPM salary guide, right. And I was going to do that in 2021. And the more I was trying to do that it was so difficult to do. And the reason why it’s become extremely difficult now to do is as the compensation bands are fairly remain the same.

So if you go to Amazon today, and you join as a senior TPM or any other company joining as a senior TPM, you’re generally hitting what our author here said, around 300. That’s what he said, right? But if you joined  like, five years ago, as a senior TPM, the stock has gone up tremendously. Or if you joined like three years ago, if you see the Amazon stock or the Google stock, or even the Microsoft stock, if we look at the last three, four years, the amount of rise the stock has given now has completely changed the compensation band. So it’s like kind of very interesting, well, who you talk to, and where they are in that phase of you know, are they in year three, are they in year four, and how much stock units they’ve been given and how much that stock is actually appreciated.

I was looking yesterday on where there was an entry from, I think, Pinterest, where it was $1.5 million for a TPM salary. And that’s because I should have probably checked, right? But there are people who got like a lot of stock. And then they went IPO for example, right. And then it’s like it’s through the roof. But in general, I think they can go by the yardsticks salary what you’ve given. But there are these outliers that you should clearly know that joining an organization and the timing at which you’ve joined the organization is kind of plays into that.

So that’s kind of important to note. And thank you so much for this wonderful podcast, we might do another podcast with the author, because we had prepared a lot of material, but we’re kind of running out of time. So we will come back and do another one at a later point in time, but thank you so much for joining us, and spending like so much time with us and giving so much valuable information to all our listeners. It was a great pleasure talking to you. And I probably learned a lot. And our readers probably would really enjoy this. So thank you so much for joining us today.

Mr. ESF: Thank you, Mario,  it was a pleasure being here.

Mario Gerard: Thank you.

And my friends, that’s the end of this series of podcasts with the author of the blog engineer seeking fire. I hope you found that conversation enlightening, and you learned something new. I did for sure. I would greatly appreciate if you could share this podcast with your friends and colleagues or anybody who might be starting the TPM journey.

Do check out the website for the transcript and the entire podcast notes. I’ll also be posting the link to the blog site for the engineer seeking where you can, you know, learn a lot of new financial information.

So, thank you so much. Thank you so much for listening in and I’ll see you at the next episode.