Tech Lead Manager Behavioral Interview with a FAANG Engineer (M1/L6+)

[Music] Hi, how are you doing? I'm doing good. How are you doing? I'm doing well also, so thank you for joining today. And uh, please let me know if there's any audio issues on my side. I do have some backup headphones, etc.

And great. So, so I'll start with just some overall setup. So just to make sure we're on the same page today, I have a behavioral mock interview with you, and I got that you have roughly seven years of experience and are targeting an L6+ role. Is that right?

That's correct.

Excellent and great. Okay, so regarding the target role, so that we can level a little bit, is there any level specific to a company that it might be relative to? Like maybe an Amazon L7 or like a Facebook E6 or E7 or a Microsoft L6/7, something like this?

So I'm interviewing for a role at TikTok, a Tech Lead Manager role. My assumption is that it's like similar to like an M1 at Meta.

Got it. And in terms of title, would that be like a Senior Manager or—

Oh no, it's just called Tech Lead Manager.

Uhuh. Okay, great. Excellent. So that is helpful. Tech Lead Manager, M1. All right. So, so I think that's great. So for today, uh, kind of like a normal interview, if we can start off with one or two-minute introductions, then given that this is a mock but also the interviewing iOS, I also give some brief tips and kind of expectations, and then we'll go into the main interview at latest by the 10-minute mark, maybe seven-minute mark, so that we have a solid 40 to 45 minutes as usual for the main part. And then with the remaining time, we can start getting into any feedback and questions. Does that sound like a plan?

Yeah, that sounds like a perfect plan.

Fantastic. So for the intros, would uh you like to get started or shall I get started? And again, this is anonymous, so feel free to share as much as you're comfortable with.

Sure, yeah, I can get started. So I'm currently an M1 as Meta, and I've been at Meta for almost 13 years now. Nine years of which I've been like a software engineer, and for the past years I've been like an engineering manager. It's only in like the past four to five months I've been in like the PR/SE space, and before that I've been in like the sales and ads space for like almost 12 years now.

Great. Okay, that is excellent experience. Thank you.

All right. So from my side, let's see. So I'm at one of the larger companies in the Pacific Northwest, headquartered there. Years of experience, about 9 or 10. I've mostly been a so-called IC, or individual contributor, but in the last four years or so have been leading uh more and more people over time. And what else? Yeah, I've been on this site for some time now, IO, and uh great. That's that's brief about me. And also, if you're familiar with this IO site, sometimes we do use the text editor, but for most behavioral culture interviews, it's mostly dialogue. So just pointed out if you want to type anything, you're free to, but there's no expectation to.

All right, so great. In terms of some of the overall clarifica—well, not clarifications, but thrust of what we generally look for in these interviews are some initial things I'll just note down which you uh may already know, of course. And on the respectful side, uh, yeah, we're always looking for, you know, as a person, uh mutually respectful, great to work with, collaborative with others, proactive. That's one thing, of course. Like when we get into some of your own experiences, like how you anticipated some things and maybe delivered something on your own or early. And also uh results-oriented, right? So if you've managed X number of people on a project, that's great, but kind of rounding out the story maybe with what the business impact was and how the relationship was also built. Do those sort of things kind of make sense?

Yes, it does.

Excellent. And also the STAR method, are you familiar with that acronym?

Oh yes, like in the previous two interviews that I did, this was brought up, which was like the situation, task, action, and result. I think to a large extent it goes into like the respectful, collaborative, proactive, results-oriented, but the idea is that you stick to this so that like you Iain very clearly what the situation was, what was the task that was given to you to resolve the situation, what action did you take, and how did you drive like the result.

Fantastic. Yes, and that's that's great. Yes, and on the result, uh, yes, how you drove the result and what the result was, that's that's perfect. Excellent. Thank you.

Okay. And for L6+, something that I will also note—oh, and sorry, this last bullet point is it does help to have some stories, if you will, or previous scenarios at your fingertips. And every now and then there might be a question that is uncommon but relevant, and it's always fine to say, hey, can I take a minute to think about it? That's perfect, you know, sharing your thought—thought process. But on those questions that you feel maybe you've gotten before and you have a good story for it, that's perfect. But we don't want to sound uh like robotically rehearsed, right? We we want to get the sense of, yeah, that person has it top of their mind, but they're really telling me this story, not, you know, reading from a script.

Okay. Now for L6+, there's I would say four additional areas that are sometimes good to touch on. Of course, it's not expected that we touch all of them in the span of 40 minutes or so, but if we can get to at least two of them that you have an opportunity to focus on, this would be great. So for example, one is delegation, right? As we manage more and more people, an example might be that we form relationships with others, maybe under us or at our same level that can also be managers of others. Uh, so that's one thing. Another is scalability of work, so that can mean how you help others be scalable or did some of your own work on scalability. And comfortable with uh conflicts, right? Understanding the other side and how you maybe still built a a good relationship even though people might have had different priorities as an example. And then the last one, which actually starts getting into so-called like executive level, is managing up, like how you've effectively influenced uh leadership, might be on a whole new project or change in course on something that was baked in for a few years.

Great. So we're doing well on time; we're near the 10-minute mark, but any questions overall here?

Uh, no questions so far.

Fantastic. All right, so let's get started with one question for today. So can you tell me about a time that you disagreed with your manager?

