We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free
An Interview with a FAANG engineer
Watch someone solve the tech lead behavioral questions problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.
Interview Summary
Problem type
Tech Lead Behavioral Questions
Interview question
1. Time that disagreed with a manager 2. Time when you needed to share a decision with your team that you disagreed with? 3. Time some of your reports asked directly 'How do I get promoted'?
Interview Feedback
Feedback about Utilitarian Lemur (the interviewee)
Advance this person to the next round?
YesHow were their technical skills?
4/4
How was their problem solving ability?
4/4
What about their communication ability?
3/4
It was a privilege to work with you today on an L6+ Behavioral round. I thought you did quite well overall and might score as 8/10. Feedback I've received is that I'm "too lenient" on this platform sometimes so if I had to be pickier, 7/10; but overall 'yes' to proceed; hence the 4/5 stars "Communication". Strengths - Clear leadership signals on how you navigated tricky situations e.g. when you and manager disagreed on what to initially prioritize - Good signals on delegation -- Would recommend to add why you specifically picked other managers/engineers to help with projects - Overall good STAR communication -- Scenario descriptions organically sounded natural from experience - Active and good listener -- Very receptive to follow-up questions and being candid about pertinent details such as team sizes, business priority, and overall impact - Comfortable with conflict -- E.g. when a project was deemed risky, you navigated grey areas without being combative and were ablet to deliver news on something you disagreed with (project continuance) -- Comfortable in resolving ambiguity instead of simply navigating around it Potential areas of improvement: - More linear structured communication -- Maybe a nit but sometimes important context would come up during the "Action" part of STAR which could instead be part of "Situation" -- E.g. when clarifying and highlighting ROI vs change mgt in first example - From time to time pause and ask interviewer if you've answered their question or if they have follow-ups - Elaborate a little more on key points of why there was risk/conflict/disagreement -- E.g. when manager and skip labeled a project as too "risky", spend a few seconds on describing why they found it risky and (ideally) how you could see their point of view -- Elaborating on why you understood their point of view came a little bit later in your narrative, so this may also be a "nit" - Fostering growth in direct reports -- We touched on it at end but you could elaborate more on the promotion path as being an opportunity to mentor others so that they have the team's best interest in mind and gain independence -- Depending on the company you're interviewing at being potentially "transactional" with direct reports can be a pro/con Resources: - Follow Ethan Evans on LinkedIn - "Leadership and self-deception", Arbinger Institute Open notes: Copying from my text inputs from beginning Tech lead manager M1 General: - Respectful - Collaborative - Proactive - Results oriented Tips: - Follow STAR - Be prepared but not robotically rehearsed L6+: - Delegate (dividing work with others above/below) - Scalability of work (distribute vs 1:1) - Comfortable with conflict (understanding of other side and long-term "win-win") - Managing up: how you've influenced leadership
Feedback about Stochastic Panda (the interviewer)
Would you want to work with this person?
YesHow excited would you be to work with them?
3/4
How good were the questions?
4/4
How helpful was your interviewer in guiding you to the solution(s)?
4/4
Interview Transcript
Stochastic Panda: Hi. How are you doing?
Utilitarian Lemur: I'm doing good. How are you doing?
Stochastic Panda: I'm doing well also, so thank you for joining today, and please let me know if there's any audio issues on my side. I do have some backup headphones, et cetera. Great. 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 l six plus role, is that right?
Utilitarian Lemur: That's correct.
Stochastic Panda: Excellent. 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 l seven or like a Facebook e six or e seven or a Microsoft l 67, something like this?
Utilitarian Lemur: So I'm interviewing for a role at TikTok, a tech lead manager role. My assumption is that it's similar to like an M one in meta.
Stochastic Panda: Got it. And in terms of title, would that be like a senior manager?
Utilitarian Lemur: Oh, no, it's just called tech lead manager.
Stochastic Panda: Okay, great. Excellent. So that is helpful. Tech lead manager, m one. All right, I think that's great. So for today, 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 I O side, I'll also give some brief tips and kind of expectations. And then we'll go into the main interview at latest by the ten 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?
Utilitarian Lemur: Yeah, that sounds like a perfect plan.
Stochastic Panda: Fantastic. So for the intros, would 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.
Utilitarian Lemur: Sure, yeah, I can get started. So I'm currently an m one at 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 three years I've been like an engineering manager. It's only in the past four to five months I've been in the privacy space, and before that I've been in the sales and ad space for almost twelve years now. Great.
Stochastic Panda: Okay, that is excellent experience. Thank you. All right, so from my side, let's see. So I met one of the larger tech companies in the Pacific Northwest, headquartered there years of experience about nine or ten. I've mostly been so called IC or individual contributor, but in the last four years or so, have been leading more and more people over time. And what else? Yeah, I've been on this site for some time now. IO and. Great. That's brief about me. And also, if you're familiar with this I O site, sometimes we do use the text editor, but for most behavioral culture interviews, it's mostly dialogue. So just pointing that 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 clarification. 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 may already know, of course. And on the respectful side. Yeah, we're always looking for is a person mutually respectful, great to work with, collaborative with others, proactive. That's one thing. Of course, 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 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?
Utilitarian Lemur: Yes, it does.
Stochastic Panda: Excellent. And also the star method, are you familiar with that acronym?
Utilitarian Lemur: Oh, yes. 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 the respectful, collaborative, proactive, results oriented. But the idea is that you stick to this so that you are playing 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 the result?
Stochastic Panda: Fantastic. Yes. And that's great. Yes, on the result. Yes. How you drove the result and what the result was.
Utilitarian Lemur: That's perfect.
Stochastic Panda: Excellent. Thank you. Okay. And for l six plus, something that I will also note, 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, sharing your 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 like robotically rehearsed right. We want to get the sense of, yeah, that person has it top of their mind, but they're really telling me the story, not reading from a script. Okay. Now for l six plus, there's, I would say, four additional areas that are sometimes good to touch in. 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. 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 conflict. Right. Understanding the other side and how you maybe still built 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 executive level, is managing up like how you've effectively influenced leadership, might be on a whole new project or changing course on something that was baked in for a few years. Great. So we're doing well on time. We're near the ten minute mark. But any questions overall here?
Utilitarian Lemur: No questions so far.
Stochastic Panda: Fantastic. All right, so let's get started with one question for today. Can you tell me about a time that you disagreed with your manager?
Utilitarian Lemur: 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 we're in. So the context over here is there's a project that was called as growth plans, where we were working with product marketing managers to figure out how we can optimize their outbound workflow. And the idea behind this is that product marketing managers talk to product managers and 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 roadmapping 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 roadmap to get this project onboarded or offloaded based on what the relative prioritization is. Now, one of the first steps that I took was consulted with a data scientist to understand, okay, for a particular project intact that optimizes processes, how do we need to measure the success of these set of projects, what kind of prerequisites that are required, and how do we measure previous and pre implementation and post implementation so that there could be a good story that could be attached and that can be presented to leadership in the roadmapping session. Now, once this task was given to me, I engaged with the data scientists, I engaged with the product marketing team, and also to a large extent engaged with the engineering managers because most often they're not. Their entire workflow was done to tasks, whereas most of the product managers work and product marketing managers work were being done to Google Docs. So you have this disconnect in terms of understanding, how do we tie in two different workflows without overtly burdening engineers with 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 drive three particular things. One, there'd be a 10% reduction in overall time to market for any new product that was in like alpha beta and production launch. But the con was that you had to do a change management in the product marketing and product manager departments. Now this is where to a large extent, my manager was pushing back on me, pretty much saying that, okay, the 10% reduction looks fine, but the change management aspect of things where you need to influence an entire to onboard onto this tool seems unreasonably complicated. So therefore we need to reprioritize this project in favor of another project. Now, to a large extent, this agreement was stemming from the fact of one, there was a huge amount of time investment that was involved, that would have been involved in convincing leadership on the product marketing and product marketing managers teams to ensure that they were on board. In terms of why this tool needs to be built out, how the change management should occur, what does that entail in terms of training for these set of people? So that was one particular major, I would say areas of disagreement between me and my manager was like, okay, I felt like this was a project where we have that impact that is not being questioned, but rather the change management of things being questioned, like how do we handle this? It's like a too big of a process to be handled by an engineering team, which I understood. 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. Let's assume that if it takes three months to do change management, even if you build a tool at end time, it might take like n plus three time for you to even start realizing the impact of stuff. So especially if you look at a short timeline of six months or like a yearly review, how do we go about 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 project, it might give you the right set of Roi. Now, the feedback from my team was that they felt like this particular growth trends project, which even though it had the challenge of change management, they were very interested in pursuing this. 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 the impact that is going to be realized. The new project that is going to be provided to us was to a large extent, 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 talking to stakeholders, trying to figure out, okay, if you have to build a tool where you needed to do change management perspective, how can you do that more effortlessly? What kind of intermediately tools or processes could you entail or build to ensure that people who are just using Google Docs could use the new tool as seamlessly as possible? Or how can we ensure that their existing workflows have tied to seamlessly into the tool? So all of these were interesting challenges, especially on the senior engineers on my team were interested in. So to a large extent, the main things that I did was speak with my manager, told them the areas where I disagreed with him, and also backed it up with statements from my team and the stakeholders in terms of how they could potentially reduce the change management friction that was bought in. From my manager's perspective, my manager understood the pitch that I was trying to bring in from, but he was also on the fence in terms of like, okay, is this a worthwhile project to go with? So what I did was, with his permission, I spoke to the skip from my, I spoke to the skip on the PMM and PMR, and I also delegated some of the responsibilities to the PoCs 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 have conversations with their leadership in areas that I'm not an expert in. So I found an official POC group and allocated certain set of responsibilities. Oh, we all agreed on responsibilities that we would do in terms of convincing our skip managers and our managers. We had this two to three week period where we set up conversations with our managers, with our skip line managers, and provided responses in terms of how long would the change management take place, how do we ensure that measurement was being taken care of in the appropriate manner? And to a large extent, is the leadership aligned from the PMM and PM standpoint as well. So once we have all of these conversations put in place, to a large extent, like leadership boss like okay, aligned to an aspect of like, okay, it looks like bottoms up feedback that we are 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 in operational cost, in terms of getting a product from alpha to production launch. That's significant enough. Now, the revenue aspect of things, we will probably need a long term measurement, but we do have the data scientists on the team that have committed time as well. So to a large extent, we address these problems one by one from like, a manager and from a leader perspective, and that helps prioritize the project. So this was one of those times where my manager agreed with terms of like, okay, these questions or concerns that have been raised have been addressed. So therefore, this project 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 doing all of this non engineering work because from a senior engineering manager, senior engineer's perspective, they were also interested in gaining other projects, especially in terms of excess and collaboration. And the final result was that 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 early product launches that we wanted to do in terms of how quickly do we identify advertisers, how quickly do we measure revenue impact, how quickly these product bugs and iterations can be resolved. So to a large extent, it was more, I would say the revenue impact was more tangential rather than being directly tied to the work. But to a large extent, internal leadership was aligned. Like for an internal tool, this was good enough.
Stochastic Panda: Got it. Thank you. I really appreciate that. That's a really good overview of the situation on the change management versus the initial perspective on ROI. So 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 that right?
Utilitarian Lemur: 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 we would not wait for a longer period of time to realize the impact. But 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 the other projects that are coming in, neither is this project lesser nor higher in priority. So therefore this project gives a long, good exposure for my team. That is a big win. It helps them in the career development. That's a big win. And to a large extent we have pocs from the PMM and PM standpoint. So we have delegated work to ensure that we are not the ones that are driving this work as the main owners, but rather we have peers that are driving work from there and in terms of convincing their leadership as well. So 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 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 up front as well. If yes, this project is worthwhile. If not, then obviously I will agree with my manager, enter and take on the project that does have very clear ROI that has been defined as well.
Stochastic Panda: Excellent. Yeah, that's great. That you prepared for, let's say, the alternative or counterfactual ahead of time. Excellent. 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?
Utilitarian Lemur: So the feedback 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 then was like, okay, this is the hypothesis that we could go with and this is how we can measure it. To a large extent, 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 designers on the team who were conducting user research sessions with the folks run 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 us up in terms of giving a data point that says that one, how do we measure the impact? Here is the hypothesis and here is how 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 measurement tracking? And three, what type of realized impact would we see from a nontangible aspect? It's more or less like, do the folks that going to be using this tool feel like they are comfortable doing the change management to use this tool? And that was what user feedback was giving us is like, yes, let's assume that I have to go through a month of trainings to use this tool. I still feel like this is a worthwhile investment of my time if the realized impact in terms of reduction is actually viable.
Stochastic Panda: Excellent. And just to kind of round that out a little bit too, is, 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.
Utilitarian Lemur: So both of them were internal. So the user research, this was an internal that we were building. So both of these were internal focused. But the types of feedback that we were getting from the two aspect was like, one was more, I would say intangible to a large extent. Pretty much I'm blanking on the world, 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 1000 users. Let's do a survey with these thousand to figure out, okay, will this tool be useful? Here is how there were mocks that were presented to them in terms of how the tool would flow. So we got early signals from them like, okay, 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 resource 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 validate or invalidate the initial hypothesis that you have. So 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 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, if you look at it, that's where the manager was coming from, is there's a lot of assumptions being made in terms of the usefulness of this tool versus other projects where we know very clearly what the ROI is going to be. So that's where it was more or 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 multiple different dimensions, or do I give them a project where they know exactly what they need to do, which is going to help them definitely in their career perspective, but it's not going to challenge them as much as the ambiguous problem statement that we were dealing with.
Stochastic Panda: Got it. Thank you. And last follow up question I had in mind here, and by the way, this is an excellent review of the feedback, and it sounds like you use this 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, did 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? How did you bring up this feedback to them?
Utilitarian Lemur: At least with my manager it was more informal meetings where I was trying to gauge feedback in terms of what type of questions am I getting, how do I address these set of questions? It was more or less like, I would say a coaching plus feedback is how I was interacting with my manager because they were also understanding, like, okay, this is a new area that he's dealing with, so we need to give him some sort of guidelines or a framework on how to think about this kind of work so that they can grow more in their career. I think with the skip level meetings, that was a more formal presentation where based on all the questions that I had received from my manager, it was more a presentation that addressed the set of questions in terms of like, okay, this is how we are engaging with the designer team in terms of doing mocks and doing user research sessions. And these are the types of feedbacks that we are getting. Here is the alignment process that we have with the XFN folks in terms of ensuring that we can address the change management concerns that I've been having. And the third slide basically talked about, okay, in terms of long term career growth, this is how I would see the senior managers on the team playing critical roles. This is not only going to help us with this particular project, but it also for any future 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 these more ambiguous type of statements as well. So in short, it's like with my manager, it was more informal conversations where it was both coaching plus questions that I need to answer to get the project prioritized. With the skip, it was a very formal presentation where it was a presentation in terms of how are we engaging with xfns, how are we going to be answering questions on the impact side, and how do we see this playing out in terms of long term career growth of everyone on the team?
Stochastic Panda: Got it. All right, thank you. That was comprehensive and I really appreciate that. So if you're open to it, let's go on to another question. Okay. 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.
Utilitarian Lemur: Yes. I think this ties in nicely to your previous question. On the time that I disagreed with my manager, this was like the second piece where we had a new project that was come in and this project was called chat management with external stakeholders. This was again like an ambiguous problem statement that was given to us was like with the advent of large language models towards the mid of 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 at least do a pilot with external call center agents so that they can leverage these chat center models to ensure that most common questions flow through these chat models first, and then you would only engage with the call center agents as like a secondary piece so that their time is freed up to do more proactive set of calls. Now, with this particular situation that was given to us, the task that was given to me specifically was like, okay, you now have an excellent set of folks. You have a business engineering team that works directly with 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, here's an ML engineering team that will probably help you train these models to answer the common set of questions that have been asked or being identified by the support agent team. So, with these three teams, with, the task that was given to me was like, engage with these teams, try to figure out how long would this project actually take care of? And now you also get your team involved in these early set of conversations so that they can also 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 it was like a three month on and off engagement where we would sync on a weekly basis with all the three stakeholders. Try to figure out, okay, which call center do we aim towards and why do we have specified this particular call center agent? Try to identify the common set of trends that we've identified using with the internal chat support team. And the third was engage with the ML team to understand, okay, how long would they need to take? They need to take trainer model. How do we ensure that we rate limit any sort of requests that are coming in? What type of computational cost are we looking at so that the cost don't suddenly balloon up to an extent where we are suddenly taking up too many resources from a metas 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 take over these conversations while I was engaging with my manager and skip and reporting to them on the progress. In terms of, okay, these are the major concerns that we are seeing in terms of computational cost. These are the pros and cons of approaches that we are taking in. And to a large extent, 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 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 was both in terms of saying that, okay, this is too higher risk, where you're not only talking about a delayed impact, in terms of ensuring that, okay, you're going to do this initial pilot, then you're going to retrain the model, try to figure out, like, okay, is this actually causing a reduction or is it causing an increase? Now, if you are setting up call centers, especially in terms of expectations, it's very, I would say contractual. In terms of like, once you say that this 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 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 how long you actually take 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 amount 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 a, we were training like new models and therefore we didn't have 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 analysis that we found, the final result was that both my manager and skip were pretty much, I mean, it was a top stone, understandably, in terms of addition 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 there's a lot of unknowns, and these unknowns not only impact how we function, but how meta engages with 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 discontent at the Dashian, 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 it's contractual and we cannot pivot in these contractual obligations as quickly as we expect. So therefore this project is going to be dropped for now. But it doesn't mean that we are 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 reengage with them in terms of building the system end to end. That I would say was like, the final result that was driven was like, we will still continue with the model, but it won't be our team that's directly engaged with it. But the other two exceptions, while we pivot ourselves to the other project that have clear ROI and defined, and to a large extent, if there are ambiguous problem statements that could be defined as well, we will try to prioritize it. But that was like pretty much the nation that we all arrived at.
Stochastic Panda: Excellent. Thank you. And that's a really great scenario that you described, 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 contractual obligations and the cost of doing all of this. 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 your team would no longer at the time be continuing with it. Did you share this feedback first, maybe with some, or through some one on ones with your directs, or was it in a stand up or some sort of weekly team meeting or email? I'm just curious how you communicated that.
Utilitarian Lemur: Sure. So the first thing that I did even before communicating with my team was phrase it out in my head and run it by my manager just to ensure that there's not any sort of bias that was creeping in from my end that either showed that I was pro this decision or against this sedation. 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, I would say, review that showed that, okay, it was free of bias. Then I shared it in a stand up meeting, like the weekly stand up meeting that I have with my team, where we discuss 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 I shared this particular update was like, okay, this is the final ration that has been reached for this particular project. The reason why we are not proceeding with this particular project is because of the contractual obligations. Everyone acknowledges the disappointment in terms of this is a hot new space everyone wants to get their experience in as quickly as possible before processes are defined in terms of which teams does what. But the main point that I wanted to highlight in the particular meeting was that, a, there is an acknowledgment 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 a pack 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 reengage 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 like you still have the option of syncing with these folks, trying to understand 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 the projects that have been assigned to you versus going with your interest. And this is where, to a large extent, with the skip and the manager, 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 prioritize the projects that have been assigned. But we had some sort of time commitments which rounded up to like 15% of a week's percent time, or a time in a week where they can engage with these folks to try to get their hands dirty with model training as well.
Stochastic Panda: Got it? Yeah. Thank you. That makes a lot of sense to acknowledge 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 completely leave it. 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 volunteer, like, hey, if you want me to all share this feedback with your team, how did that go about the decision that you would share the feedback with your team?
Utilitarian Lemur: I would 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 us to share it in a team wide session or our wide session as to why we went with the. I felt like it would be better coming from me, and that's where I volunteer that, okay, I will share this update with the team before they hear it. In terms of like, oh, suddenly a decision is landed on them. So I wanted to soften the blow as much as possible, which is the reason why I volunteer. I would say I volunteer to share the meeting. Share the decision with my team in the meeting. Got it.
Stochastic Panda: Excellent. Thank you. Okay, so we have about ten plus minutes or so, I think, for one more question. And again, I'll state it before I type it. And the question here is, has there been a time where some of your reports have directly asked you, what do I need to do to get promoted?
Utilitarian Lemur: Yes. So I would say this was a situation back in 2020 when I recently got. When I became a manager in 2021, of the few questions that I had from the high performing engineers that I had on my team was like, hey, given that it's the pandemic season and there's a lot of unknowns in terms of how performance is going to be measured, their main questions was like a, I'm right now in the yellow zone. There are zones that. The context for here is that there are zones defined for 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 level five within two years. So you have these timelines that were defined, and the concern that was raised from two of my reports was that, okay, I'm currently in the yellow zone, and considering this is the pandemic. And there's a lot of projects that are in flux. And to a large extent, people have been trying to figure out what their right work schedule would be. The main questions that were given to me was like, given a, it's a pandemic, b, there are a lot of personal things that are going on in people's 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 that was given to me as first as a manager. So to a large extent, I relied on heavily on getting advice from my manager. It was more or less like the main concerns were like, 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? 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 are working on doesn't make sense anymore. How are you going to pivot about this? So servicing this feedback help 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 every team across the. So what we're going to do is bubble feedback up to the vps and eventually up to mark in terms of trying to get to Daeshan. In terms of in this extraordinary situation right now, how do we ensure that we at least have a path going forward for folks? So not everyone is operating under the assumption that things are normal. Things are definitely not normal. So that's the nation, or at least that's the conversation and updates that I was sending to my team on a weekly basis. And during the one on one was that okay? These conversations are now happening at a vp level. I don't have visibility into 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 meat solve. But these are like decisions that are not yet finalized. But this is how the conversation is going. So at least to a large extent, they at least felt that, okay, even though my manager doesn't seem cannot influence what the final decision is, at least I'm getting communication. And that helped, especially during the remote period that we were with. And after a two or three month period, finally a decision was raised. Like Mark made the post that said that, okay, everyone's going to getting a meets all. So there's absolutely no concerns in terms of feedback. They're going to be for folks that are in like a yellow zone. Since everyone's getting a meets, all folks in yellow zone can continue being at their existing level until the pandemic is over. So that means that 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 decision helped 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 aiming for my promotion. That I would say was like how I dealt with this particular phase of how do I get promoted? That was happened during 2020, to be honest. And I have a more recent example of this as well, where the pandemic is 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 l three. How do I get promoted? Can I get a promotion within the six months? This was a more direct point. I can go into this, but if you feel like, if we have enough time over here, but I wanted to get your thoughts before I tackle that scenario.
Stochastic Panda: Yeah, thank you. So maybe two thoughts here. 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 a lot of it was on the overall uncertainty, right? Not necessarily on specific individuals performance, but on the kind of larger state of things. And so, yeah, that really helps in that context, for sure, and how you addressed it. But yeah, I think to maybe complement that, it would be good to maybe get a three to five minute or so summary on the more recent individual that asked you if you're open to it on kind of summarizing that situation.
Utilitarian Lemur: Oh, yes, definitely. So this was a brand new engineer that joined the team 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 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 to a large extent, the way that I handled this particular conversation was like a giving a very realistic scenario of how PSE actually works at meta and especially the context around sustained impact. So what I told him was like, okay, let's assume that you're aiming for a promotion within six months period. I would say that's definitely not possible. That's an expectation that I'm setting up front in terms of 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 Plc at meta is being designed over here is that we are not looking at short term impact. For folks to suddenly show a sudden spike in impact and sudden reduction impact over the previous half, that is not what we are looking at, but rather the philosophy over here is lagging promotion, where we are giving you projects that are at your level currently. If you perform well, then you're giving more challenging projects that help you stretch your expectations to the next level. And once you saw that you are able to do this set of project, you'll be given more and more challenging projects. That helps not only like me, but also the other engineering managers within the 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 tasks that are given at a detailed level and you are expected to execute on time for these set of tasks after that next three months period is where you'll be given more ambiguous problems that are not too ambiguous at a level five level, but rather what the expectation would be that you'll be given a particular task without the details and expected you to now fill out how you go about accomplishing this particular task for a single project. That behavior will help us understand are you able to take on more and more ambiguous set of problems. Here are the level three and level four expectations that are transparently provided in the internal wiki so that you can also have a mental model in terms of 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 well. So that 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 eight to nine 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 really getting. All of this will help you get to a level four within realistically, like a year's 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 upfront and b describing the process in terms of how I intend to manage their career in a long term perspective and also how I expect them to perform on 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 all the projects off, but you're also proactively asking for team members in terms of getting more complex projects. That's a good signal that we are sending that, okay, this person is capable of handling more and more. And once that happens, there is a scenario that within an eight month period, I'm getting questions from other engineering managers on like, oh, this person who is at a level three is being able to handle at level four projects. I think we should be able to give him a promotion. That is a perfect signal for me to put you up from promotion. So one is me preparing a case for your promotion. Two, you displaying the qualities eloquently to other engineering managers, where I'm getting questions as to why we are not putting you up for promotion. That is a more stretch goal for you, but that has definitely happened. But I would say aim for 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 process in what an exceptional performance looks like and what the normal performance looks like gave the person the option in terms of what path would they like to choose, and we can adapt to it as and when we go through it. The end result was that, okay, 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 are working towards right now. He's on track for a promotion because he joined March. By end of this year, he's sustaining impact. So I'm putting him for promotion for February of next year.
Stochastic Panda: Excellent. 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?
Utilitarian Lemur: So the idea is that we give them a promotion package and we tell them that, okay, this is now currently being reviewed with the other folks, but what we cannot guarantee is that the promotion is going to through. It's more or less like you're being put up for promotion.
Stochastic Panda: Excellent. Okay, so we've got about five or six minutes, and if you're okay with it, I'd like to spend 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, if you're open to it, I'll start with some of my own comments here.
Utilitarian Lemur: Yeah, that would be super useful. Thank you.
Stochastic Panda: Great. Yeah. Overall, I thought you did 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 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, let's say, setting some of the trust building relationship with your direct reports and maybe some of your interactions with your manager or skip. So, one example, the last question that I asked is slightly loaded, but 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 the direct says or asks, like, give me a list of to dos. Manager provides the to Dos. 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, 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 mind, right. Come to me. Sure, if you have some questions, but if you're not always expecting me to give you a list of to do, then that direct might eventually start thinking a little bit more independently. Like, okay, my first priority is to help my manager and the team. What can I do, right? What can I build? Or how can I get answers to questions on my own? Things like this. Does that sort of make sense? I hope I articulated some of that correctly.
Utilitarian Lemur: It does. Cool. It's more or less like phrasing it rather than saying that, okay, you're not going to get promoted within the six months period. It's phrasing it more in terms of, okay, that's a valid question. Acknowledge the person's question rather than dismissing it, and then ensure that you have a path forward in terms of 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 and the company.
Stochastic Panda: Exactly. Because then you start resolving the tricky thing of transaction based to growth mindset. 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, this manager and I, we have really good and informal conversations over lunch. So I waited for the next time that we had lunch to broach 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 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. 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, this might also help in some of the behavioral. This is super important. 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.
Utilitarian Lemur: Nothing. To be honest, all of these questions were things that I don't think I've gotten before, but I think the clarification that you asked was very clear. It's like when you're saying that you're going to interact with someone, just clarify, give context in terms of saying that. Okay. I set up a weekly one on one with my manager to discuss in general how projects are going along. And in these meetings is where I brought up the project status and how we need to engage with XFN folks. And this served as my primary means of getting feedback from my manager. And this is where we also made a decision of, okay, this is okay for me, get my skip involved, get feedback from them, and then we can proceed forward in terms of how this project needs to be prioritized.
Stochastic Panda: Yeah, absolutely. And that kind of human touch thing might also be a little bit company or team dependent, but 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, et cetera. Again, those were nitpicks, but I think you did well. And, yeah, it was a privilege to speak with you. Thanks for the interview today.
Utilitarian Lemur: Thank you. And it was a privilege speaking with you as well. And I really appreciate the question and the feedback that you provided.
Stochastic Panda: Excellent. All right, well, thanks again, and, yeah have a good rest of the day.
We know exactly what to do and say to get the company, title, and salary you want.
Interview prep and job hunting are chaos and pain. We can help. Really.
