YouTube Transcript:
Amazon interview 2

Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.

AutoDub

Understand YouTube Foreign Videos

Immersive YouTube Voice Translation

Break language barriers, embrace global quality content

Solve Foreign Video Barriers Instantly

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.

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.

Click on any text or timestamp to jump to that moment in the video

Most transcripts ready in under 5 seconds

One-Click Copy125+ LanguagesSearch ContentJump to Timestamps

Paste YouTube URL

Enter any YouTube video link to get the full transcript

Most transcripts ready in under 5 seconds

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.

Add to Chrome — Free

Works with YouTube, Coursera, Udemy and more educational platforms

Get Instant Transcripts: Just Edit the Domain in Your Address Bar!

YouTube

←

→

↻

https://www.youtube.com/watch?v=UF8uR6Z6KLc

YoutubeToText

←

→

↻

https://youtubetotext.net/watch?v=UF8uR6Z6KLc

YouTube TranscriptPreparing your results…