Yes. So the situation that I can think of is when there was a project that was handed to me, and this was a project that where in like—so the context over here is there's a project that was called as like growth plans where we were working with like product marketing managers to figure out like how we can optimize their outbound workflow. And the idea behind this is that product marketing managers talk to like uh product managers and like engineering managers to figure out like, okay, this is a new product that is coming in; we need to ensure that these products are shipped on time, and these are the metrics that we need to handle, and these are like the four or five main metrics that we need to drive in terms of adoption. So this entire process needed to be automated, and this was a new project that was given to me. Now, during road mapping season, the task that was primarily given to me from my manager's perspective was like, okay, you need to figure out what the priority of this particular project is in terms of business impact and then influence road map to get this project on boarded or like offloaded based on like what the relative prioritization is. Now, the—the one of the first things steps that I took was like consulted with the data scientist to understand like, okay, for a particular project impact that optimizes processes, how do we need to measure the success of these set of projects, what kind of like prerequisites that are required, and how do we measure like previous and pre-implementation and post-implementation so that like there could be a good story that could be attached and that can be presented to leadership in like the road mapping session. Now, once this task was given to me, I engaged with like the data scientist; I engaged with like the product marketing team; and also, to a large extent, like engaged with like the engineering managers because most often they're not—their entire workflow was done to like tasks, whereas like most of like the product managers work and product marketing manager just work by being done to like Google Docs. So you have this disconnect in terms of understanding like, how do we like tie two different like workflows without overly like burdening like engineers with like a change in process. So all of these conversations are going on, and to a large extent we had a good enough story that showed that that drove three particular things: one, there was a 10% reduction in overall time to market for any new product that was like alpha, beta, and a production launch; but the con was there was that you had to do a change management in the product marketing and like product uh manager departments. Now, this is where to a large extent my manager was pushing back on me as saying pretty much saying that, okay, the 10% reduction looks fine, but the change management aspect of things where you need to influence an entire or to like onboard onto this tool seems unreasonably uncom—complicated. So, so therefore, like we need to deprioritize this project in favor of like another project. Now, to a large extent this agreement was stemming from the fact of like, one, there was a huge amount of time investment that was involved that would have been involved in convincing leadership on like the product marketing and product marketing managers teams to ensure that they were on board in terms of like why this tool needs to be built out, how the change management should occur, what does that entail in terms of like training for this set of people. So that was one particular major like I would say areas of disagreement between me and my manager was like, okay, I felt like this was a project where we have the impact that is not being questioned, but rather the change management of things being questioned, like how do we handle this? There's like a too big of a process to be handled by an engineering team, which I understood like—like if you're talking about change management, it's a bigger process, and by the time you realize the impact you're going to have, like let's assume that if it takes three months to do change management, even if you build the tool at like N time, it will might take like N+3 time for you to even start realizing the impact of stuff. So especially if you're looking at like a short timeline of like six months or like a yearly review, how do we go about like doing all of these reviews? So all of these questions were brought up from my manager's perspective was like, you're now managing a team; you need to think about all of these things; so therefore, this project doesn't seem to give you the right ROI, whereas if you take another set of projects, it might give you the right set of ROI. Now, the feedback from my team was that they felt like this particular growth plans project, which even though it had the challenge of change management, they were very interested in like pursuing this. And since—so the stance that I took with my manager was that, okay, it looks like I understand the perspective that my manager was coming from, but I also bubbled up the feedback that I was getting from my team and from my stakeholders was like this project is worthwhile because of the fact of like the impact that was going to be realized. The new project that is going to be provided to us was to a large extent like it was almost equivalent in terms of impact, but it did not have the same sort of experience that my team would gain in terms of like talking to stakeholders, trying to figure out like, okay, if you have to build a tool where you needed to do change management perspective to how can you do that less more effortlessly, what kind of like intermediary tools or processors could you entail or build to ensure that people who are just using Google Docs could use like the new tool as seamlessly as possible, or how can we like ensure that they existing workflows seamlessly into the tool? So all of these were interesting challenges, like especially on the senior engineers on my team were interested in. So to a large extent, short the main things that I did was like speak with my manager, told them the areas where I disagreed with them, and also backed it up with statements from my team and the stakeholders in terms of like how they could like potentially reduce the change management friction that was being from my manager's perspective. My manager understood like the pitch that I was trying to bring in from, but he was also like on the fence in terms of like, okay, is this a worthwhile project to go with? So what I did was like, with his permission, like I spoke to like the skip from my arc; I spoke to like the skip on like the PMM and PMR; and I also dedicated some of the responsibilities to like the PCs from these teams, ensuring that saying that, okay, you need to drive some sort of alignment with your leadership if they need an engineer in the conversation in terms of ensuring that, okay, how long is the build time, is it worthwhile, can we support these set of features? If they need a technical perspective, I can definitely come in, but I cannot at all the time like have conversations with their leadership in areas that I'm not an expert in. So I found that like an unofficial PC group and allocated like certain set of responsibilities. Oh, we all agreed on like responsibilities that we would do in terms of convincing our skip managers and our managers. We had this like two-to-three-week period where we set up conversations with our managers, with our skip-level managers, and provided like the responses in like in terms of like how long would like the change management take place, how do we ensure that measurement was being taken care of in the appropriate, and uh, and to a large extent, is the leadership aligned from like the PMM and PM standpoint as well. So once we have all of these conversations put in place, to a large extent like leadership became like, okay, align to aspect of like, okay, it looks like bottoms-up feedback that we're getting is that this tool is going to be super useful. A, this is the measurement that has been set up in terms of like 10% reduction and like operational cost in terms of getting a product from like alpha to production launch—that's significant enough. Now, now the revenue aspect of things, we will probably need a long-term measurement, but we do have the data scientist on the team that are committed time as well. So to a large extent, we address these problems one by one from like a manager and from a leadership perspective, and that helps prioritize like the project. So this was one of those times where my manager agreed with terms of like, okay, these questions are concerns that have been raised have been addressed, so therefore, like this project is go—is good to go forward with. And to a large extent, my team also rallied behind the project in terms of ensuring that, okay, we are enthusiastic about like doing all of this like non-engineering work because from a senior man—like a senior engineering manager, senior engineer perspective, they were also interested in like gaining other projects, especially in terms of like excellent collaboration as well. And the final result was that yes, I mean the initial 10% reduction was realized within like a three-month period after the project was built, but the revenue impact was realized, I would say six months later on, and it was almost like I would say it increased revenue by 10% or $10 million specifically for these like early product launches that we wanted to do in terms of like how quickly do we identify advertisers, how quickly do we like measure revenue impact, how quickly are like these product bugs and iterations can be resolved. So to a large extent, it was more I would say the impact was more tangential rather than being like directly tied to the work, but like to a large extent like internal leadership was aligned—like for an internal tool, this was good enough.

