YouTube Transcript:
Amazon interview 2
Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.
Share:
Video Transcript
View:
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.
Click on any text or timestamp to jump to that moment in the video
Share:
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
Transcript Extraction Form
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.
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