YouTube Transcript:
Amazon interview 2
Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.
Share:
Video Transcript
in terms of the minutes to flow. So, I'm planning to cover three different areas that largely focus on the Amazon leadership principles. I'm just, you know, looking for probably uh somewhere between three to five questions is what we'll have time to get into. Um, and really what I'm looking for is just, you know, your individual experience. Um, as as we get into the questions, I'm looking for really kind of your individual contributions, kind of when you got into a project, you know, what what did you do? um and and then help me understand as much as you can with data, you know, just what impact your your projects had and things like that. Um and I try to make these very conversational, so I may interrupt you at times just to try to get a better understanding of of the the examples you're providing. Um and um what else can I share? And yeah, I'll be I'll be taking notes on my end as I'm sure uh most folks that you spoke with are probably typing on their computer. So we're not multitasking. We're just uh trying to capture our conversation, you know, just uh taking notes. That's what we'll be doing on our side. Um and then like I said, I'll leave somewhere between, you know, 10 to five minutes for questions you may have uh at the end. So, sound good. Yeah, sounds great. Let's go. Excellent. All right. Uh so, let's get Actually, if you don't mind, I'm going to go off video so I can go full screen on my end. Feel free to do the same back on video. Yeah. So uh the first question is really around um uh delivering uh the on projects. I'm looking for an example of a time where you had significant unanticipated obstacles to overcome to achieve a key goal or a project milestone. So help me understand what made it um you know significant and what made it unanticipated and then how you dealt with it. Got it. So project where I had significant and un unanticipated goals to overcome obstacles to overcome to reach a goal. Got it. Yeah, sure. Um I can um think about a recent scenario that happened in my current uh role at Philips Healthcare. So I've been working on uh I'm a mechanical design engineer working on a defibrillator uh a medical device and I designed the main enclosure uh for this device which is a plastic component and when I received uh the first articles from our manufacturer and I built it into an assembly and I performed a series of hardware tests u to validate its functionality and performance and in One such test when I did uh when I dropped it uh according to a standard drop test I noticed that on one of the particular corners orientations when it was dropped uh the water ingress seal was popping out. Uh this was basically like a watertight seal uh that um ensures this device maintains its uh IPX rating. So that was a catastrophic failure if that happened in the field. And as the lead designer for this uh component, I took over the my task here was to perform a root uh cause investigation, see what why this was happening and how I can prevent it while also taking in into consideration that we were pretty close to a phase gate at that point of time and I want to avoid any costly retooling and uh deadline derailing u because of that. So um the way I started off is first uh I built u multiple series of these encoders because I wanted to replicate this issue so that it wasn't just a one-off issue and it was happening uh was occurring more uh so when I built a a few of these and I tested them uh it occurred more than a few times. So this was definitely uh more of a design flaw at that point uh is was my conclusion. And actually apolog's design that you were testing. Uh this was my design. This was your design. And then so you said you built a few uh additional closure enclosure. You just I guess you're trying to understand like what's the failure rate, right? How many um is it like 50% failure rate or or or more or less? Uh can you help me understand like what was the failure rate in actuality? Like what are you running into? Yeah, sure. So, um what I figured out is when this particular device was dropped on that particular orientation after three to four drops is when it would the seal would pop out. So, it took like three to four drops for that section to like weaken out and for that action to occur. Okay. Uh, thanks. And so, um, yeah, so once I tested multiple of them and they all had those flaw, uh, it was pretty evident to me that it was a design flaw and not a manufacturing or material flaw more of. Uh, so next I used a high-speed camera to capture exactly what was happening at the moment of impact. And I figured out that because of the way that uh this assembly was designed, uh one section of that assembly had a lot of electronics packed into it and the other section was pretty free and it was like a hollow shell. And that difference in uh assem uh you know assembly stiffness was causing the hollow end to deflect a lot more than the uh stiffer end. uh which respected electronics and that difference was enough to create enough of a gap at the moment of impact for this seal to pop out. So uh with all of this information u now on hand I started getting with some uh prototype development I got to making some concepts to see how I would overcome this. Um I realized that you know this was happening because one section is hollow. So I had to stiffen it out. I printed out some SLA uh prototypes too. I had some reinforcements in that section to give it some extra strength. And then I had other uh reinforcements like cupping and um stuff to prevent relative motion uh between different compons within the within the enclosure. So after all of these uh reinforcements, I performed another drop test on this device. And previously when it was popping, the seal was popping out after three or four drops. This time it was doing it after 12 to 15 drops. So to me that was within the performance spec of what I was looking for and I would call that pretty much resolved. So I then coordinated with our manufacturer because whatever reinforcements that I was uh I wanted to implement, I had to make sure they did not interfere with the existing tooling and other manufacturing uh architecture that was already built to make these in an injection molding press. So I had to make sure um that coordination was maintained and uh together we came up uh with the the final design and we have uh since received a new batch of production of these parts from the manufacturer which I tested and they perform within the the mod the expected uh range now 12 to 15 drops and so yeah that's kind of how the whole process went. Um okay so this is helpful thank you. Um I'm trying to understand so when you kind of look at this example right your design you get the the sort of prototype back you get the failure rate find a way to fix it. When you kind of think about that example that works backwards. Um, was there something you could have done differently I guess in the design initially or was it more a function of the the fact that really you were getting a complete assembly back there might have been like gaps in kind of what you could have designed them for. Yeah. I know that makes sense and that was actually one of my biggest learning from this uh experience too which is uh so when I initially designed this part uh in isolation I performed an FA analysis on it to see how it would impact when it you know when it's subjected to some kind of mechanical stress things like that uh but when it's assembled together into a bigger complex system there's a whole new level of uh comp factors that come into uh which is something I should have considered at an earlier stage. So yeah, that's that was my big learning. Now when I'm designing something that interfaces with multiple different subsystems, um I take that knowledge into effect before you know I'm shooting off the parts to the next level. Sure. Um you you mentioned uh you got it to sort of 12 to 15 uh kind of drops for the failure to occur that you said that was good enough. Is there something you could have done to go beyond that? Right. I mean there's there's meeting good enough and then there sort of exceeding what's expected and there's that's a tricky balance, right? Yeah. Or sort of overorrect too much. um help me think like help me understand sort of why good enough was good enough in this case and why not go more than that. Yeah, sure. Um so in this case what I was actually targeting is the the bare minimum requirement was that this thing had to survive at least uh three drops on one uh edge. So it was kind of on the borderline of the bare minimum and getting this to so my idea was to get it to within a factor of safety of at least double the requirement which should have been like six to seven drops and so when after this reinforcements it got pushed to like way beyond. So that felt like definitely within the comfort zone. It could have been made even more secure but at that point it's like diminishing returns because we would have to add a lot more uh material and made it make it expensive. Got it. Okay. So, you weren't really that the three was the the cusp of of the failure rate, but the 12 is actually quite right quite good. Okay. Okay. Um I'll switch directions. Um different example, a different question. I'm looking for an example of a time where you received critical piece of feedback or tough or critical piece of feedback. um and and how you sort of took the feedback and how how you adapted it um to improve your um your work. Oh, did you hear me? Yeah. Yeah, I can hear you. Sorry, you were cut. Okay. So, did you get a question or uh yeah, so I I think you cut off at the end. So, like a time I got critical feedback and how I improved myself based upon that. Yeah. Just looking for example of you know critical feedback from a peer manager. Yeah, of course. And um what did to um Yeah, sure. So uh in my current position at Philips um there were times when uh this was pretty early on in my career uh I was leading several uh key subasssemblies within the defibrillator device and I was regularly presenting updates in cross functional design reviews with teams from different backgrounds like electrical usability systems uh project management industrial design and um I I took uh pride in the technical part of that work. Um I went very detailed focused on the all the qualitative metrics all the CAD FA DFM and after a few of those meetings um my manager pulled me aside and he gave me some direct and critical feedback um along the lines of your work is technically sound uh but your presentations are too detailed and too technical. um you want you have to tailor them to you know like your what your audience are looking for and what information they really need to do their end of their task. So that that was kind of u the the feedback that I received after one of those presentations and so that um hit me because my goal was to drive was not just to present whatever I had in my work. my goal was really to drive alignment with these other teams and move the program forward. So that that's what that you know that's when I got like a better understanding of what the objective of these presentations were. Uh and you know like I had to like kind of slow it down, take it back on track. So my task became figuring out how to improve my technical communication style so that everybody in the room felt aligned and not overwhelmed by it. So I started um observing how some of our senior engineers uh and managers structure their updates. I noticed they always led with context from a top- down approach with the objectives and tradeoffs before diving into any technical data. So I kind of adopted a similar style. Um I switched to a top down communication style with a high level summary and then going with the key decisions and then the rational behind it and then supporting data for anybody that wants to dive deeper into something like that. And I made it a point to like uh send out these presentations well ahead in time so that people uh had enough time if they wanted to get into the details of it at the review meetings. So this uh impact uh it was quite observable. Um the meetings after that were shorter and they were more productive. The discussions became more focused and I got um much faster and smoother approvals on some of my proposals and um and and all I got positive feedback from even the nonME team members after that and it helped me build a level of uh trust and communication between our different uh teams uh none teams. So yeah, one one thing that I really learned from this, you know, like uh having the technical skills is more of just like the gateway to do your work, but really to be effective, uh you know, it's more about how you can translate your ideas across different domains and bring people on board. Um so yeah, it was a good learning experience. That was good feedback from your manager. I guess I'm I'm trying to think about in that example, did you have a prior understanding of what was expected. I mean because I could almost you know if I were your situation you know you go back with the manager and say hey no one said that right no one told me. So was that expectation set or was it just you had kind of taken on this role but what was expected was not really clearly done. Um I think it was a bit of uh I you know I I had the the basic understanding you know like why we were doing this design reviews which is to like hey we're making a change in the design we just want you guys to know this is why it's changing. So I had that basic understanding going into it. Uh but you know like I really had to go through a few of them to get capture the sense of you know like these people are giving me their time because really what they want to know is how it affects them and what they have to do. Uh you know that relates to what my work is not just making a presentation of look at my work is what I did. So yeah. Right. Okay. And um did you get any feedback from peers or others in the meeting after you know after you adopted your style was any kind of recognition of of um the change in style you mentioned a few things in terms of it drove me faster and um you know kind of it was people sort of understood what you were trying to get local feedback yeah I think um I've had my manager talk about it and and some of my me peers talk about it but the most uh actionable feedback that I noticed is definitely how smoother my meetings went uh after I started doing that. You know, previously we were we were talking spending a lot of time on like the minute technical details of things that didn't really make a lot of sense in the bigger essence of the picture. But now, you know, it was definitely a lot more streamlined uh and lesser detours through the course of it. So, so it's a good uh good feedback, I suppose. Yeah. Yeah. That's kind of how I I interpret it. Okay. Um, we'll stick with the manager as as maybe the the the anchor point, but a different question. I'm looking for an example of a time when you strongly disagree with your manager or it could have been a peer manager or peer, someone you work with. Um, and the disagreement was on something you considered very important for the business, right? Kind of think of it as a fundamental disagreement. Um, help me understand the the source of the disagreement and how you kind of manage or navigate through through the disagreement. Right. It's it's you know in some cases the person you're disagreeing with is right. In some cases you're right. Right. So how do you kind of you know so help me understand the disagreement and then how you navigate through it. Yeah sure. Um I think a similar situation I have with my manager actually. Um so as part of my current u role and responsibility uh on behalf of the mechanical engineering team I was the reviewer for some of the system level performance documents and uh one such document was like a highle u system performance doc where which basically outlines all the uh require functional requirements and that document would later trickle down to our me team as design requirement. documents. So when I was reviewing this uh one requirement stated that uh when um so we basically use something called an infant child key which is like a plastic key with a magnet to flip the device from adult mode to a child mode. U so this requirement said when this key was inserted into the device if it breaks uh during a drop uh the part of the key within the device must not get dislodged in it and it should be able to be removed without use of additional tools. Uh which made sense to me because you know if it gets stuck in the middle of a safe people are going to that's going to cause delay and potentially loss of life. So it made sense to me and I signed off on it. And then two months later when we received u our parts from the manufacturer, I was running a drop test uh on this device with the key. And then I noticed uh there were multiple failures when this key broke. It was getting dislodged in the device and sometimes I needed foreps to remove it uh out of the device. So, I instantly flagged this issue with my manager uh and I took it up to him and at first uh he was a little um hesitant on it. Uh he kind of dismissed it saying this is not a hard regulatory requirement. This is more of a nice to have uh kind of a requirement and this could be relaxed out over the next revision of this doc. Uh and at at that point I didn't uh push on it. Uh but it didn't quite sit right with me uh making uh a standard uh requirement change that late into the design cycle because of a testing convenience. It seemed like a slippery slope that would affect uh bigger things later down the line. So, um, I didn't push back on it right away, but I took the opportunity uh at the next, uh, weekly one-on-one that I had with him, which was the following day. And, uh, rather than approaching uh, escalating it in an emotional manner, uh, I laid out a a constructive proposal for him. So first I uh you know like gave a transparency into like why uh this requirement was in effect uh because uh how it could affect the safety of a participant during the save if it gets dislodged and people spend time trying to get it out. Uh and once I did that I also outlined um a plan um that I would I would I was ready to take ownership of this design change. I would start conceptualization, prototyping, get ready, talk with the uh manufacturers and get a fix up within uh a month. And I showed him a timeline of this and I said I would prioritize and get this out. So when I approached it at a at that uh that kind of a more constructive manner, his stone kind of u changed about the whole situation and he went like okay so looks like he already got a plan ready for it. So then go ahead and take the lead on it. And so then I I spent the next couple of weeks uh redesigning it, testing it. Uh and once I felt like I found a good concept that was in a good place, I worked with my manufacturer to get a fix out. Uh we have since received uh first articles of these keys again, which I tested and um they fare uh much better. uh even if they break this time it's easy to remove them out of the the of the socket and doesn't cause the issue anymore. So I guess on this question um you said that you feedback for the manager feedback. Um help me sort of think about that through data. Right. So you have this sort of instinct that says this is a bigger issue than the manager is understanding. Yeah. Could you have proven it with data to the manager? Yeah. Um so I think um the best way that I took at that point of time was um I showed him a couple of these samples that I that I have broken when I was performing a drop test and I actually laid it out when I was meeting with him later. I laid those in front of him and I showed it to him like uh this is not as an easy of an issue as we think it is. This is actually pretty complicated because when it gets broken and stuck in there, you need tools to get it out. And imagine an EMS uh personnel running across with it and it breaks in the field. There is no way they're going to be able to perform a save with this. So, and I also told him that I tested about eight or nine samples and this problem occurred in more than two of them, which is more than enough to cause a concern for us. So, those were my two metrics. Yeah. I guess what I'm trying to understand is what was the miss the first time around when you manager seemed like he's dismissive of it. Why do you think that was? I think um it's it's a mixture of one uh because on on paper this was not a an FDA regulatory requirement. Uh this was something that u we at Philips u came up with just based on a functional usability uh kind of u requirement. So it wasn't mandatory but it was still critical to functioning of the device. So the reason why I think um he was hesitant on spending more time on this was because we were pretty close to a design freeze at that stage. We had like a two two months to two and a half months of a window before we we're starting official verification and validation on these and a delay like this at that stage uh would have definitely derailed that timeline. So I think yeah, but when I put it in front of him like the proper timeline of this is how long it will take and this is by when I'm going to have it back in our hands ready to go. It just made it easier for him to make that call. Got it. Okay. I think maybe what's still missing for me is like understand it's not like you you you found the issue, you push, you advocated for a change with your manager and you were able to get it sort of addressed which is great. But it seems like there's a process gap somewhere upstream from you. Um right where these kind of requirements potentially mclassified. How do you what do you do to fix that? Um so especially in this case when we figured out this was um a glaring gap in the the requirements classification. Um after this conversation with my manager um I also checked with the systems team to say why you know get an understanding of why this was only just a baseline level requirement but not something more critical. And some of this was to do with uh uh with just how things are laid out in medical tech. If something's been uh working and untouched in a while, people are hesitant to make radical changes. um and some of that just got carried on from a legacy uh build of what we were following. And turns out in the previous case we were using a slightly different version of a infant child key where this kind of a uh problem wasn't very evident. Okay. Got it. Okay. So that's um let's see. We're doing pretty good on time, so I'm gonna keep peppering you with more questions. Um, as kind of going back to the first, uh, theme you were talking about. I'm looking now for an example of a time when you did not meet a goal that um, you considered. Um, uh, oh, actually, sorry, let me rephrase that question. Looking for an example of a time where you not only met a goal, but exceeded what was expected of you. So you kind of you know exceeding expectations in this case. Okay. Yeah. Um cool. Uh all right. Um I can think about a scenario where I was working with my electrical engineering team. So the electrical engineering team did their validation testing for a new patient cable assembly. This was a critical cable assembly within the defibrillator device that transferred shock from the battery to the patient. So they were uh pretty set on the components that they wanted to use for it. And it was my task to come up with a way to integrate it within the the device. You know, do all the wire guiding, make sure everything is held in place in in uh cases of vibration drop and things like that. And on top of that, I also had to like uh come up with a drawing for this and send it out to suppliers to get quotations uh for sample builds. So that was the official requirement uh from me at that uh stage. So I got to that level. I got the I got the thing modeled into the defibrillator how I wanted it to sit. I got the drawing done and then I sent out for codes and then I got u some codes from a vendor which looked pretty good and we approved it. So we wanted these sample builds from this uh vendor to come in within 3 months because we wanted a we had a face gate for a prototype build. Um so and that was our timeline and then two weeks later this uh assembly uh this cable assembly uh supplier he came back to me and said uh there was an issue with one of the wires that we used in our assembly and there was like a six month lead time on it and that and he proposed an alternative to see if we could he could use a different one. Um, so me being the one uh, you know, like Julia as this with the supplier. So I reached back to my electrical engineering team to check if they would be okay with this new cable assembly or if they had any other alternatives in mind. And um they came back to me and said they had already validated um that the wire that they wanted to use and they were not in a position timeline wise to like run through a different series of trials with it and they wanted to stick with what they were initially wanted to use. So I then reached out to our internal procurement uh and buying team within Phillips to see if they had any contacts with the manufacturer of this wire directly. And while they did not have any direct leads with this manufacturer of the wire, what they told me is there was a different product division within Philips uh the ultrasound uh scanning division and their product used the same wire from that company. So I I got that information and then I reached out to the mechanical engineering lead for the ultrasonic uh scanning uh product and I explained to them the situation we were in and I asked them if we could use their existing leverage with the manufacturer to source some of that wire for our prototype builds and they were happy to help. Uh and then I got the ca the cable assembly supplier and this wire manufacturer. All of them lined up with our procurement team and made sure that wire came all the way down from the manufacturer to our supplier and then they built it into assemblies and send it back to us within the 3-month timeline that we initially wanted them in. And one other thing this also this whole thing uh also helped set up is a better workflow uh internally within flips for teams to uh reach out and you know help with resources uh like cases like this if they ever happened again after that which was something we never really did before that we all had our own good example like how you actually operationalize you might need for the contracts folks. They connected you with that other team that could you know that effectively is using the same wire so you're able to leverage it which is great. How do you kind of make that a common practice within a company so that you know you get the sort of economies of scale that fits without you know looking at individual projects. Yeah. Um I think that was um you know one one like one of the hurdles of medical healthcare which is uh each product wants to individually wet their own suppliers and vendors uh and manufacturers before they get in business with them. Uh but in this particular case uh since this was a this was more of a prototype and R&D level build we were able to like bypass that uh and make this connection happen. Uh but what this process really set off is is the fact that you know like trying to start a conversation about uh making some of these uh supplier and requirements within our own systems uh to like smoon them out so that we can have more interplay within uh the other Philips functional teams. So it's something the quality system people are working on to make it easier. But at least this was an instance where we clearly showed to them with proof that there are cases where this will help us uh uh absolutely if we can you know work past this hurdle. Yeah. What I guess um your last question on this one is so you you got the initial time from the supplier for six months but you're trying to get the prototypes done in three months had you not got pursued this path what would the six months have been acceptable within the organization like what what would have happened had you not and gone about I think um it could have gone two different routes um I think I don't think six months would have been acceptable at that stage more likely what we would probably done is the electrical team would have had to go back to the drawing board work out u alternative wires of different require different um properties if they could use any of that and uh they had to validate it and they had to also run like a signal noise test an EMCMI testing is what they called. So this could have led to a series of uh additional testing which would have costed both time and effort of at least up to a month or two to get another buyer qualified. And this is a team you already gone to, right? So they already said no. But you're saying that if push came to shut, they would have had a choice but to sort of qualify the new Yeah, they would have had to probably qualify the new wire. Got it. Okay. Thank you. Um, we'll keep going. So, I'm looking for another example of a time when you were not um you're not able to meet a commitment in this case. So, so this is really about um you're working on a project, you miss a a commitment and how you uh how do you correct that, right? How do you sort of um maybe you know work with peers working with the manager um you know how do you how do you sort of prevent it having a bigger impact on the organization. Um, so I can think about a time when so as I was the um ME team's reviewer for some of these high level performance documents, uh, one such document the systems team put out was uh they were running behind schedule and they were trying to rush this document out as soon as possible for a necessary phase gate deadline and they sent it out to me for review on a Wednesday and they scheduled the final approval signoff meeting on a Friday. Um and with my experience I knew this was a pretty complex document. It was like 80 to 100 pages long and it needed uh very thoughtful input uh including coordination from some of my other mechanical engineers and I quickly realized you know I would not be able to meet the expectations of this sign off date uh that they're requiring me to do. So my task here was to maintain the quality of the review while also avoiding unnecessary delay to the project and I needed to manage expectations uh keep my team in aligned and also ensure that we didn't just sign off on something incomplete or inaccurate. Um so something along those lines and the way I went about it is uh first I reached out to the author of the document and I explained to them why I would not be able to complete this within the given timeline you know especially without a full uh teamwide uh meeting about this and make you know like before all of us got on the same page about some of the critical components in there. So he pushed back initially and escalated it to our uh PM and suggested that the Emmy team was holding up the progress on this document. And then when we had a conversation with me, him and the PM, I I tried to explain why this needed a more thorough review and timeline. and I was ready to spend um so that was a Wednesday and and I told him I was going to attend the meeting on a Friday uh give my comments but I would not be ready to sign it off yet and I was willing to spend some more time on it over the weekend to catch up reading on it and try to comm coordinate with my other ME folks meanwhile to get all of their inputs and would be ready for a sign off early next week. So after that uh a bit of um back and forth discussion uh the author kind of agreed and they rescheduled the approval meeting to early next week and then we used the extra days to align across our team in in the ME team and as a result we actually ended up um we found some critical elements in there which we flagged and which had to be corrected. uh so it was worth delaying the document slightly to ensure the quality of the work and I think um yeah um that's that's kind of how we went about it. So it was about a two-day delay but if had we not have caught that at that point of time it would have led to a either a design issue or a revision issue much later down the line. So, um that's that's kind of how um it went. So, I mean it seems like you're not given a whole lot of time. Um what was the urgency? What was driving occur? And you know, if you look at it from that, do they have justification for you know asking for review? Yeah. So their justification for it was that um this was a living document that has been in draft for u a week or so at that point. So they were under the understanding that you you've had over a week to like start going through it. You don't have to like go through it right when it's done. Uh was the argument that the author was coming up with. But really their timeline pressure was that um they were underst staffed and they were like running behind the clock to get this uh over the line. Uh and this was tied uh to a phase gate for us uh when we had to move from like a PLC to a PDC. Uh so this was the team that was kind of lacking behind with rest of the other teams. So that's kind of their push to like get it out of the way as soon as possible. Got it. Okay. I mean, you know, like without being in the situation of just judging from the outside, it seems like kind of a mess up on their side and they're just trying to push it through now and make it a bit of your problem because if you're reviewing a live document, well, the expectation is is changing. So, you could have been reviewing things that are not complete, right? So, you would have been feedback. So, seems like like an excuse on their side. Is that fair? Yeah, that's kind of my understanding of it. You I mean, I know it's in review. I know it's based off of a legacy document, so they were under the expectation that, you know, I'm not reading this as a fresh document from the get- go, but I have a I've already been through this. But yeah, like you said, you know, like if it until it's not done, it's not done. Especially something which is so critical and which will like dictate how design requirements flow down later to us. Yeah. Yeah. I think last question for me. I'm looking for an example where um you went along with a group decision um even if you disagree with it, right? So, you know, often times you can you have a you have kind of a fundamental point where you're disagreeing with a decision that's been made. You can vocalize your disagreement, but at some point you might decide you're going to move ahead with the disagreement. I'm looking for an example where you disagreed but decided to go along and help me understand why. Yeah. Um sure. Um yeah. Um I can um talk about a time when during the early stages of um design and conceptualization of a defibrator that I was working on. I was working with my industrial design team on the device outer seal and handle. So these were like two prominent features uh on the outside of the device. One of them was like a water ingress seal that ran around the device and one of them was a rubber handle. So the ID team u they strongly pushed for a unibody elasttor design. So they just wanted both of these two components to be a single body without any witness lines separating them. um mainly because it looked sleek and for like a seamless uh aesthetic, visual aesthetic. Uh you know, and it made sense when I looked at the renders. It looked really good. Um, but that raised some concerns for me from a manufacturing uh standpoint because the seal was about 3 mm thick whereas the handle was about 10 to 15 mm thick in areas. And that kind of uh difference in wall thickness uh usually causes some problems for compression molding which was the manufacturing approach we were going to take for this. So my task here was to balance uh the ID's uh ID team's design vision along with what was manufactur manufactur manufacturable in real reality uh and also making sure you know that was uh delivering the right amount of structural performance that we need from it without delays uh obviously without u you know like pulling things apart in too many directions. Um so eventually I needed the team support uh you know even if we didn't initially align on it. So the way I went about it is um at first uh I raised my concern to the ID uh about why this might be a manufacturing issue and then they pushed back on it and suggested exploring alternative materials or alternative molding processes um things like that. So instead of escalating the conflict at that stage, I took a more datadriven approach. Um first I reached out to my manufacturer uh to validate my concerns about this uh design idea and he pretty much he pretty much uh confirmed my hypothesis uh that this difference in wall thickness would cause uh material flow and dimensional instability issues. So after that I ran an FEA simulation to see what would happen if I tried to reduce the thickness of the handle and match it closer to the seal. Um but what that showed is that doing that um the handle could no longer support as much load as the requirements wanted to in terms of real life performance. So that would have uh not worked. So with all of this information in front of me, I'm I set up another meeting with our industrial design team and I showed them the my initial concept that I went with the manufacturer with the manufacturer's input on it and then my alternative uh concept and why this was not possible using the FA analysis. So with all of that in front of them, um it made that uh conversation a lot more uh constructive. You know, instead of like just pushing back on each other and just stating ideas and opinions, it was more of okay, together what kind of a workound can we get to uh how can we compromise to like meet both ends of this. So, and then um we worked uh about across that and we came up with a a clever assembly idea where it wouldn't look like it was two different parts if you looked at it from a a distance unless like you're holding it really close to your face. Uh but it still served a function that it was two different parts. Uh both did not cause any manufacturing issues and both were performance uh stable. So that's kind of how we uh preserved both functionality and the goals. Um okay, got it. Cool. Um I'm just getting through. I don't I think we got through all of my questions pretty efficiently. jump back on video and uh let's see what questions of yours I can answer. Um so yeah, I'm curious. So you said you work on the software side of things. Um so you work like in kind of like software for the the direct uh robotics that this and solutions that this reliability team is working on. Not really. So I'm I'm from a completely different group altogether. Um the way to think about my team is that we so we build entire robotic systems for our fulfillment centers right watch tons of videos on how work there's a fair element of human decision making that needs to go into that right so I think kind of system dynamic as opposed to a completely closed loop robotic system so my team builds the software for our maintenance technicians our operators to understand kind of how to think about the right decisions at the right points so really they're We're helping them make decisions about how to not constrain the system as like a at a macro system level as opposed to the individual robots at all. I see. And um so I was going to ask you, so I mean I'm I'm speaking with a lot of Amazon personnel obviously in this interviews and everything and they've been telling me good things about it, but I have a question. So what is something that you wish Amazon, you know, like in your workplace you did differently or something you can improve on? Yeah, I think what's happened I've been here a long time. So I think one of the things I see is that uh you know generally we operate like a startup and a lot of what positive things you hear I think are very true. Unfortunately, what happens as that organization gets bigger um and you know there's issues that people are trying to fix. Sometimes we introduce too much process and sometimes we introduce almost we overcorrect for things um and so the amount of administrative burden can get out of control, right? And each thing in isolation makes sense, right? Have a problem that you run into when they're like, "All right, fix this. who are going to have a review every time you create this kind of a a document or create this type of a process and in isolation they make sense but in aggregate they don't make sense. So sometimes you know you kind of you there's a tendency to almost overcorrect on things without taking a step back and asking questions of like how often does this actually happen and how much process do you need to place you know in some cases and I think that's just a function of how big we have become and how many people we have and how many things come up ad hoc right so um I think I personally would like to see us get back more agile uh scrappy as opposed to like overly processor oriented and it's a function of I think we bring a lot of people from big industry you know big companies that that come in and they're like hey you guys are doing it all wrong you know when I was at such and such company we had all these processes that would prevent this from happening and I think what those folks miss is that we work at such a high speed compared to other teams other organizations that something that we build within you know a 9 to 18 month period would take 5 to seven years in industry So as when you start to introduce those processes and they make sense, yeah, you sort of lose the forest for the trees because now too much time is being added to the projects, you know. So that's the the thing that I think I would like to maybe see improve is not overburdening us with administrative work because we're trying to correct too many problems at scale. Got it. Yeah, that that makes sense. I can share your sentiment on that. uh but from a slightly different setting you know like uh we have a medical device company but we uh it's being led by non-medical device uh management sure and you know that often times can cause some mismatch in expectations timelines uh things like that so yeah I can feel that it would be nice to you know like to have everybody aligned on and you know set up in a streamlined manner. Yeah. And you know, you have to strike a balance, right? Like there are times when process makes sense. There are times when we can do things better. And I fully acknowledge and I think we should all acknowledge that you want continuous improvement, but then you also want to know when you reach the point of diminishing return. Want to go beyond that. And I think sometimes like that uh that line is not always clear to folks. So it's just the reality of a growing growing organization. were much bigger than we were 10 years ago. Got it. No. Yeah, that makes perfect sense. Yeah. Um I know you got you got anything else for me? I think those are No, I think we're good. I think you gave me some good examples and I think that you know I always look for consistent patterns and I see uh I see those in your example. So I think uh I think I got everything I needed. Um and uh yeah. No, I think uh I think you still have a couple more interviews. Yeah, I do. Yeah. Yeah. Two more. Excellent. Um, yeah. Let me see who else you're meeting with just sort of what to expect. So, you already met with Patrick. I have. Yeah. Good morning. Patrick and I used to share an office many months ago. So, you still have I think uh let's see three interviews still. So, uh I think the last person you're speaking speaking is Sabi. He's the only one I know in the group that you're meeting with. But uh should be should be a lot of fun. Uh I wish you all the best with the rest of the interviews. Good luck and uh we'll get back in touch after you've met with everyone and we've had a chance to Yeah, absolutely. Of course. Yeah. Thank you so much, S. This has been a really nice fruitful conversation. I think turning off the camera kind of helped in a way. I don't know. This felt like a more peaceful setting like I was just talking to myself. Yeah, it's sometimes I leave the camera on. I do find sometimes it can be distracting for the the interview. So glad that worked out. Yeah. No, I think you know we're trying to multitask here. I was taking notes and I sometimes like looking all over the place. So I find myself looking weird on camera doing that. So but yeah, good luck with the process and uh we'll be in touch. All right. Thank you so much. You have a great rest of your days later. Bye. Bye. Bye.
Share:
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
How It Works
Copy YouTube Link
Grab any YouTube video URL from your browser
Paste & Extract
Paste the URL and we'll fetch the transcript
Use the Text
Search, copy, or save the transcript
Why you need YouTube Transcript?
Extract value from videos without watching every second - save time and work smarter
YouTube videos contain valuable information for learning and entertainment, but watching entire videos is time-consuming. This transcript tool helps you quickly access, search, and repurpose video content in text format.
For Note Takers
- Copy text directly into your study notes
- Get podcast transcripts for better retention
- Translate content to your native language
For Content Creators
- Create blog posts from video content
- Extract quotes for social media posts
- Add SEO-rich descriptions to videos
With AI Tools
- Generate concise summaries instantly
- Create quiz questions from content
- Extract key information automatically
Creative Ways to Use YouTube Transcripts
For Learning & Research
- Generate study guides from educational videos
- Extract key points from lectures and tutorials
- Ask AI tools specific questions about video content
For Content Creation
- Create engaging infographics from video content
- Extract quotes for newsletters and email campaigns
- Create shareable memes using memorable quotes
Power Up with AI Integration
Combine YouTube transcripts with AI tools like ChatGPT for powerful content analysis and creation:
Frequently Asked Questions
Is this tool really free?
Yes! YouTubeToText is completely free. No hidden fees, no registration needed, and no credit card required.
Can I translate the transcript to other languages?
Absolutely! You can translate subtitles to over 125 languages. After generating the transcript, simply select your desired language from the options.
Is there a limit to video length?
Nope, you can transcribe videos of any length - from short clips to multi-hour lectures.
How do I use the transcript with AI tools?
Simply use the one-click copy button to copy the transcript, then paste it into ChatGPT or your favorite AI tool. Ask the AI to summarize content, extract key points, or create notes.
Timestamp Navigation
Soon you'll be able to click any part of the transcript to jump to that exact moment in the video.
Have a feature suggestion? Let me know!Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.