Got it. Thank you. I really appreciate that. That's a really good overview of a the situation on the change management versus like the initial perspective on ROI. So if—if I followed, and please correct me if I'm wrong, it sounded like initially the disagreement between you and your manager was that your manager was pushing to prioritize projects based on ROI, but on the other hand you saw more, let's say, longer-term or better impact in change management and some of the processes around that. Is—is that right?

Yes, that's right. So it was more I would say from a manager's perspective they were optimizing for like, okay, what kind of impact that could be immediately realized that could—that would—that we would not wait for a longer period of time to realize the impact, but my—my stance was like, okay, this project from an ROI perspective, yes, it could take longer time to realize, but if you stack rank the project amongst like the other projects that are coming in, neither is this project lesser nor higher in priority. So therefore, like this project gives like a long—good exposure for my team, that is a big win when it helps them in the career development; that's a big win. And to a large extent, we have PCs from like the PMM and PM standpoint, so we have delegated work to ensure that we are not the ones that are driving this work as like the main owners, but rather we have peers that are driving work from there, and in terms of convincing their leadership as well. So like, to a large extent, this project could have not been prioritized as well; that could have been a result as well if the leadership from like the other teams were like, okay, this is not worth the time. And I prepared for that eventual scenario as well. It was more or less like, let's try to do this; let's try to see if the other teams are willing to put their cost upfront as well. If yes, this project is worthwhile; if not, then obviously, like I will agree with my manager and take on the project that does have like very clear ROI that has been defined.

Excellent. Yeah, that's great that you prepared for, let's say, the alternative or counterfactual ahead of time. Excellent. So, so maybe one or two follow-up questions here. You mentioned something really interesting that you shared some feedback with your manager where this feedback or data points were coming from others, and my question there is how did you solicit or get this feedback?

Oh, so the feedback uh process was twofold. So one, from a data scientist perspective, the feedback that I was getting in is like, is this tool useful, and how do we measure the impact of this tool? And that was the feedback I was getting them was like, okay, this is the hypothesis that we could go with, and this is how—how we can measure it. To a large extent, like this is a viable model of getting the information, so yes, that was one area that I was getting in. And the second one was like, we also had uh designers on the team who were conducting user research sessions with like the folks from like the PMM, PM, and engineering standpoint in terms of like, okay, let's assume that the work that you're doing flows into the centralized tool, what type of information would you provide, would it be useful, would it not be useful, what type of pain points would this address? So we had user research that also backed up—backed us up in terms of giving a data point that says that one, how do we measure the impact, here's the hypothesis, and here is how like we in—we intend on putting measurement in. The second piece was like, here is how the user research sessions that we've conducted is giving us very solid points in terms of saying that, okay, what type of features do we need to build, and how would these features help in like measurement tracking, and three, what type of realized impact would we see from a non-tangential aspect? It's more or less like, do the folks that got go—

Going to be using this tool, feel like they're comfortable doing the change management to use this tool, and that was what user feedback was giving us. Is like, yes, like let's assume that I have to go through like a month of like trainings to use this tool; I still feel like this this is a worthwhile investment of my time if the realized impact in terms of like reduction is actually viable. Excellent.

And just to kind of round that out a little bit too, is it fair to say that the, let's say, data science perspective from this feedback was maybe more internal facing, so like within your company, and the user research that you conducted was external?

