There is a framework to deal with these kinds of situations: There is a concept in project management called the “iron triangle”. The Iron Triangle describes the need to trade-off against 3 constraints: Cost, Time, Scope. You can only control 2 out of 3.
@baoyu_ Engineering managers deal with that along with the ram, cpu cycles, dev cost triangle. But this is 101 stuff and at an engineering manager level they should have far more in depth understanding and experience.
This is the kind of information i live for. That just gave me goosebumps. It just solves SO many scenarios with one process. That's why being process-focused pays off in all atmospheres.
We like to watch an interview with someone who recently turned into engineering manager from individual contributor. Since a lot transition is involved.
Really appreciate the interviewer in this video for actively challenging the ideas with followup questions, which mimics what is more likely to happen in a real-life interview and inspires me to think how I would respond in those scenarios.
He got stuck at progress bar as literal issue and forgot to answer the other question “how your team perceive it” they will either think of you as someone who let go bugs and put you in similar situations later or they will actually think you taking one of a judgement call
There is a whole engineering aspect to the "two features" that is missing from this answer. Sure.. from an outside product manager role. But that isn't what we need a technical manager for. You should take into account the interactions of these features, and infrastructure needs with the rest of the technical roadmap. This can include things like dependencies, or cost of making changes to other parts of the tech to support these features. I can add a feature that is risky, and could compromise other parts of the code base. Or one of the features costs includes developing infrastructure that can open doors in the future. There is much more to this question than just bus value.
Ye but he works at a Big tech where face value is the most important part. You can see that he is way more interested in following the process then the long term effects.
@@DoooooooDooooooooooz I try to keep my profile and work anonymous on here do to cancel culture, but I'm at one of the top 3 ( or 1st, depending on stock market that day). The quality of managers varies dramatically from one team to another. There tech skills, however are always elite to say the least. Getting into this place is like getting into Fort Knox level difficult. Most companies though.. well.. engineering managers are extremely difficult to find. In practice it requires 2 very different sets of skills that are difficult to find in the same person. But when you half ass getting such a manager.. well .. people don't leave companies, they leave managers.
@@BuffNerdInCa The only thing i have learned from working at a big tech is that everything is smoke and mirrors. That’s what they sell and that’s how they get the best talent to do essentially nothing all day other than politics. That’s why you are not hearing this guy talk about anything interesting.
As a director this is a fail from me. At the min I’m looking for systems thinking that extends from the technical to the managerial approach, and I just wasn’t seeing it with them except when they had to recount a known process at Walmart. He just barely stumbled into “customer impact” after much thought - which is a component of a potential framework but he stopped short. It also didn’t do him justice repeating “these things happen all the time” while failing to present a systematic approach to managing through them. If anything, he got caught up so much on qualitative impact/optics, which presumably would be at the end of any description of a system/stack-rank of things to consider. Would’ve loved to hear something like “i use effort + impact. here’s a formula for impact, and heres a formula for effort”. Then the interviewer can follow up to probe branches of that formula, and see if the manager can calibrate when variables are changed. The fact the interviewer has little to anchor and probe on here is a good signal for a beginner watching this that something didn’t go right.
This is a weird question for an EM. Usually the Product owner does prioritization, with input and discussion with EMs/Leads to get a general sense of the effort and risks involved with development. The engineering manager shouldn't be setting feature priorty.
"Usually" does not mean it's being practiced outside MAANG type of companies. There are so many overlaps and roles confusion Technical PM/Product Manager/Program Manager/Project Manger/Engineering Manager or even VP of Engineering with flavor of CTO/CIO. Thus you may end up in situation of working EM and then found yourself in charge of quite broader list of responsibilities. Let's put over this the whole shebang with company size and level of establishment of all processes. The whole point: questions in this video are legit ;)
Absolutely incorrect, empirically incorrect. An EM has resources, and is hired by the company to deploy theme effectively. THEY own engineering time. A PM is there only to provide 1/2 of the input an EM would use to prioritize, and thats impact. An engineer team provides the effort, and the EM takes both inputs to make a call, presumably with the support of their PM but it’s still their call as that’s the sole reason managers ever exist (to allocate resources properly). What you’re likely confusing is the different between a roadmap priority, and an engineering team’s priority. They mostly overlap, but can differ. PMs do indeed own roadmaps, but that roadmap can be dropped in a second to respond to an incident and the PMs feedback is irrelevant.
Very weak answers for followup questions. This manager seems like a someone who is happy to accept sub-par work. At the least he should've talked about fixing the process to avoid future bugs.
what do you expect from interviews to the roles of managing people? There is never one specific answer. You gain your experience and you improvise once you are in specific situation.
It’s true once u enter the interview loop but it’s very hard to have the chance. Most companies tend to do horizontal hiring; that is you need to be on the same level in ur prev company
The engineering manager interviews are such that you won't know if you got the answer right or wrong. You could get a point right, but they are looking for another 5. Very easy to think you did well, but didn't. What shocks people is when I say, yes, that is a good point. Any more points or thoughts on the question, I'm looking for 4 or 5. I'll ask a question about order in which to do features, and most senior devs, PO's fail with "based on business value". that is the least concern in the context of the question.. all features must be present to ship. There are about 10 reasons I can think of and expect 3 to 5 from a candidate starting with the most obvious.. dependency order. The answer given here for the which feature to drop, completely missed the whole engineering aspect to it. Just covered some product management points.
In other videos from Exponent, sometimes the questions are great and the answers weak. In this case the questions and followup questions were weak but the answers were great. For example, on 4:19 "... like so do you give them like the engineering directors or do you like who do linked them up with?". This kind of imprecise speech renders your service and presentation ineffective.
I really didnt like the answers in the followup. - Seemed like ramblings of a common chat with coworkers. Not just answering the question. More excuses and comfort with subpar releases because "others have bugs too"
The interviewer is very accommodating when Indians from India are providing such BS answers, but in this case, it was only a white looking guy and the interviewer was brutal with him
Was this guy fired after the interview? First thing I heard was he has history working in data driven environments, and then talks about missing deadlines and asking for extensions, or delivering half baked products... even worse he spends a good amount of time discussing how he weighs and determines delivery failures and is okay to deliver problematic results as long as exposure is limited. WOW. 1) Never get yourself in a situation where you need to deliver 2 projects and can only deliver 1. This exposes your inability to properly scope projects. Don't talk about missing deadlines, don't talk about asking for extra time. 2) Never talk about setting a low bar. All deadlines are met on time. All projects meet or exceed expected outcome. Don't talk about knowingly delivering projects with known failures. This guy spent a lot of time here... I think he probably routinely delivers faulty products, asks for extra time, or misses deadlines because he is good at talking his way out of it and making it seem normal. Anything less than 100% perfect is unacceptable. Anything worth doing is worth doing right. Anything worth doing right, should be done right the first time. This guy fell into the rabbit hole of the question.
@@rafaelfreitas9009 I do work IT. I was a manager in 2010, and delivered an Active/Active cloud solution that provoked Cisco Systems to head hunt me in Los Angeles and pay to bring me up to Silicon Valley for 7 years. Now I consult. I have trained teams for over a decade. I have NEVER missed a deadline, never delivered an inferior product, NEVER had to explain why an inferior product was delivered by me or my team. And I just want to say... this guys spends so much time talking about limiting the exposure of his failure so only a small amount of people see. It only take 1 bad review or comment to ruin a new product. I hate to be so mean... but I would never hire this guy.
@@rafaelfreitas9009I have 25 years IT working experience for companies like AIG and Cisco. I've NEVER missed a deadline for a project properly scoped. I do not practice answers of failure, as failure is not an option. I take on the biggest projects, because I can deliver.
Don't leave your engineering management career to chance. Sign up for Exponent's engineering manager interview course today: bit.ly/3ieuazv
There is a framework to deal with these kinds of situations:
There is a concept in project management called the “iron triangle”.
The Iron Triangle describes the need to trade-off against 3 constraints: Cost, Time, Scope. You can only control 2 out of 3.
Wow...as an SDE, I would love to work with such manager who keeps teaching such interesting perspectives in every retrospective.
@baoyu_ Engineering managers deal with that along with the ram, cpu cycles, dev cost triangle. But this is 101 stuff and at an engineering manager level they should have far more in depth understanding and experience.
This is the kind of information i live for. That just gave me goosebumps.
It just solves SO many scenarios with one process.
That's why being process-focused pays off in all atmospheres.
We like to watch an interview with someone who recently turned into engineering manager from individual contributor. Since a lot transition is involved.
Really appreciate the interviewer in this video for actively challenging the ideas with followup questions, which mimics what is more likely to happen in a real-life interview and inspires me to think how I would respond in those scenarios.
He got stuck at progress bar as literal issue and forgot to answer the other question “how your team perceive it” they will either think of you as someone who let go bugs and put you in similar situations later or they will actually think you taking one of a judgement call
There is a whole engineering aspect to the "two features" that is missing from this answer. Sure.. from an outside product manager role. But that isn't what we need a technical manager for. You should take into account the interactions of these features, and infrastructure needs with the rest of the technical roadmap. This can include things like dependencies, or cost of making changes to other parts of the tech to support these features. I can add a feature that is risky, and could compromise other parts of the code base. Or one of the features costs includes developing infrastructure that can open doors in the future. There is much more to this question than just bus value.
Ye but he works at a Big tech where face value is the most important part. You can see that he is way more interested in following the process then the long term effects.
@@DoooooooDooooooooooz I try to keep my profile and work anonymous on here do to cancel culture, but I'm at one of the top 3 ( or 1st, depending on stock market that day). The quality of managers varies dramatically from one team to another. There tech skills, however are always elite to say the least. Getting into this place is like getting into Fort Knox level difficult. Most companies though.. well.. engineering managers are extremely difficult to find. In practice it requires 2 very different sets of skills that are difficult to find in the same person. But when you half ass getting such a manager.. well .. people don't leave companies, they leave managers.
@@BuffNerdInCa The only thing i have learned from working at a big tech is that everything is smoke and mirrors. That’s what they sell and that’s how they get the best talent to do essentially nothing all day other than politics. That’s why you are not hearing this guy talk about anything interesting.
there is a whole lot of that
As a director this is a fail from me. At the min I’m looking for systems thinking that extends from the technical to the managerial approach, and I just wasn’t seeing it with them except when they had to recount a known process at Walmart. He just barely stumbled into “customer impact” after much thought - which is a component of a potential framework but he stopped short. It also didn’t do him justice repeating “these things happen all the time” while failing to present a systematic approach to managing through them. If anything, he got caught up so much on qualitative impact/optics, which presumably would be at the end of any description of a system/stack-rank of things to consider. Would’ve loved to hear something like “i use effort + impact. here’s a formula for impact, and heres a formula for effort”. Then the interviewer can follow up to probe branches of that formula, and see if the manager can calibrate when variables are changed. The fact the interviewer has little to anchor and probe on here is a good signal for a beginner watching this that something didn’t go right.
If you follow SW Agile development that framework dictates, clear responsibilities of PM and EM. His answers are fluffy or woolly
Formal framework for defect is assigning severity to defect. All severity of 1 must resolved without question. Deadline has to move.
Dude get someone to fix the progress bar!
This interview had an impact on me.
Are questions such hypothetical scenarios or asking to tell stories from past experiences?
This... was not a great interview.
Agreed.
This dude not measuring shit
Agreed. I believe the prioritization aspect were not well handled
eh this is not a good look for LinkedIn EM
This is a weird question for an EM. Usually the Product owner does prioritization, with input and discussion with EMs/Leads to get a general sense of the effort and risks involved with development. The engineering manager shouldn't be setting feature priorty.
Yap
"Usually" does not mean it's being practiced outside MAANG type of companies. There are so many overlaps and roles confusion Technical PM/Product Manager/Program Manager/Project Manger/Engineering Manager or even VP of Engineering with flavor of CTO/CIO. Thus you may end up in situation of working EM and then found yourself in charge of quite broader list of responsibilities. Let's put over this the whole shebang with company size and level of establishment of all processes. The whole point: questions in this video are legit ;)
Absolutely incorrect, empirically incorrect. An EM has resources, and is hired by the company to deploy theme effectively. THEY own engineering time. A PM is there only to provide 1/2 of the input an EM would use to prioritize, and thats impact. An engineer team provides the effort, and the EM takes both inputs to make a call, presumably with the support of their PM but it’s still their call as that’s the sole reason managers ever exist (to allocate resources properly). What you’re likely confusing is the different between a roadmap priority, and an engineering team’s priority. They mostly overlap, but can differ. PMs do indeed own roadmaps, but that roadmap can be dropped in a second to respond to an incident and the PMs feedback is irrelevant.
He isn’t Software development EM , looks like Senior/principal engineer or non SDEM ,never talks about scope/MVP/talk to product teams etc
Excellent questions n answers
Good questions.
This one was great, several insights. Good advice in the end 😊
This interview only provided hand waivy answers. The answers were also not structured well.
Thank You Exponent!
if (progress > 100 ) progress = 100;
if (progress < 0 ) progress = 0;
actually he did not answer in a one line he try to make confuse. i dot get what he want to say :)
Very weak answers for followup questions. This manager seems like a someone who is happy to accept sub-par work. At the least he should've talked about fixing the process to avoid future bugs.
Very high level interview but great talk nonetheless.
what do you expect from interviews to the roles of managing people? There is never one specific answer. You gain your experience and you improvise once you are in specific situation.
I feel engg manager interviews are a lot easier than an individual contributor. Is it just me?
It's a different ball game but yes they're on the easier side.
they are being interviewed on all the things ICs are, plus other things ICs aren't
in the faang interviews, not all companies
It’s true once u enter the interview loop but it’s very hard to have the chance. Most companies tend to do horizontal hiring; that is you need to be on the same level in ur prev company
The engineering manager interviews are such that you won't know if you got the answer right or wrong. You could get a point right, but they are looking for another 5. Very easy to think you did well, but didn't. What shocks people is when I say, yes, that is a good point. Any more points or thoughts on the question, I'm looking for 4 or 5. I'll ask a question about order in which to do features, and most senior devs, PO's fail with "based on business value". that is the least concern in the context of the question.. all features must be present to ship. There are about 10 reasons I can think of and expect 3 to 5 from a candidate starting with the most obvious.. dependency order. The answer given here for the which feature to drop, completely missed the whole engineering aspect to it. Just covered some product management points.
In other videos from Exponent, sometimes the questions are great and the answers weak. In this case the questions and followup questions were weak but the answers were great.
For example, on 4:19 "... like so do you give them like the engineering directors or do you like who do linked them up with?". This kind of imprecise speech renders your service and presentation ineffective.
If I were interviewing this person, I would not hire him.
I really didnt like the answers in the followup. - Seemed like ramblings of a common chat with coworkers. Not just answering the question. More excuses and comfort with subpar releases because "others have bugs too"
hi,
for next time can you use white board,for more understanding like for slow learner
Easy. Do one, finish it and them do the second one. The question says both need to be done. You have to do both. Period.
lol 😁
The interviewer is very accommodating when Indians from India are providing such BS answers, but in this case, it was only a white looking guy and the interviewer was brutal with him
😂
This was terrible
This is a horrible interview. Why would an EM be in a retrospective? Does that promote psychological safety?
No thank you sir! 😂😢😢
Was this guy fired after the interview? First thing I heard was he has history working in data driven environments, and then talks about missing deadlines and asking for extensions, or delivering half baked products... even worse he spends a good amount of time discussing how he weighs and determines delivery failures and is okay to deliver problematic results as long as exposure is limited. WOW. 1) Never get yourself in a situation where you need to deliver 2 projects and can only deliver 1. This exposes your inability to properly scope projects. Don't talk about missing deadlines, don't talk about asking for extra time. 2) Never talk about setting a low bar. All deadlines are met on time. All projects meet or exceed expected outcome. Don't talk about knowingly delivering projects with known failures. This guy spent a lot of time here... I think he probably routinely delivers faulty products, asks for extra time, or misses deadlines because he is good at talking his way out of it and making it seem normal. Anything less than 100% perfect is unacceptable. Anything worth doing is worth doing right. Anything worth doing right, should be done right the first time. This guy fell into the rabbit hole of the question.
Are you working for IT? Not even big tech companies are able to achieve what you described here. Absolutely insane.
@@rafaelfreitas9009 I do work IT. I was a manager in 2010, and delivered an Active/Active cloud solution that provoked Cisco Systems to head hunt me in Los Angeles and pay to bring me up to Silicon Valley for 7 years. Now I consult. I have trained teams for over a decade. I have NEVER missed a deadline, never delivered an inferior product, NEVER had to explain why an inferior product was delivered by me or my team. And I just want to say... this guys spends so much time talking about limiting the exposure of his failure so only a small amount of people see. It only take 1 bad review or comment to ruin a new product. I hate to be so mean... but I would never hire this guy.
LOL what a crappy answer. Hope you are not an EM.
@@rafaelfreitas9009I have 25 years IT working experience for companies like AIG and Cisco. I've NEVER missed a deadline for a project properly scoped. I do not practice answers of failure, as failure is not an option. I take on the biggest projects, because I can deliver.
😂