Engineering Manager Mock Interview ft. Robinhood EM

how do you set goals for your team [Music] hi everyone and welcome back to another mock interview with exponent today we're here with sri shari would you like to introduce yourself yeah definitely happy to be here and hi everyone my name is sri i serve as the head of data infrastructure at robinhood and my role is mostly an engineering management role my my role is to support the organization support the career development of people uh help make sure that we're building um you know good strategy towards uh supporting um internal teams and customers at robinhood so to give you all the quick overview uh data infrastructure's mission uh is to build foundational data platforms which are then used by the rest of the company so most of the work involves you know working with big data technologies building the right foundational tools and platforms which are leveraged by engineers data scientists and analysts across the entire company i joined robin hood uh last year and prior to joining robin hood i spent about eight years at yelp um where which is where i started my career as a fledgling new grad after grad school um got a wonderful opportunity there to grow as an engineer before moving into a management role uh setting up the data platform team there and kind of growing that over time so i've mostly been in the platform and infrastructure space uh which is something that i enjoy doing and uh you know been and been in a management role for about uh five or six years so far that sounds fantastic thanks so much for for sharing that with us tree um you're here with us today for an engineering management mock interview um and my first question to you is how do you set goals for your team yeah it's a good question and i think it's one of the more important things that you know engineering managers have to do so maybe i can walk through a high level kind of philosophy and approach and how i think about it and then maybe share some examples uh does that sound good that sounds good okay sounds good yeah so the way i think about this is um you know in order to set goals uh for your team uh you need to get inputs from the right places so how i think about inputs are uh need to get some inputs from um you know senior leadership maybe there are initiatives that the company wants to drive or the organization wants to drive taking that as an input taking an input from you know your team's customers so for me kind of being part of a internal platform team our teams customers are other teams within the company so getting a sense of what they want uh what they're looking for what are the challenges that they're facing taking that as an input um and then the third input i would say is from uh your team so in in my case that would be kind of engineers and managers in my team uh who have you know a lot more context there their ears are on the ground they have a good understanding of you know where the skeletons are hidden in the closet you know where there are big tech debt items that we need to tackle and can i take those inputs um you know the idea is going to collect all of these inputs and then use them as part of the planning process so that's kind of the the high level philosophy you know to break that down with a concrete example um you know let's take the example of you know the recent planning cycle that i've been through in terms of setting goals for the team uh so once i kind of gathered all of these inputs um so i gathered inputs from senior leadership uh you know uh you know purely by asking them and some of these get transmitted down from the company so that's kind of the easy one the second one is getting feedback from from customers so one of the things that um you know my team does is we send out periodic surveys to all of our customers and we ask questions like hey um you know what features would you like to suggest for our platforms or we ask questions like on a scale of one to ten you know how likely would you how likely would you be to recommend this platform to another team and try to take that as as an input so we get a survey results and you know we look at the survey results together as a team and then try to determine uh which of those we should prioritize and as for inputs from the from the team i do a similar process i you know send out a survey to my team uh asking people to suggest ideas upward ideas and we go through a collaborative brainstorming session um and once all of these ideas are collected um you know if i'm directly managing a team i'm kind of the point person but if i have other managers or leads i usually ask them to drive that process where we put all of these data together in one single spreadsheet and then try to stack rank the priorities based on our intuition our judgment and the data that we've gathered and once we've kind of stack ranked the priorities uh we then try to determine how much of these can actually be meaningfully be done by the team uh and so you know that's a little bit of uh uh mixture of an art and science i would say um because you know the science part is we can you know estimate the size of those projects uh by asking the team by asking the engineers who are closest to the problem but there's also a lot of uncertainty with estimation like especially with projects that we've never worked on so we have to bake in some buffer there and then based on that then try to determine uh how much can the team meaningfully do and add a little bit extra as a stretch goal in order to kind of motivate the team to push themselves and then once this is done you kind of have a roadmap for the team and depending on the company some companies follow an okr format um so we try to use objectives and key results sometimes follow a roadmap format uh so depending on the company and kind of the nature of the process some of this might vary but that's generally the the process i tend to follow got it and then so you mentioned that you follow some criteria for prioritizing these things that you that you rank in your in your spreadsheet right what are some examples of the criteria that you consider other than complexity of the project yeah that's an excellent question so the way i think about this is uh priority prioritization of rubrics are closely tied to kpis for the team so for example the kpis or key performance indicators for data infrastructure would be reliability uh scalability security and we have specific metrics measuring that so what we try to do when we come up with these projects is try to determine which of those metrics these projects are intended to move so for example if we have a project to you know add some more access control features on some of the infrastructure that we're building that's going to improve our security kpi or if we have a project that our customers have asked for that is going to make their lives easier we're probably moving a customer satisfaction metric so just trying to determine which of these metrics or kpis these projects are moving and then determining kind of a portfolio of them um at least in my experience i feel like it's very very hard to you know objectively stack rank everything that the team does but it's useful to think of it from the lens of prioritizing them into buckets so maybe we want to take a portfolio where we say you know in the last uh cycle or in the last year we built a lot of innovative features but maybe accrued a lot of ticket so the portfolio of you know reliability projects will be higher uh and uh you know we might allocate a 60 portfolio to that uh as opposed to you know uh uh 20 or 30 so i think of it from the perspective of portfolio assigning these projects to these portfolios having some percentage allocation for them and then within each of these portfolios trying to rank these projects based on uh how how likely they are to move the metrics that we care about some of them are very data driven some of them are intuition driven so you know we don't always get it right like i make mistakes here all the time and then kind of learn from it retrospectively yeah yeah absolutely um so you mentioned you mentioned that tech debt is definitely something that you consider when you're prioritizing your work and then it kind of depends on just how did the previous half go how much tech did you actually build up so let's say you're you're in a half when there's a lot of tech debt and you have to really prioritize that move a lot of projects up to the forefront p0s have a lot to do with just you know cleaning up some of that code how do you motivate your engineers when a half is looking like it's not really going to be very product or you know other kpi oriented and it's going to be very tech debt oriented yeah that's a great question i'm smiling because uh hits home i'm an engineer so i really want to know how you answer this question this is very real i think i think one a common mistake that a lot of people make including myself and i have made this mistake before in the past is to not communicate the truth to the team um you know engineers are smart like everybody that we hire is this is smart uh you know that's the assumption that i go with and people deserve to know the truth uh you know in the past i've made a mistake where you know i try to sugarcoat things i say hey you know it's fine we'll do some exciting things but uh people can see through bs uh and so i think it's just really important to be honest um because at the end of the day um you know most people i'm not saying this is true for everybody but you know most people want to do work that is impactful uh to the company to the organization uh and also they want to you know learn new skills along the way um you know going by that uh going by that logic uh you know my approach usually is uh first communicate the truth like hey like you know this is why we are prioritizing this uh we have lots of tech debt and if we don't address it right now uh this is going to cause a lot of pain to us in the future and and try to connect the tech debt to the impact that it will have on the team if we don't address it uh so for example if we don't address the ticket in a timely manner uh the on-call burden on the team might increase and uh you know uh people on the team might feel more miserable uh in in the long term tying it back to you know what it means for the company and what it means for the team and for individuals on the team is helpful um and then also communicating the fact that you know some of this work might be interesting for some people some of this work might not be interesting for some people uh so i think that's where i try to balance you know project interests uh with people's career growth interests so for example uh you know a tech debt removal might be let's say there's a project to upgrade a particular library and then you know probably the previous library has a lot of bugs and you know take debt we just want to upgrade it to a new version most people think it's it's a very boring thing to do but there might be people on the team you know for whom this is a great learning opportunity to uh learn something new and this might be a good fit for them so uh trying to figure out uh you know the right project person fit uh can also help there and then the third thing i kind of communicate kind of the realistic picture that you know for us to be a sustainable team in the long term uh you know we don't want to be tackling tech debt all the time so if we do a really good job you know in this cycle in this half we should be decreasing the portfolio of time that we spend on tech debt so that we spend more time on exciting products and features so uh it's never an easy conversation uh you know i i may have made it sound as if you know it's a playbook and you can just run through it it's never an easy conversation but i think it boils down to just being honest with people and you know having this conversation about priorities and impact it has on them and it has on the business okay that sounds wonderful um yeah i think as an engineer i think that sounds great i would always like to hear honestly just what is the situation this half um how much work are we gonna have to do on tech debt and have that up front rather than try to guess you know where the where the team's at um my last question for you is at some point in your first answer you were talking about stretch goals or you just touched on it lightly so i'm curious how do you evaluate when something is a stretch versus just you know a goal like anything else yeah excellent question um the way i think about it is uh when we do kind of capacity planning for our projects and try to determine uh the process that i tend to follow is like a t-shirt size estimate where we say you know is this project a small medium large extra large uh and then try to associate some notion of uh you know person weeks or some some estimate of that nature uh and then we'll have a high level capacity for the team based on the number of people on the team so if there are you know eight people on the team it's uh uh um 32 uh person weeks in a month and so on so uh trying to kind of use that as the capacity estimate and then uh you know try to do a kind of rough comparison of you know how much can we meaningfully take on given the capacity that we know on the team and anything that's beyond that is quote unquote stretch because uh it's probably unlikely that we'll be able to finish it uh you know finish those things within within the within the designated time frame um and so i specifically like to call those out or i basically we as a team like pick out a couple of them from that list like from the projects that kind of fall beyond the cut line uh and specifically call them out as stretch because uh we don't want to communicate to our customers that we are going to you know finish this and commit to this because that would be perhaps signing up the team for too much but at the same time you know we don't want to be a team that you know is complacent or you know sits pretty on you know the goals that we've set uh we want to aspire to keep doing more and more because a that is healthy for the company because we want to drive more value to the company and b it's healthy for people on the team because the more uh you know impact that people have on the team it helps them grow their careers too so um from that lens you know i work with my tech leads or engineers who are most familiar with the area to pick towards three of these initiatives or projects that are beyond our capacity but we call them as stretch goals i want to make sure you know before i actually communicate that in okrs or whatever format that the company uses i want to make sure i get that sign off from the team because i don't want to be the person who just arbitrarily signs up for stretch goals so usually back to the team and say like hey these are a couple of things um you know i'm interested in calling out as a stretch goal does this make sense and then once i get kind of the buy-in from the team we call that out and the idea with stretch goals is um uh those are kind of aspirational projects for people or members on the team who want to do more kind of beyond the the things that have been signed up on the team and so uh sometimes you're able to hit stretch goals in my experience sometimes we're not but the times we're able to hit us hit our stretch goals i think you know it's a good indicator to me that you know the team is like performing well and we should you know keep moving that in subsequent quarters and subsequent halfs yeah as a follow-up to that so what what do you do when you don't meet your goals whether they're stretch or not there are times when goals aren't met what what do you do then yeah great question it happens uh it happens often in certain projects um my approach there is you know just try to you know first of all try to anticipate that uh early on some projects it's easier to anticipate um uh you know i i have uh um you know the team has a you know bi-weekly sprints or i have weekly check-ins with the project leads so i keep kind of asking questions on are we on track like are we at risk so some of these things we we may be able to anticipate and if we're able to anticipate um i i basically um uh you know either myself or through a project lead like communicate that to our stakeholders and say hey this project is at risk and this is why it's at risk and providing that context some of that risk can be mitigated by cutting scope or by uh adding more people but but in some cases you know maybe that's not possible and those are kind of the easy ones right the harder ones are when you don't anticipate them and you just fall short in the end and it happens sometimes yeah i think in those situations it's important uh you know to approach it from a blameless perspective and to do a very honest retrospective to see you know what went wrong uh is it um did we go wrong in estimation did we go wrong in uh not knowing uh how complex a particular task is going to be uh where did we go wrong and just trying to find that and make sure that we learn from that and we don't make the same mistake again um but yeah um the goal at least for me like some one of the things i strive to do is like try to anticipate this as much as possible in advance so that we can course correct but in cases where we can't just do an honest retrospective take away the learnings and apply them next time um i i you know i have this controversial uh mindset uh some people may not agree with this but i feel like you know most deadlines are arbitrary uh except when you know there are a few deadlines that matter where you have you know multiple teams coordinating or there's a big release that the company owes to a customer otherwise most intermediate deadlines are arbitrary so uh you know as long as you know we uh are able to understand you know why we were slow or why we missed a particular date and we're able to action on it i think that's kind of a reasonable next step okay thank you so much three that was fantastic um i have feedback that i'd love to give you but before i do that i wanted to ask you to self-resp staff sorry self-reflect um and let me know what you thought cool yeah uh yeah i thought the questions were good um you know i uh i was trying to kind of pick experiences from from from my past work experiences and trying to communicate that um yeah i think um maybe in in some places maybe i uh um talk too long and so maybe i should pause and then you know ask the interviewer uh to make sure i'm on the right track i did that in some places but in some places i think i i ended up you know talking too long without kind of asking for asking for follow-ups um yeah otherwise i think it was it was good uh was able to kind of get some get some interesting high-level examples uh i was trying to you know figure out you know how much to how much concrete examples i should share given that this is the interview i held back from sharing very specific ones but but i was trying to balance that line so hopefully you know the points points came across no that that definitely makes sense um to the to the first thing you said where maybe you felt like you talked a little bit too long in some cases um i think yes maybe in in some cases i felt like there were some follow-ups but then you preemptively answered questions that i would have had later which i don't think is i don't think it's terrible to do that as long as you have a clear structure for what you're saying and i think you did um i was following you throughout there wasn't any point where i thought like the question was just out of hand and i didn't i didn't remember what i asked you to begin with so it's a fine line um i think you i think you did fine um with just answering the question giving me good enough structures that i could follow you throughout the throughout the process and what i thought you did particularly well was this was very conversational it was very easy for me to jump in ask you follow-ups um and you know play off some of the stories that you were telling me and and you did the same i think it was when you treat it like a conversation it's just a lot easier to to be able to convince someone else that you not only have the chops for management but also empathy which is extremely important when you're when you're dealing with people on a daily basis another thing i think you did well was in one of your questions you admitted a mistake that you thought you made early on um i think this was remind me i think this might have been in the uh how do you motivate your engineers when you know you're going to need to do a lot of tech that work right and i think i think that's fantastic whenever there is a possibility to demonstrate growth because there's you know something that you didn't know before but you do know now i think that's it's a great way to do that and to show that you are capable of growing and learning from your mistakes so that was really good in general just with the structure of your answers i really appreciated that you started off with philosophy and then you went into just here's an example and practice of a time when this happened i know this is going to be more specific um in a real interview but but i think yeah in general that structure is really good wherever it's whenever you can use that so yeah overall i thought this was this was a great interview i enjoyed talking to you and i felt like i got really good insight into how you work and what your philosophies are and i hope i hope this was useful for you as well yeah i know definitely this was fun and uh you know as as someone who you know as someone who interviews and also as an interviewer like either ways it's really hard to get that feedback on you know uh how your communication comes across so i appreciate the notes that you shared because uh uh it was really helpful to know from you know another perspective uh you know what were the things that could change what were the things that went well so yeah that was fun fantastic thank you so much for being with us shree um this was really fun to do today and good luck with all your future interviews thanks so much for watching don't forget to hit the like and subscribe buttons below to let us know that this video is valuable for you and of course check out hundreds more videos just like this at tri-exponent dot com thanks for watching and good luck on your upcoming interview [Music]

Channel: Exponent

Views: 83,108

Keywords:

Id: sOX_Xl1TKic

Length: 21min 54sec (1314 seconds)

Published: Mon Aug 30 2021