Oh, so both of them were internal. So the user research, this was an internal field that we were building, so both of these were internal focused. But the types of feedback that we were getting from the two aspects was like one was more, uh, I would say, uh, in tangential to a large extent, it where pretty much I'm I'm blanking on the word, but rather like the sentiment from the users in terms of like, okay, let's assume that this tool is going to be used from from like a thousand users; let's do a survey with these thousand to figure out like, okay, will this tool be useful? Here is how like the they were marks that were presented to them in terms of like how the tool would flow. So we got like early signals from them like, okay, is this tool, first of all, is this tool going to be useful to you, and what feature sets would actually make this your life much easier? So that feedback is what user research is giving us. The data scientist was giving us, once this tool is launched, how do you measure the success of this tool? And that helps either like validate or invalidate the initial hypothesis that you have, so that like one. So if the initial question was like, you don't have any measurement for the folks that are going to be using this tool; do they feel like this tool is going to be useful? Yes, we have user research to back that up. Now the second question obviously is going to be like, once this tool is launched, how are you going to measure the success of this particular tool? We have this framework that's already ready, and this is how we intend on measuring the success of this particular tool. So yes, I mean, that that's, if you look at it like that's where the manager was coming from, is like there's a a lot of like assumptions being made in terms of like the usefulness of this tool versus like other projects where we know very clearly what the ROI is going to be. So that's where like it was more less like, do I give my team this, I would say, an ambiguous problem statement and ask them to solve for it, which is going to stretch them in like multiple different dimensions, or do I give them like a project where they know exactly what they need to do, which is going to help them definitely in like their career perspective, but it's not going to challenge them as much as like the ambiguous statement. Got it. Thank you.

And last follow-up question I I had in mind here, and by the way, this is an excellent review of the the feedback, and it sounds like you use this uh feedback to present it to your manager, which then helped out with some next steps. And my question there is, how did you surface or present this feedback to your manager? So, for example, that you send your manager an email with, "Hey, here's a bunch of data points from data science; here's a bunch of surveys from the research user group," or did you have a call with your manager or take them out to lunch? Like, how did you bring up this feedback to them?

Oh, so this was, so at least with my manager, it was more informal meetings where I was trying to gauge feedback in terms of like what type of questions am I getting; how do I address these set of questions? For it was more or less like, I would say, a coaching plus like feedback is how I was interacting with my manager because they were also understanding like, okay, this is a new area that uh he's dealing with, so we need to give give him like some sort of guidelines or a framework and how to think about this kind of work so that like they can grow more in the career. I think with the skip-level uh meetings, that was a more formal presentation where, based on all the questions that I had received from my manager, it was a more a presentation that addressed the set of questions in terms of like, okay, this is how we are engaging with like the designer team in terms of like doing mods and doing like user research sessions, and these are the types of feedbacks that we are getting. Here is the alignment process that we have with like the XFN folks in terms of ensuring that we can address the change management concerns that I've been having and from like, and the third slide basically talked about like, okay, in terms of long-term career growth, this is how like I would see like the senior managers on the team playing like critical roles. This is not going not only going to help help us with this particular project, but it also like for any future like Vision projects that we have in terms of pivots that we might do, you can now ensure that our team is now going to be more equipped to deal with like these more ambiguous type of situations. So uh, in short, it's like with my manager it was more informal conversations where it was both coaching plus like questions that I need to answer to get the project prioritized; with the skip, it was a very formal presentation where I answered like it was a presentation in terms of like how are we engaging with like XFNs, how are we like going to be like answering questions on the impact side, and how do we see this playing out in terms of like long-term career growth of like everyone on the team. Got it. All right, thank you. That that was comprehensive, and and I really uh appreciate that. So if you're open to it, let's go on to another uh question. Okay, so yeah, and I'll write it down here after I state it. So if you can tell me about a time that you needed to share a decision with your team that you disagreed with.

Yes, I think this ties in nicely to like your previous question on like the time that I disagreed with my manager. This was like the second piece where was we had a new project that was coming, and this project was called uh uh chat management with like external stakeholders. This was again like an ambiguous problem statement that was given to us was like, with the Advent of like large language models like towards like the mid of like previous year, one of the projects that was being spun up within the ad space was like, how do we now leverage these large language models to like at least do a pilot with like external like call center agents so that like they can leverage these chat center models to ensure that most common questions flow through through these like chat models first, and then you would only engage with like the call center agents as like a secondary piece, so like their time is freed up to do more proactive sets of goals. Now with this particular situation that was given to us, the task that was given to me specifically was like, okay, you need to now you you now have an XFN set of works; you have a business engineering team that works directly with like these call center agents; you have an internal support agent team that helps you identify what the common trends and what are the common issues are; and third, he has an ML engineering team that that will probably help you like train these models to answer like the common set of questions that have been asked or being identified by like the uh the support agent team. So with these three teams that with the task that was given to me was like, engage with these teams, try to figure out like how long would this project actually take care of, and now you also like get your team involved in like these early set of conversations so that like they can also like drive most of these conversations, and I'm also able to delegate these responsibilities. So the main thing was that we did like a three-month or actually yeah, it was like a three-month on and off engagement where we would think on like a weekly basis with like all the three stakeholders, try to figure out like, okay, which call center do we in towards and why do we like have specified this particular call center agent; try to identify the common set of trends that we've identified using with like the internal like chat support team; and the third was like engage with like the ML team to understand like, okay, how long would they need to take a they need to take like train a model; how do we ensure that we rate limit like any sort of request that are coming in; what type of computational cost that are we looking at so that like the cost don't suddenly balloon up to an extent where we are suddenly taking up too many resources from like Meta perspective. So all of these questions were being answered, and once there was a framework that was set up, I assigned my senior engineers to like take over these conversations while I was engaging with my manager and skip and reporting to them on the progress in terms of like, okay, these are like the major concerns that we are seeing in terms of computational costs; these are like the pros and cons of like approaches that we are taking; and to a large extent like this was a scenario where I was pretty excited, and the team was pretty excited in terms of engaging with this space, but this was a scenario where where all the feedback that we were getting mostly indicated that yes, this project would be successful if we implemented it well, but there was more risks of this project going not going the way that we expected, but we as a team were willing to take that particular risk. But this was again like where the manager and my skip were both in terms of saying that, okay, this is too high risk where you're not only talking about like a delayed impact in terms of ensuring that okay, you're going to do this initial pilot, then you're going to retrain the models, try to figure out like, okay, is this actually causing a reduction or is it causing causing an increase? Now if you're setting up call centers, especially in terms of expectations, it's very, I would say, contractual in terms of like, once you say that the chat model is going to at least give an assumption of like 10% reduction, they are going to pivot their call center agents to do something else, and if there's an increase in terms of like how much capacity a call center agent would actually need to provide in terms of answering these questions, the costs are going to balloon. So not only are the costs going to balloon in terms of like how long you actually train to retrain the models, but also in terms of risk in terms of what the company faces because you suddenly are now to a large extent trying to renegotiate the contract because the ML models are not functioning as I expected. So this was one of the reasons why we couldn't productionize the chat center model; neither could we actually go ahead with this particular product because of the fact of like a we were training like new models, and therefore we didn't have like a realized impact for it yet, and to a large extent you have contractual obligations which couldn't be modified if we needed to do any sort of last-minute pivots. So with this kind of like analysis that we found, the final result was that both my manager and skip were pretty much, I mean, it was a top-down like understandably in terms of like a decision that was passed on that said that, okay, we are not going to proceed with this project because of all of these particular risks; you will now need to communicate with your team. And this was a thing where I was very clear upfront with my team in terms of saying that, okay, this is a project that we're all passionate with, but the risk over here is the fact of like there's a lot of unknowns, and these unknowns not only impact like how we function but how Meta engages with like these call center agents as well, which is the reason why we need to stop this project. Now obviously folks were disappointed, and there were, I mean, the disappointment was more or less handled by me to be honest, but it wasn't a scenario where I expressed like this discontent at the decision, but rather I was like, this is a decision that I completely agree with, and the reason I agree with even though we put so much time into this is because of the fact of like it's contractual, and we cannot like pivot in these contractual obligations as quickly as we expect. So therefore like this project is going to be dropped for now, but it doesn't mean that we're not going to productionize it in the future; we are not going to be actively engaged with it, but the ML engineering team and the chat support team are still going to continue working with this project in terms of refining the model to ensure that there is at least to a large extent they can do some sort of internal testing to ensure that this model can answer like at least 10% of the questions that are going to be manually routed. Once they give us that confidence, we can probably like re-engage with this particular project, but on and off that doesn't mean that the folks on the team don't engage with the team. It's pretty much it's like you still have the option of like syncing with these folks, trying to understand like how the models are being built; you still have that particular set of freedom, but at the same time it's about balancing the time between like the projects that have been assigned to you versus like going with your interest, and this is where like so far like with the skip and the manager like we did have some sort of negotiation in terms of like, okay, folks can do still spend some time on understanding how these models are being trained because it's a brand new space, but they still would need to like prioritize the project that have been assigned, but we had some sort of like time commitment which rounded up to like 15% of a week's person time or or or a time in a week where they can engage with these folks to try to get their hands dirty with like model training as well. Excellent. Thank you. And that's a really great scenario that you described, uh especially very modern on the pros and cons of LLMs, especially when there's not only excitement but also some potential barriers as you mentioned with like contractual obligations and the cost of doing all of this. So so thanks for sharing that, and one or two follow-up questions also here. So one of them is, when you shared the let's say decision with your team that you that your team would no longer at the time be continuing with it, did you share this feedback first maybe with some uh or through some one-on-ones with your directs, or was it in like a standup or some sort of like weekly team meeting or email? I'm just curious how you communicated that.

Sure. Uh, so the first thing that I did even before communicating with my team was like phrase it out in my head and run it by my manager just to ensure that that there's not any sort of bias that was creeping in from my that either showed that I was pro this decision or like against this decision. So I did run it by my manager, and I did get feedback in terms of adjusting some language, but to a large extent once that messaging was like I would say it was free of bias, or at least I had like a I would say review that showed that okay, there was free of bias, then I shared it in like a stand-up meeting, like the weekly stand-up meeting that I have with my team where we discuss like what has happened like the previous week, what type of blockers are we experiencing, and what is it that each one is going to be doing for this week. That is where like I shared this particular update was like, okay, this is the finalization that has been reached for this particular project; the reason why we are not proceeding with this particular project is because of like the contractual obligations. Like everyone acknowledged like the disappointment in terms of like this is a hot new space; everyone wants to get like their experience in as quickly as possible before like processes are defined in terms of like which teams does what, but like the the main point that I wanted to highlight in the particular meeting was that like a there is an acknowledgement of the effort that has been put in; B everyone does acknowledge the space that is worthwhile the investment, but the reason we are not proceeding is because this is not an area that we can very quickly pivot if things go wrong, and that's the reason why we pulled that back on this project until we have a model that is ready enough to say with confidence that it's going to work for the situation and for the measurement that we intend to work. Once that is done, we can probably like re-engage with this particular project, but on and off that doesn't mean that the folks on the team don't engage with the team. It's pretty much it's like you still have the option of like syncing with these folks, trying to understand like how the models are being built; you still have that particular set of freedom, but at the same time it's about balancing the time between like the projects that have been assigned to you versus like going with your interest. And this is where like so far like with the skip and the manager like we did have some sort of negotiation in terms of like, okay, folks can do still spend some time on understanding how these models are being trained because it's a brand new space, but they still would need to like prioritize the project that have been assigned, but we had some sort of like time commitment which rounded up to like 15% of a week's person time or or or a time in a week where they can engage with these folks to try to get their hands dirty with like model training as well. Got it. Yeah, thank you. That makes a lot of sense to acknowledge the the efforts from the team but also add the context on the reason for the decision and how some of it your team could still keep in touch with and not, you know, completely leave it. That's that's great. Thank you. And maybe as a last follow-up to that question, when your skip and your manager essentially decided, right, for all these reasons, here's why this project will not continue at least for now, did they tell you, okay, now it's your turn to share this news with your team, or did one of them uh volunteer like, hey, if you want me to, I'll share this feedback with your team? Like how how did that go out, the decision that you would share the feedback with your team?

I say this was more like collaboratively. When we had the leads meeting, the option was given to me in terms of like, hey, do you want to share it or do you want like us to share it in like a team-wide session or all-hands session as to why we went to the decision? I felt like I like it would be better coming from me, and that's where like I volunteered that, okay, I will share this update with the team before they hear it in terms of like, oh, suddenly a decision has landed on them. So I wanted to soften the blow as much as possible, which is the reason why I like I volunteered that I would say like I volunteered to share the meeting; I'll share the update with my team in the meeting.

God, excellent. Thank you. Okay, so we have about 10 plus minutes or so, I think, for one more question, and again I'll I'll state it uh before I type it. And the question here is, um, has there been a time where some of your reports have directly asked you, what do I need to do to get promoted?

Yes, so I would say this I would say this was a situation back in 2020 when I recently got when I was became a manager in 2020, and one of the few questions that I had from like the high-performing engineers that I had on my team was like, Hey, given like it's the pandemic season and there's like a lot of unknowns in terms of like how performance is going to be like measured, like their main questions was like a I'm right now in like the yellow zone. Like there are zones defined for like different levels. For a level three engineer, they're expected to grow to a level four within two years; for a level four engineer, they're expected to grow to like level five within like two years. So you have like timelines that we defined and the

Concern that was raised from, like, two of my reports was that, okay, I'm currently in, like, the hello zone. And considering, like, this is the pandemic, and there's, like, a lot of projects that are in flux, and to a large extent, people have been trying to figure out, like, what the right work schedule would be. The main questions that were given to me was, like, given A, it's a pandemic; B, there's, like, a lot of personal things that are going on in people's lives; like, how is it that I can ensure that I can either get an exemption for the yellow zone, or how do I get promoted? And this was, like, the question was given to me as first as, like, a manager. So, to a large extent, I relied on, like, heavily on getting advice from my manager; like, I didn't—it was more or less, like, the main concerns were, like, how does—if I had to boil it down, the main concern here was, like, how is performance going to be measured? I think that's where the questions were coming from, even though it was being pointed to me as, like, how do I get promoted, or how do I get an exemption. At the bottom line, it was like, okay, how is performance going to be measured in this distressing time, and how is it, like, I need to prepare myself for any eventualities? That was, like, the two questions that were being asked, and to a large extent, that was being asked across the company as well.

And what I pretty much highlighted to my manager and my skip as well was, like, hey, this is the trend of questions that are coming in from my team. Main questions are around, like, A, performance measurement—how is that going to occur? Two, this is a distressing time for most folks on the team, so either you can expect a drop in productivity, or, like, projects need to be reassigned or reshuffled. Considering most of these things were being planned for in-person time, now that we are all remote, some of the projects that we're working on doesn't make sense anymore. How—how are you going to pivot about this? So, surfacing the feedback helped both the manager and skip understand, like, okay, this is a trend of questions that we are not only receiving from your team, but we are also receiving from, like, every team across, like, the uh—or so what we're going to do is, like, bubble the feedback up to, like, the VPs, and eventually up to, like, management. In terms of, like, trying to get to the—in terms of, like, in this extraordinary situation right now, how do we ensure that we at least have a path going forward for folks? So, like, not everyone is operating under—under the assumption that things are normal. Things are definitely not normal. So, so that's the de—or at least that's the conversation and updates that I was sending to my team on, like, a weekly basis, and during the one-on-ones. For that, okay, these conversations are now happening at, like, a VP level. I don't have visibility into, like, what exactly is going on, but at least the early indication seems to be that there might be some sort of exemptions that might be raised, or everyone will get, like, a meet-all, but these are, like, decisions that are not yet finalized, but this is how the conversation is going. So that, like, at least to a large extent, they were—they at least felt that, okay, even though my manager doesn't seem like cannot influence what the final decision is, at least I'm getting communication, and that helped especially during, like, the remote period that we were with.

And after, like, like a two or three-month period, the final addition was raised, like, Mark made the post that said that, okay, everyone's going to be getting a meet-all, so there's absolutely no concerns in terms of feedback they're going to be for folks, like, yellow zone, since everyone's getting a meet-all. Folks in yellow zone can't continue being at their existing level for until, like, the pandemic is over, so that means at least end of 2021, no one needs to worry about this. But it also doesn't mean that performance can degrade. It pretty much meant that for projects that are being assigned to you, unless you did extraordinary—which is where the manager comes in—as long as you're meeting all the expectations, you don't have to worry about anything right now. That they help, like, the team to a large extent, at least understand, like, okay, this is how I can plan my career forward. If I do extraordinary well, I'll still be rewarded, but as long as I meet the expectations, I do not have to worry about, like, any form of promotion. That I would say was, like, how I dealt with this particular, like, phase of, like, how do I get promoted that was happened during, like, 2020, to be honest. And I have a more recent example of this as well, where, like, the pandemic over—2023, there's a new engineer that was assigned to me, and the question was pretty much was, like, okay, I'm currently in L3, how do I get promoted? Can I get a promotion within the six-month period? This was a more direct point. I can go into this if you feel like if—if you have enough time over here, but I want to get your thoughts before I tackle that scenario. Yeah, thank you. So—so maybe two thoughts here. Uh, one is that's really excellent context on the pandemic and how the pandemic influenced some of the subtext of the question, right? How do I get promoted? And you teased out or discovered that, you know, a lot of it was on the overall uncertainty, right? Not necessarily on specific individual's performance, but on the kind of larger state of things. And—and so, yeah, that—that really helps in that context for sure, and how you addressed it. But uh, yeah, I think to maybe compliment that, it would be good to maybe get a 3 to 5-minute or so summary on the more recent individual that asked you—um, if you're open to it—um, kind of summarizing that situation.

Oh, yes, definitely. Yeah, so this was a brand new engineer that joined the team uh in March of this year, and I was assigned this particular engineer, and that was pretty much the open question over there was, like, they were ambitious, as expected from, like, a young person, and the question that was posed to me was, like, okay, I'm a brand new engineer, I'm excited to go—I'm aiming for a promotion, like, within a six-month period, so what is it that I can do to get promoted, like, a six-month period? And—and—and to a large extent, the way that I handled this particular conversation was, like, A, giving a very realistic scenario of, like, how PSC actually works at Meta, and especially the context, analyze sustained impact. So what I told him was, like, okay, okay, let's assume that you're aiming for a promotion within a six-month period. I would say that's definitely not possible; like, that's an expectation that I'm setting up front, in terms of, like, saying that whether it's possible or not, that's definitely not possible. Now, is that a reflection on your performance or your caliber as an engineer? It's definitely not. It's mostly how, like, PSC at Meta is being designed over here is that we are not looking at, like, short-term impact for, like, folks to suddenly show a sudden spike in impact and sudden reduction impact over, like, the previous cycles. That is not what we're looking at, but rather the philosophy over here is lagging promotion where we—we are giving you projects that are at your level currently. If you perform well, then you're given more challenging projects that help you stretch your, like, expectations to, like, the next level. And once you show that you are able to do this set of, like, projects, you'll be given more and more challenging projects that helps not only, like, me, but also the other engineers, engineering managers within the—or understand what capability and what type of projects that you're working at, and this is how your setup will be. In terms of, like, okay, within the first three months, this is how the type of projects that I'll be giving to you that has, like, tasks that are given at a detail level, and you are expected to, like, execute on time for these set of tasks. And after that, next three-month period is where you'll be given, like, more ambiguous problems that are not too ambiguous at, like, a level five level, but rather what the expectation would be that you be given a particular task without the details and expected you to now fill out, like, how you go about accomplishing this particular task for a single project. That behavior will help us understand, like, are you able to take on, like, more and more ambiguous set of problems here? Are the level three and level four expectations that are transparently provided, like, in the internal wiki so that, like, you can also have a mental model in terms of, like, how you need to function. And once you do this, you'll be given more projects where you're given exposure to other team members as—as well, so that, like, not only me, but you also get peer feedback that helps back up the behaviors that we expect from a level four. And all of this cannot be realized within a six-month period because most folks require at least, like, 8 to 9-month period. That's the average that we expect, and once you have shown this sustained level of impact, it's not only my word that people need to take for, but there's also, like, the peer feedback that you're getting. All of this will help you get to a level four within, like, realistically, like, a year worth of time, and it's not going to be a six-month period of time. So that's how I handled this particular conversation was, like, A, very clearly setting expectations up front, and B, describing the process in terms of, like, how I intend to, like, manage the—a career in a long-term perspective, and also how I expect them to perform on, like, a three to four-month period. I did also provide, like, there are exceptions to this. Let's assume that within the three-month period you're not only able to knock off all the projects off, but you're also proactively asking for team members in terms of, like, getting more complex projects. That's a good signal that we're sending that, okay, this person is capable of handling more and more, and once that happens, there is a scenario that within the eight-period I'm getting questions from other engineering managers on, like, oh, this person at—who's at a level three is being able to handle that, like, level four projects, like, I think we should be able to give him a promotion. That is a perfect signal for me to, like, give put forward a promotion. So, one is me preparing a case for your promotion; two, you displaying the qualities eloquently to, like, other engineering managers where I'm getting questions as to why, like, we are not putting you up for promotion. That is a more stretch goal for you, but that—that has definitely happened, but I would say aim for, like, what is it manageable, and definitely if you feel like you can stretch yourself, you're more than welcome to stretch yourself where you give me a plan, and we can work towards that as well. So I did provide the two processes, like, what an exceptional performance looks like and what the normal performance looks like, gave the person the option in terms of, like, what part would they like to choose, and, like, we can adapt to it as and when, like, we go through it. The end result was that, okay, for the—it was, like, within a year's time he was able to show sustained impact, and we did give him a promotion, to be honest. That was, like, the plan that we agreed upon, and that's the plan that we're working towards right now. He's on track for a promotion because he joined March, by end of this year he's, like, sustaining impact, so I'm putting him for promotion for, like, February of next year.

Excellent. That's—that's good news. And have you communicated to this person, like, hey, I'm getting the promotion package ready for you, or is it more standard maybe in your philosophy or at your company to maybe not disclose that information and only tell the individual if it goes completely through? All at the idea is that we give them a promotion package and we tell them that, okay, this is now currently being reviewed with the others, but what we cannot guarantee is that the promotion is going through. It's more or less, like, you're being put up for promotion. Excellent. Okay, so we've got about five or six minutes, and if you're okay with it, I'd like to spend—well, maybe three to four minutes on my own initial feedback, and then in the last minute or two, some comments. I do have a hard stop, but I think we made really good progress on the questions, so—so yeah, if you're open to it, I'll—I'll start with some of my own uh comments here. Yeah, yeah, that would be super useful. Thank you. Great. Yeah, so—so overall, overall, I thought you did uh really well. You answered all the questions, you stuck with STAR, and you interspersed good, in my opinion, leadership and delegation. So that's initial uh high level, and just some things I might—I suppose maybe call them nitpicks, right? Sometimes these nitpicks are interviewer dependent, but one that comes to mind is on uh let's say setting some of the trust-building relationship with uh your direct reports and maybe some of your um interactions with your manager, skip. So one example, ex—like, the last question that I asked uh is slightly loaded, but it—it does come up, right? When people ask, how do I get promoted? The nitpick here is that if you wanted to, you could lean a little bit on the beginning on saying things like, hey, it's a fair question, but the risk that we sometimes run as managers is having a very transactional relationship with our directs, meaning uh the direct says or asks, like, give me a list of todos, manager provides a todos, they do them, and it's done. That's sometimes, like, the coin machine model, which is sometimes called for maybe on some projects, but sometimes as managers for longer term, right? If this is going to be a direct that you can hopefully build trust with and count on in tricky situations, getting to know them a little bit more as a person and translating the question a little bit to say, you know, hey, direct, I understand you want to get promoted, but maybe the right question is what can you do to help me and to help the team, right? Because then it starts becoming something more like a proactive seed that you're planting in the direct's mind, right? Like, come to me, sure, if you have some questions, but if you're not always expecting me to give you a list of todos, then that direct might eventually start thinking a little bit more independently, like, oh, okay, my first priority is to help my manager and the team, like, what can I do, right? What can I um build, or how can I get answers to questions on my own, things like this. Uh, does that sort of make sense? I hope I articulated some of that correctly.

Oh, it does. It's more or less, like, phrasing it rather than saying that, okay, you're not going to get promoted within the six-month period. It's phrasing it more in ter—okay, like that's a valid question, is the person's question, rather than dismissing it, and then ensure that you have a path forward in terms of, like, giving them a mental model in terms of, like, this is how we think about this. If you start thinking about this more naturally, this is going to help you get promoted without you actually thinking about it. It's going to be a natural part of your progression in—in the company. Exactly. Exactly. Because then you start resolving the tricky thing of transaction-based, like, growth mindset. Um, yeah. And the other nitpick I would have is you brought up really good situations where your manager or skip was involved, and something that might help is emphasizing here and there a little bit how you specifically interacted with them to say, like, oh, you know, this manager and I—we have really good and informable conversations over lunch, so I waited for the next time that we had lunch to approach this or that topic, or my manager and I tend to communicate really well, I don't know, over a video call, and that's our—our preferred format, so I waited for the next time for that opportunity to come up. Something that tells the interviewer a little bit about your day-to-day and how you interact with people. Uh, certainly it's okay to start a little bit abstractly and said, hey, they communicated with me, and I communicated with them. That's perfectly fine, but if you can add some of those kind of human touch details, um, this might also help in some of the behavioral—this is super—and yeah, yeah, of course. And yeah, I apologize, we're near time, so I do have one or two more minutes if you have, let's say, one comment or one question for me.

I mean, nothing to be honest, like, all of these questions were things that I don't think I've gotten before, but I think uh I think the clarification that you—was very clear. It's like, when you're saying that you're going to interact with someone, just clarify, like, give context in terms of saying that, okay, I set up, like, a weekly one-on-one with my manager to discuss, like, in general, like how projects are going along, and these—in these meetings is where, like, I thought up, like, the project status and how we need to engage with, like, external and folks, and this is where this served as, like, my primary means of, like, getting feedback from my manager, and this is where, like, we also made a—of, like, okay, this—okay for me to, like, get my skip involved, get feedback from them, and then, like, we can proceed forward in terms of, like, how this project needs to be prioritized. Yeah, absolutely. And that kind of human touch thing might also be a little bit company or team dependent, but it—it definitely helps give some more context as to maybe helping your interviewer feel like, boy, I would be really excited to work with this person because they're paying attention, like, how to best interact, right? Phone call, lunch, etc. So—so again, those were uh nitpicks, but uh I think you did uh well, and yeah, it was a privilege to speak with you. Thanks for the interview today. Oh, thank you, and it was a privilege speaking with you as well, and I really appreciate the questions and the feedback that you—for waiting. Excellent. All right, well, thanks again, and uh yeah, have a good rest of the day. He