We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free
interviewing.io

An Interview with a FAANG engineer

Watch someone solve the behavioral interview problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Behavioral Interview

Interview question

1. Can you describe a time when you made a mistake at work? How did you handle it, and what was the outcome? 2. Give an example of a time when you had to understand and work within the constraints of a project. How did you navigate these constraints to deliver value? 3. Describe a challenging problem you faced and how you approached solving it creatively. 4. Can you share an example of how you've mentored a team member to help them improve their technical skills and communication?

Interview Feedback

Feedback about Ultra Automaton (the interviewee)

Advance this person to the next round?
Thumbs upYes
How were their technical skills?
3/4
How was their problem solving ability?
4/4
What about their communication ability?
3/4
Overall: Great story! You clearly have the communication and project management skills to solve unique problems and put a "bow" on the project. I would just practice your story 10-20 times to get it concise. That's really the main blocker. 1. Can you describe a time when you made a mistake at work? How did you handle it, and what was the outcome? - Estimation problem - did not account for onboarding time, realized scope on day 2 - Went to manager and gave new estimate - Next time: account for other elements, paper trail for communication, gathered info you find in one place from learning (docs) for outdated code base - Looked for workarounds for how to set up environment due to blockers - Be clear about timelines for setting up and each tasks Suggestions: - Rephrase “leave a paper trail” to “collect documentation from what I learned for future use” 5. Give an example of a time when you had to understand and work within the constraints of a project. How did you navigate these constraints to deliver value? - Working with sister teams to check timelines and share resources - Instead of sharing an engineer they had existing systems - Identified bottlenecks - Find middle ground on timelines - Resolve conflict: ask for time to catch up, go through design document, ask for timeline, first meeting might not have answer, they would go back and explore with their team, get their timelines, - How to handle: gather all information and let manager handle it Suggestions: - Make more concise: how you handle start to end 7. Describe a challenging problem you faced and how you approached solving it creatively. - Realized that test load did not match LB usage - Identified pattern - during deployment - Searched other teams having a similar issue - Outside the box solution: reached out to AWS support, usually don’t do this Suggestions: - Highlight this is eng culture not to reach out externally 3. Can you share an example of how you've mentored a team member to help them improve their technical skills and communication? - New intern, wasn’t sure how to communicate in a corp environment - Made sure he was comfortable to reach out - it’s ok to ask questions and be wrong, build confidence - They feel pressure - if they want to convert to FT, they have to “know their stuff” - How to looks for answers - internal resources, slack, resources to help himself - Archetype - Tech Lead - Breaking down a project, convert product to eng - make sure they are aligned - How do we get to production - alerts and other “put a bow on it” - Does a system already exist in our company - Solver: dig deep, explore all resources, ask seniors - they are excited to solve issues Suggestion - I like “put a bow on it” - Others are excited to solve complex issue Story based on archetypes - Very unique product - selling a car on amazon - Many teams involved - Looked into similar problems - groceries - Wrote design - We can not call the project done until… (encryption is addressed, alarms, certifications, business mentrics, reviews by other team) - List statuses - did they return at the dealer, email notifications (unique problems), Suggestions - Made mistake: start with how you made estimation mistake, how far you’ve grown - Cut first part, focus on unique problems GENERAL - Come up with stories, you can integrate stories

Feedback about Deliberate Pumpkin (the interviewer)

Would you want to work with this person?
Thumbs upYes
How excited would you be to work with them?
4/4
How good were the questions?
4/4
How helpful was your interviewer in guiding you to the solution(s)?
4/4

Interview Transcript

Deliberate Pumpkin: Why don't you tell me a little bit about yourself. What kind of role are you going for? A little bit on your background and what are you looking for in this session? Do you want to get more tips? Do you want to just practice questions? Yeah, let me know what sounds good for you.
Ultra Automaton: Yeah, of course. So a little bit of background about myself. My name is Viha and I've been actively interviewing because yeah, like my company, they decided to shut down our team here. So yeah, I've just been like looking at other options and hopefully land something this year. So yeah, my. And yeah, like I mentioned like I do have an interview on Friday with like a dedicated 1, 1, 1 like 45 minutes slot of a behavioral round. Usually like in other companies they have a behavioral round integrated as part of like the interviews in itself. Right. Like for example Amazon, they, they have like a leadership section within each tech interview. But here like this is a dedicated behavior and I've never practiced a behavioral run and I'm not really sure like where I stand other than my own judgment of myself. So I think like getting a review, getting some tips especially for the behavioral round would be super useful. And yeah, I actually have about like four years of experience as a software engineer and the role that I'm interviewing is for a backend engineer. Basically like my experience has been as a backend engineer for the past four years and so the role that I'm interviewing for is also for a backend engineer. And yeah, I'm interviewing for stripe. And yeah, I was, I was or am with Amazon. So now I'm shifting and like looking, looking for other options outside. Yeah, like I have a bachelor's in computer science as well as a master's in computer science. And yeah, about like four, four and a half, five years of experience as a software engineer. Yeah, that's that's about myself and I think like again just reiterating like I behave like other than my own self judgment, I'm not really sure like how or where I stand in terms of like a behavioral round and what like managers or like what a hiring manager looks for during these, these rounds. So I guess like a good like yeah, just like good tips and like if we could spend some time just practicing also would be nice. So maybe like that way I can get like real time feedback on, on, on what I can do, like what I can improve. And I think like yeah, just in terms of like nerves as well, like before an interview. I think this, this having like a mock session will help there. Yeah, I think that's, yeah, that's a little bit about myself.
Deliberate Pumpkin: Awesome. All right, so in that case, probably what we can do, I will ask you a question and based off that you'll give an an and I'll give a little bit of feedback and tips. How does that sound?
Ultra Automaton: Awesome. Yeah, I think that sounds good. I can do that.
Deliberate Pumpkin: Great. Okay, so question number one. Can you describe a time when you made a mistake at work? How did you handle it and what was the outcome?
Ultra Automaton: Shoes A time where I made a mistake at work. I'm just trying to recollect if anything pops up in my mind. Yeah. So most recently I was, I was given a task where like this is a completely new code base and I only had like 15 days of time to get like 15, like I was okay, yeah, sorry, let me just restart. I'm just like recollecting my thoughts. So yeah, like my most recent project like this, I had to work on a different team's code base to get a task done for us. Like basically like we. This was a dependency on another team and they didn't have the capacity to get that done. So I worked on this as an awaiting effort. And so this was a front end work and most of my experience has been as a backend engine engineer. And this like I think I'm like short. Long story short, the mistake I made here was in terms of like effort estimation. I was working with a fellow engineer from their team who had like a document written in terms of like, oh, how much would the effort look like to get to get this task done? And just brushed over the things with him like okay, what are the to do's and like what do I have to do in terms of like, you know, to get the stuff done? And this effort was estimated to be 15 days. But then the mistake I made Was not realizing that this did not one, this did not account for like the onboarding time that I would need to understand the code base and understand the new. Especially because this is front end. Like I had to get like, you know, get accustomed to the different frameworks that they were using. I did not account for the timeline there. And there was another thing where like I took their word for it instead of like going back and researching on my end before confirming that this can be done in 15 days. So I think that was one mistake that I did. But like quickly when I, I quickly realized this when I started onboarding like I think like day two, I realized like this is not a 15 day effort and even for somebody who had the experience to get this done, this is definitely not a 15 day like effort. So I went back to my manager, discussed this, made sure that he was aware like showed the show the errors especially because like even the onboarding and like setting up the code base, the instructions were not, were not right and getting, getting this set up in itself was going to longer than they had estimated. So I think that was a mistake and like moving on. I've learned from this and I take my time to give out, give out efforts and estimates. I don't just. Yeah. And I also make sure that I do my deliberate effort in terms of like you know, researching and making sure what's being given to me is as accurate as described by them. So I think this and also like making sure that I have like a paper trail of communication to go back to in terms of proof or like verification. I think that was one good thing that I did during that time because like there was a, like we tracked these issues in a sim and like there's a conversation going on there and I made sure that I kept that updated with the latest information of what was going on. And that kind of helped me go back and like show, hey, this is the, this is what was said, but this is not true. This is, this is what's going on. And I think like keeping a paper trail there helped. Yeah, I think that's, that's my quick answer.
Deliberate Pumpkin: Gotcha. Can you tell me more about how the paper trail helps and what type of issues does it specifically help you with?
Ultra Automaton: Yeah, of course. So the major issue that I had was trying to set, set up an environment, right? Like setting up my. In order to make sure that I'm able to like test any changes that I make in beta and gamma environments. And so they had provided a Wikipedia page that, that gave the instruction to Setting this up, but that was like pretty outdated. And when I, when I began setting this up, I quickly realized that this document was outdated and like the instructions were not right and most of the code base was, was lagging. And they also had like only one engineer who was aware of like the entire code base. So like the content within the code base. So I, yeah, I left these messages in there like, hey, these instructions don't seem right. This is not working. And I have so and so errors. Like, you know, can I, can I get some more help? Like have you seen these on your end? And in the meanwhile while I was waiting for their response, I also had these slack groups where anybody who's trying to set up these like JavaScript or like a beta and gamma environment to test these front end, front end setup, I reached out there as well and I noticed like a couple of people were having the same issues there. And like this is. And then yeah, turns out that this is going to be a hard blocker because there's no solution to it. Like this is just like outdated code base where like, like support for this was no longer out there. So then I need like, then I reached out to them like, you know, and because there was no response from them yet, like I made sure that my manager was aware, tagged them in the sim, basically the issues that we were tracking. And yeah, I also made sure that their manager and my manager was aware of like the issue going on. Like left the left. I also left messages of like, hey, this is, this is the issue. Looks like this is going to be a hard blocker in terms of like testing this front end. Like, are there any other way that I can set this environment up? Are there any other way that I can, you know, take a look at. So there's like timestamps of when like what was. So there's also a timestamps of hey, like this, this is what was agreed on. Like number of like these are the to dos. Like basically like four or five features that I would have to add as part of this task. And the timelines mentioned like how long it would take for me to even like set up the environment. And I mentioned that hey, just setting up the environment which was allocated to be like a day is, is not true because waiting for permissions from other teams, that in itself was taking like two or three days longer. And I took an like digging deeper, I took a look at the code base to see like, you know, how long their efforts would take. So like, so this task was actually to make sure that there was a calendar UI and we had to make that accessible. So basically adding keyboard navigation and making sure that the speech, like the text to speech software is able to identify components within the calendar and like read them out loud. To read them out loud. And I quickly noticed, like, for that to happen, there are some coding standards that should have already been part of the code and I would just have to add like certain features on top of it, basically, like add tags and things like that. But this code was, did not maintain those standards, which meant, like, I would have to make additional relevant changes to that code base, which was outside of the scope of this task. So I quickly realized that in the day or two and I mentioned like this, you've estimated this to be two days, but that's not going to, that's not true because, like, there's other dependencies that we will have to ensure that happens. And I, and I left a paper trail with links to these codes with links to any online resources that I found. So yeah, so yeah, leaving that paper trail helped.
Deliberate Pumpkin: Gotcha. Okay, so a little bit of feedback. You phrased this as leaving a paper trail. Leaving a paper trail. It can have some negative, negative connotations. Like what I think of when leaving a paper trail is essentially gathering information where you can assign blame to somebody else. Like, that's the context I usually hear leaving a paper trail used in another way that you could phrase the same thing based off of what you described is, you know, I'm gathering the documentation in one place for future use. So when you phrase it that way, it's more of like, you know, hey, this is a messy code base. But I'm going to gather all this stuff that I learned for future people not to have the same problem as I have.
Ultra Automaton: Okay. Yeah, yeah, that's actually good. Yeah, good way to phrase it for sure. Because that's also part of what I did, like writing a document and writing like. Because I did go back and write some. My learnings on how to set up this code base. I wrote like a document and how to get the code base up and running. Like, how do we test this in beta and gamma environment with the old stuff not supported anymore? So yeah, I think that was a good point that I should have brought up. Thank you for that feedback.
Deliberate Pumpkin: Yeah, a lot of stuff is all about phrasing. Like you're literally saying the same thing but in different words.
Ultra Automaton: Yeah.
Deliberate Pumpkin: You know, in corporations, people, they take certain phrases a certain way and eventually just learn which ones to use.
Ultra Automaton: Yeah, yeah, that's True.
Deliberate Pumpkin: Just make a note for myself if you were to.
Ultra Automaton: So I, I, I just like had a quick question like, is there, is, is there a way for me to like, you know, I guess like form. I know the stop pattern is what people usually suggest. But like beforehand before a behavioral interview, like can I come up like, is there a way for me to like come up with like a list of topics that I can talk about for these questions that are going to be asked? And like what are your recommendations in terms of like what kind of topic should I, I guess like should I have or like prepare for in advance?
Deliberate Pumpkin: Yeah. So how I recommend doing it is you come up with maybe three or four stories from your career that really, you know, show like what you have done. So for example, I usually take about three projects that I worked on and they really showcase a few things. Let me actually I have a list of what we want to show. Do behavioral. Okay, so here's basically what we want to show. The first thing is handling challenges. So that's the first question that I asked you. Like when you make a mistake, how do you handle that mistake? When you're stuck on a problem, how do you handle that problem? So that's handling challenges. The next one is going to be mentoring and team building. So you talk about how you have helped your co workers and how do you unblock your co workers and also you talk about your mentors and how you learn. Okay, the next one is communication. Okay. And we could go through the rest. Yeah. Okay, cool. Any other questions for this?
Ultra Automaton: No, I think for now I'm good, thank you.
Deliberate Pumpkin: All right, let's give this one a shot. So communication and diplomacy. Basically what you want to do here is show your communication skills. So for example, in the story that you told, you might want to elaborate on how did you have conversations with the people who blocked you. So a typical question that gets asked is give an example of a time when you had to understand and work with constraints of a project. And how did you navigate those constraints?
Ultra Automaton: Okay, constraints of a problem.
Deliberate Pumpkin: And usually when we're talking about constraints, it could be time, it could be resources, knowledge. You have blockers, you have.
Ultra Automaton: Okay, yeah. Okay, let's see. Constraints is a common. How did I navigate through these constraints? Okay, so I'm just trying to think of like one project that, that I can help answer this question. So part of my work was basically like to, to build a system where. Build a system that can be a one stop place to track a status of an order. So basically like orders at Amazon, right? Like they are, they are owned like a status of an order is owned by various teams within, within Amazon. So like if an order was created, the payments being processed, refunds, cancellations, these are different statuses of an order they handled. The intricacies of how these are handled are handled like they're handled by different teams across Amazon. But then for our team we needed like one stop place where we can confirm like okay, this, this order ID was for our product and, and like you know, have an internal system instead of like having having us on board to these multiple systems again and again, but just have like one, a one stop place in like an internal team system that has already made this onboarding process and it's easy for us to like, to subscribe and like learn. Okay, what's the status of an order for this order ID at this particular timestamp? So the, so the complications here is like we had a defined timeline, right? Like this is by, this is when we had like a beta launch that is upcoming. And by this, this is the time that we needed to get this out. But the complications here is like when we have like multiple teams that we have to depend on, how do we align our timelines with their resources and their, their times, right? Like how do we align there? So the one thing that helped here was like this was an SVP goal. So like there was already enough pressure from the higher ups and we knew okay, this is an important project so we could like one, we could leverage that. So we began like a friendly conversation as an exploration. This was the idea, like this is what we have to get done. So we began a friendly conversation with these three or four sister teams to understand what their timelines looked like, if they had resources available. How do we make this work? Took a design document from our end, went to them and be like, hey, this is the design, this is what we're trying to achieve. Are there any resources already available on your end that we could leverage without having to need a dedicated resources from their teams or not having to utilize their time? And luckily they gave us a bunch of documents for us to go through to read and understand how we can make this happen without their intervention, without utilizing an engineer from their team. I think that in itself helped. So it turns out this kind of requirement had come from like there were a couple of teams where these kind of requirements had already come in before. So they had a system where you could just like easily, you know, get permissions to the VPCs, get and then like just subscribe to their SNS topics and that gave us like these statuses. But there are other teams who did not have something like this already existing. And there we needed some more effort. So that's when like, so this is where we like, you know, came up or like came up with the bottlenecks. These are the bottlenecks. This is where we have to spend some more time. How do we, you know, how do we make this work? And then like we like, we worked with their teams, discussed the timelines or discussed like what is a possible timeline from there and that we can make this work and can we align on, can we come to a middle point? Hey, this, this does not work. This timeline that you're saying does not work. Like, can we, is there another way that we can work? That we can work? And then we decided to like, okay, we're going to send an engineer from our team to make this work, like, can we get some kind of support? And then that's when we decided like on a, on a middle ground, on a middle timeline that, that worked for both our teams. So I think, yeah, this is one way that, that we've helped navigate constraints especially in terms of like timelines and resources. Yeah.
Deliberate Pumpkin: Gotcha. And what was an example of a conflict that you had where you couldn't find the middle ground at first, but eventually you work through it. Like take me through one of those conversations.
Ultra Automaton: Okay, sure. So at first I, I ensure like I didn't want to leave like just Slack messages too. And then like basically you get a point of contact from their team. So you know, reaching out through like I want to have like a friendly conversation even before we get into work, like, you know, get to know each other, have a friendly conversation and then move, move on to the actual work. So one, I would usually just reach out to them through Slack, like, hey, how's it going? And my name is Biha and I'm from this team and like this is, I just want to see like if you had some time to, to catch up. And I would wait for the response. If the response back was slack, it was great. That means, you know, they had the time and then like I would continue the conversation there, set up a meeting with them, a one on one meeting with them and, and then like go through my design document explaining like this is what we're trying to do and you know, what's your timeline? And a lot of the time the first meeting wouldn't come, you know, have definite answers. Instead it would be more like an explanation for them as well. They Would go back with the design document, with our doc, with our requirements, and explore within their teams as well. Like, what, you know, what we're requesting? Is that even possible? Or, like, how would that work in terms of finance for that team? And then we would have another team, another. And then I would set up like another meeting after a day of revision, and then when they were ready to come back to us with their requirements and with their answers, and I would take those and they'd like, hey, in order for us to get this feature done, we have this available, but we don't have this available. So I would write that down in a Wikipedia page and basically in a document of, you know, for this feature to happen, we, like, these are the gaps, and these are the timelines that's needed to cover. To cover these gaps. And then I would learn from them, like, is this something that they can do? Is this something that we can do? Like, how can we help from our end to cover these gaps? And if they were open enough for us to, like, you know, come update the code base in order for us to get this feature done, Like, I would note that down and I would also ask, like, a rough estimate from their engineers, like, okay, how long do you think this would get done for somebody who's like, coming and working from another team? Or is there, like, is this already planned in your, like, quarterly goals? Like, is this already. Is this something that you plan to get done? And if they had that information, I would note that down, like, write down their timelines, and then I would collect that document, go back to my team, have a discussion around these timelines, what works for us, what does not work for us. And. And then, yeah, gather those thoughts with the product manager, with our managers and our, like, my. My peers. Grab those, and then go back to the engineers and go back to the engineer from their team again, have a meeting. And then then essentially, like, when it comes to, like, two different teams and resource allocation, I would let the conversation be taken care by my manager. Like, I have now provided the information that he needs in terms of, like, what's the gaps needed for us to get the stuff from point A to point B. And then. Yeah, and then this would enable my manager to continue the conversation with their team in terms of, like, resource allocation and like, can we do the survey team work? Or, like, can their team do the survey team work? Yeah.
Deliberate Pumpkin: Gotcha. Let me just finish taking those. Cool. So the last thing that you said, it's very important. What I heard was you, your job is to Gather all the information needed for your manager to negotiate this kind of project. There are a few ways that you could phrase it better. Yeah, I would basically make this answer a little bit shorter. The important part is basically how you handle this conflict from start to end. So what I heard was you ask for time to catch up, you go through your design document, you ask for their timeline, and you might not have an answer in that first meeting, but they go back and explore with their team, and then you get their timeline and their details. A lot of times they don't have resour that they could share, but they might have an existing system which would cut down on a lot of work. You also work to identify the bottlenecks. And once you have all that information, you basically detail everything that you need, you give it to the manager, and they help actually figure out how the teams will work together. So, yeah, I think that kind of story, especially if you make it concise, is a really good story.
Ultra Automaton: Yeah, yeah, that's a good point. I think, like, I should, like, I think in terms of system design, you say scoping down my thought process, I think that that kind of would have. Yeah, I could have summarized this and.
Deliberate Pumpkin: You could practice this a lot. Yeah, yeah. Like once you tell this story like 10 times, 20 times, you basically know those key parts, and it becomes a lot more concise and easier to tell. But that ending part of you gathered everything needed in a nice little packet, and then the manager is able to use that packet to move things forward.
Ultra Automaton: Yeah.
Deliberate Pumpkin: Cool. Good job.
Ultra Automaton: Okay.
Deliberate Pumpkin: All right. So the other thing that we're looking for is creativity. Describe a challenging problem you faced and how you approach solving it creatively. So there's a concept called perpendicular solutions. So a lot of times you have a conflict. So, you know, there you. It seems that there's a problem that you can't solve. Like there's a technical block, a resource block, some kind of inter team block, but then you take a perpendicular solution where it's not a black and white problem, and you solve this problem using something outside the box.
Ultra Automaton: Gotcha. Okay. Yeah, I can. I can talk about this. So. So this is like pre release, we were prepping to make sure that our systems are all aligned and we are prepared preemptively in. In terms of like monitoring and alarms in case of thing, in case anything goes wrong. And. And like during. So part of this was we were also doing load balancing. And during load balance, like when my fellow engineers was doing load balancing, I was on call and I kept seeing these latency related tickets to that service. It's like, okay, maybe it's because of load balance, like, you know, because they're, you know, hitting the system with like, they're trying to test the system, hitting them, hitting it with like 50 tps, 100 tps to see how this would perform. Okay, issues with latency would make sense. But then what, what I quickly realized is this pattern did not match to the, to the load, to the load balance testing. But we like. And historically I just like to search the title of that ticket and I noticed there were at least 15 or 16 more of these tickets, which is beyond the timeline of the load balance testing what was going on. So what I did was quickly took a look at the timelines to see if I can pattern match this to something. So had just took the first 10 of them, wrote down the timestamps of like, okay, this is the timestamp of this when this was happening. And I noticed a pattern when like these lags or these latency issues were showing, was showing up every time and a deployment was happening while somebody was trying to make a request. So basically like while somebody's making an API request at the same time, if a deployment was happening in that, in that code base, in that setup and environment, this was when we were facing these. So it was showing up as latency, latency issues. And on digging deeper I quickly realized that we were not equipped to handle. Having latency issues during deployment is not great because this means that we would be blocked during like daytime usage when there's actual customer, customer data coming in and we have to make deployments. This would be a big blocker because our customers will be left hanging and not receive like a response to a request in itself. And I quickly realized that what they had stated in terms of like, so this was a project that we had received from another team because there was a, there was a transfer of projects and they had a document where they mentioned that they've set up auto scaling and that they've set up like the CPU utilization, the CPU usage, like all of this setup, but that did not reflect in the actual environment. So I guess there was a miscommunication, there was a gap. So updated that. But, but I still noticed a latency issue even after updating our code base to you know, increase the CPU and the memory turns. And then I realized okay, and, and I quickly used our internal resources to search through this error like search this issue that is going on. And like a couple of people had face these issues and then we had to think outside the box because like, turns out this was a non existing issue and we needed like a solution for us to get, get through this. Like not deploying during like customer awake times would, would not work because we, we are working across regions and across time zones. So that was not a solution. And I, so I decided to reach out to an AWS customer, customer service agent and try to get their help. And I think like this was one thing that we had never tried or like at least I hadn't tried on my end was to actually get help from the AWS team itself. Right. And turns out that they provided like a couple of to dos and kind of helped get this latency down during deployments. And yeah, just like long story short, like you know, reaching out to the AWS team or like reaching out to the AWS customer agent helped and they had an ongoing GitHub issue for this and like, you know, I interacted with them in this GitHub issue and you know, wrote down like my findings and the issue that we were having and then received suggestion from them from. Directly from the AWS team. So I think this is a good way for me to navigate this position.
Deliberate Pumpkin: Yeah, that's a good answer. For some reason. Yeah, we always try to solve things inside the company or I guess usually we try to solve things by ourselves. Maybe we reach out to other teams, but for whatever reason, very few engineers reach out to external resources. I'm not sure why. Yeah, but yeah, like you might want to give a little bit of background about like highlighting. This is like engineering culture.
Ultra Automaton: Yeah, yeah, that's true.
Deliberate Pumpkin: This is engineering to reach out externally. Okay, what's our next question? So there are a few other. Okay, mentorship. There we go. Can you share an example of how you've mentored a team member to help them improve their technical skills and their communication?
Ultra Automaton: Yeah, of course. So I had, so about a year back I, we had hired an intern and I was also looking to like get promoted and learn like, you know, basically grow within my own role and you know, having a mentee or like somebody that I could navigate through to get them like from point A to point B and like improve in their, like help them make progress in there in the, in the time that they are with the company would have, you know, helped showcase my skills as my mentorship skills as well. So yeah, he was, he was an intern, like just still in school, like second year school and who wasn't aware of like how. And this was his first professional internship experience. Right. Like, who wasn't aware of, like, how things work within. Within a big organization. Especially in terms of like professional fronts, like how do you communicate your issues? Like, how do you. And I think, like, I tried to apply my learnings and the issues that I had and try and see if I could help him there. Right. Like, what issues I would face, issues in terms of confidence and like, how do I like and being afraid of not knowing things when I reach out to my mentors. I think that was the biggest gap that I had. I want to ensure that he had. He was comfortable enough to reach out to me whenever he had any issues. Like where any problems are big or small. Right. Like, it's okay to ask questions, it's okay to be wrong, it's okay to fail because that's how you learn and come back in and learn and grow from there. So I think that was one important thing for me to communicate and let him know that it's okay to ask questions. And especially in like a team design discussion that are going on. Right. Like people are usually afraid to ask, oh, I don't understand this. Like, can you explain this further? Especially as a new engineer, especially as somebody who hasn't had any experience and who wants, you know, who wants this internship to be converted full time, they feel like there's a lot of stake and asking such kind of questions is not great. But I ensure that he was aware that it's okay to ask these questions, especially during a design document. Design document review. Because even senior engineers ask these kind of questions and it's completely okay. So made sure that he was confident in that terms. And I also like. So part of the way this internship works is I have a design document and I help my intern complete this to fruition. Right. Like this to production. So like my initial having. I had a design interview with him, ensure that he understood what was going on and ensure that he was asking me the right questions. And helped him. In the beginning, I helped him in terms of answering these questions directly, but also providing him the resources of how does he have to look for answers within our internal tools and systems? Right. Like, what are the resources available? Like, we had broadcast videos available. We had like a dedicated Slack channels, We had dedicated internal resources. I could like Wikipedia pages or Sage groups. I could ask a question and fellow engineers across Amazon would help like ensure that. Ensuring that he was provided with these resources and he could help himself. So I think this was like, this was my experience mentoring him. And he. Yeah, he did. He did a pretty good job at the end he, and so even during his presentation, he came up confident. He was aware of like every component that he had worked on and especially like the blockers and how he resolved them. And like, we also ended up converting his internship to full time just based on, based on his learnings and based on the results that he, that he gave us. Yeah.
Deliberate Pumpkin: Awesome. Yeah, this is a really good answer. There's not a whole lot that I would change there.
Ultra Automaton: Okay.
Deliberate Pumpkin: Okay, so then I have a few meta questions. So basically these are more about your strategy of how you build your answers in general. So have you heard of engineering archetypes?
Ultra Automaton: Engineering archetypes? No, I'm not familiar with that term. I think I might be, but like, I'm just blanking out right now. Yeah, I think I'll.
Deliberate Pumpkin: No problem. Well, basically what an engineering archetype is like, usually when you hire someone, you want to give them an image of like, this is my special skill. So, you know, they're interviewing probably like anywhere from 20 to 100 people for this position. And you gotta like say something that they'll remember. Out of all those people, there's a lot of qualified people. So for example, what my special power is is cross team communication. So I'm really great at figuring out, you know, who has certain answers, who's able to help, what their needs are. So whenever I interview, I highlight like, hey, I am the person. If you need somebody to solve cross team communication problems, hire me. And the thing is, I won't fit every single job, but the ones who are specifically looking for that skill will be like, that's my guy. So there's a few archetypes. There's a book on staff engineer archetypes, and they outline four categories. The first one is a tech lead. So the tech lead is really good at project management. They're able to understand the project, break it down, and essentially like, you know, help others on the team approach that project step by step. Then there's the architect. So the architect is more in charge of direction and quality on the higher level. So they might not be great at the little details, but they see the big picture. They handle all the tech debt problems. Then there's the solver. So the solver digs into specific problems. So for example, what you told me about with that latency issue with the load balancers, it's a weird issue. Nobody really knows the answer. Nobody really has similar problems. You navigate the organization, you think of those outside the box solutions of how do you solve this specific issue. Then there's the right Hand, which is basically helping the manager. And they're good at navigating the organization. So those are just for architects. But, like, what is your special skill? What makes you stand out?
Ultra Automaton: I think, like, I'm. There's two spaces that I think I'm good at. One was leading a project, right? Like, in terms of breaking, like, when we receive a requirement from a product manager, breaking that down to tangible engineering results, like, what do we have to do to get results? Or like, you know, reach to production to get this feature done to production, like breaking them down to smaller subtasks or like digging deeper, like, okay, does the system already exist within. Within our, Our, you know, our company? Can we leverage that? If that does not exist, what can we do on our end? So I think, like, I'm pretty good at like, breaking down, like, feature requirements, coming in from product and converting them to engineering requirements and breaking each task down, right, Like a flowchart of what do we need to get done? Like step one, step two, step three, two. Even discussing, like, security alarms and monitoring and dashboards and making a nice bow and tying the entire package up. I think I do a pretty good job there and assigning, coming up with, oh, this is the effort estimate needed to get this done and making that. The product managers are aligned with what's going on. They understand what I'm talking about and making sure that my peers can take this document, take this requirement breakdown and task estimates and timelines and take this and start building off of there. I think I do a pretty good job there. And I've had experience in at least two such projects there. I've done this, like, taken a, taken a product requirement and brought this to production within, like the set specified timelines with the help of my peers as well. So I think this, I do a good job there as well as, like, like a solver. Like, if there's a specific problem, like, I feel like as an engineer, the more and more experience you get, you feel like, oh, you would have already, like, you come up with, you see issues that probably already have solutions to, but that's not always true. Every three months, there's a new requirement, there's a new problem you're trying to solve. So I think I do a pretty good job there as well. Like, like, you know, digging deeper, you know, exhausting all my resources to get help. And if not, I even reach out to my senior engineers. And I've sometimes also reached out to, like, if I've moved teams. But I am in touch with a mentor from My previous team, sometimes if there's a tech issue, people are pretty excited to resolve tech issues. Like, I've also done a good job at, like, reaching out to them and asking for help and be like, hey, have you seen this issue? Like, you know, do you think what other resources that I can use from. From there? And so I think I would. I would bracket myself in these two spaces. Yeah.
Deliberate Pumpkin: So there's two things that I really liked here. You used the phrase that you put a bow on the project. So, yeah, a lot of times, you know, engineers, they work on the project, they make the solutions. But then like that last mile, the last 10%, that's. That turns into like another 50% and it just keeps going and going. The project never gets finished. You know, this is definitely, like a major thing that people look for. Like, can you actually get things across the finish line? This is something that you can definitely emphasize in your answers and in the answers to your questions specifically, like, hey, this is how I got it over productions. I think of all of these different things, like the alerts, the logging, the monitoring, really whatever else you need. Documentation, integration with other systems. Yeah, so that would really. That would stand out. And the second thing is, like, you go to your senior engineers and your mentors, so it indicates that you're good at relationships and you maintain those relationships. And I really like the phrase that others are excited to solve complex issues. So, you know, that shows a lot of, like, emotional understanding, which a lot of engineers don't really have because. Yeah, like, you know, sometimes certain types of problems, like if you approach another team, they have deadlines, you know, they're not really in a space to solve your problems, but you go to, like, one of your mentors, and they're like, oh, this is a very interesting problem. Like, I actually want to solve this problem. So you know how to use your resources effectively. I really like that. So I would focus on those two. So now I would like for you to tell me a story of a project that you did and focus on your archetype. So your archetype is basically a tech lead, and you are good at putting a bow on your project, and you're very good at using other resources effectively, whether it's technical documentation, documentation, or other people in the Org.
Ultra Automaton: Okay. Yeah, I think I would like to focus on the Order Status Manager, this project that I'm super proud of, that I brought to fruition, and this kind of this. And I. And I want to talk about this project because this kind of helped my fellow sister Teams also utilize the same project for and solve a lot of their issues as well. So I think I'm, yeah, I'm super proud of this project especially because it also involved like a lot of inter Amazon teams and like communication with them and you know, really hard timelines to meet to get this project done. And so yeah, so yeah, this initially basically we called our team Last Mile because like let's say if a customer placed an order on Amazon, anything that has to happen after that, right? Like all the movements for that order to reach the customer after they've done what they have to do on the ui, right? Like they'd be like, oh, I placed this order, here's my card details, here's my payment details. I clicked on place order and then anything that has to happen after that was something that our team handled. Basically the shipment in case the customer cancel the order or if they have to needed refunds. And so essentially the team that I worked for was is called Amazon Autos. So basically managing a car order and placing an order for a car on Amazon is by far like a biggest purchase any customer can make. So which means this added complexities in terms of payments, in terms of how do we manage this order. Because Amazon cannot sell a car directly, we don't own a car or we don't place them under our roof in our warehouse. Instead we deal with third party sellers, we deal with dealers who own cars and then they sell them to our customers that we are providing a platform for. This project was super important for us in terms of having to navigate a status of an order after a customer has placed an order. Other responsibilities are trying to communicate across like outside of Amazon and like outside of our team within Amazon also, right? Like because there's teams who are handling payments differently. There are teams who are handling refunds or cancellations or processing of this order or even like that getting a purchase document that is owned by a different team. But we need resources from there. So this project was complicated in terms of like because of the multiple teams involved, but super useful because we needed this one point stop with one point stop to know like what's the status of an order? Like status of a CARP order. So the product came with this requirement and they're like, hey, is there a way for us to track if an order ID belongs to belongs to a car order or not? Like the only information we have is order id. But then how do we know that this order ID is a car auto ID or is an Amazon auto's order ID took that Requirement, you know. And so one really good thing that we have at Amazon is like these broadcast videos and you know, Wikipedia pages, especially in the retail world. So I started to dig deeper like what, like what are the other teams doing? Like especially I start to research like these design documents written by fellow other product teams, like what are they doing to track their orders? So maybe it's like a groceries order. The groceries order was like very similar to what we were doing with cars. So took a look at their design space, like how are they tracking their orders, which teams are the dependent on and then like dug deeper, went to that teams documents to know like understand what's going on and then like noted down the dependency that we might have for a statistical of an order. Again like this, this can go on and on. So what I did was like I scoped this down to just three or three order status. Let's try and get this done for the beta launch and then we can add additional teams or additional features on top of it. So what I focused on was, focused on was we need to know when an order was placed, so an order place notification, we need to be aware and after because that's a starting point and after that the payments, like when do we process the payments and when are we ready for shipment of this car payment. So I scoped this down to just these three requirements, make sure that the product was aligned, that hey like we want to work on this as different phases. And let's say this phase A is going to be just these three statuses and then wrote a design document to get this done. Which are the dependent teams? What are the tasks that we need to do, what are the gaps? Had a design review and took this and began the communication with these like three different teams that we need to talk to. And yeah, so from there we came up with set timelines of what we can do and this is when we can deliver. And within the same design document I ensure that I wrote down from onboarding to broke down the task like okay, These are the APIs that we need. This is how long it's going to take for us to get this API done to design the, to design the pipeline setup or like you know, infrastructure setup this long and then the different APIs and then so we cannot call a project done until we have like monitoring and alarm set up. Make sure that the environments were you know, within a vpc, they were secure and like talking about like encryption, like do we need to do any sort of data encryption? Especially because order IDs and any customer related information is sensitive. So ensuring that we have like, you know, encourage encryption and transit and encryption at rest, like mentioned those. And then you know, even before we release this, to release this as a beta launch, like what do we have to do on our end to be prepared? Like, so that would involve setting up alarms and dashboards and load testing, ensuring that we have like the right certifications from Infosec because we're handling sensitive data. Like ensuring that they are aware that this, you know, getting, getting their reviews can take a week or two. Made sure that those timelines were accounted for as well. And yeah, so this is a streamlined process where like my peers, like one of my peers took the Infosec security review and one of my peers took like creating certain APIs, like onboarding was taken care by somebody else and like together this, creating this streamlined document helped us, you know, bring this to production. And you know, like this is at least a year back that the initial three phases were done. But today, right now, using this project we're able to support from order creation, order processing to payments being processed, to refunds, cancellations, as well as receiving notifications and knowing the status and order outside of Amazon from the dealers. Like did the customer come and pick up the car or did they cancel at the dealers? Did they make the payment at the dealers? All of these statuses is being tracked by the service right now. The service that I built and initiated is also being used by three different teams within our Amazon autos team. So the notifications team is using the service because as soon as they get an order creator notification, they need to send out emails and text messages to our customers. The CSA agents need emails or notifications as well as the dealers need emails and notifications. So they've used it there. And I was also able to build off this project for SLA management. Like, and you know, tracking business metrics like how many a product was also able to like track business metrics in terms of like, oh, how many orders were created, how many orders were canceled, like how many orders were not picked up by the customers. And this in itself like helped the product to make, make more business decisions in the future. Yeah, there were more such users like today that we are using this project for.
Deliberate Pumpkin: Just finish my notes. All right, so what I really liked here is you have a lot of very unique problems that you know, I would not have thought of. Like buying a car on Amazon. I didn't know that you could buy a car on Amazon. And of course it comes with. Yeah, right. But yeah, like you could definitely like this, this is a cool story that people will remember. And I think you should lead with this story. Like, you know, when they're reviewing their 20 possible candidates, they will say like, oh yeah, that person who like organized the whole car project on Amazon, like I really remember that. Like, you know, she dealt with all of these really weird problems. One possible way that you could drive the story home is with that mistake question. So they asked, okay, what kind of mistake have you made? And you have this nice story about like, oh, you know, I made this mistake where I just like really underestimated the timelines. I didn't gather enough information, I didn't communicate enough. But you always want to, to follow these kinds of answers with and here's how I've grown. And you have a really good story of like, look how far I've come. So in your story I would cut out like most of the first part. Like the first, I would say like 5, 10 ish minutes. They didn't really add much to the story. However, as soon as. So this is what I took away from it. You had a very unique product selling a car on Amazon. There were many teams involved. What you did was you looked at similar problems. So you didn't just jump to making your own solution. You said like, hey, what are groceries doing that's like similar because you know the supermarket has to do something on their end. Then you wrote the design document. Now this is the part which really stood out to me. So that we can't call the product done until. And then you started listing a whole bunch of stuff which I wouldn't have thought of. You know, make sure that encryption works, make sure alarm works. Certifications. I don't think of certifications as part of the project. Business metrics, reviews by other teams. And then you kind of went into like, alright, so what is unique about ordering a car? Well, you have to deal with the dealer. They, they have all these weird statuses like, like the customer returned a car or the customer picked up a car. You know, really interesting stuff. And the more you kind of get people into this story of like, wow, this is a really complex and unique project and it's a very fun project. This is what they'll remember. Because people, you know, they work on emotions, they don't really remember like sort of the technical details as much as the emotion of like, wow, this is really cool. So that's a really awesome story and that's what I would focus on.
Ultra Automaton: Yeah, I think these are really great points and like Just, sorry. Building off of that, like, here's another cool thing with Amazon cars, right? Like, traditionally, if you go to a dealer and you buy a car and you walk out of it, like, as soon as it's out of the dealer's gate, you're done. Like, that becomes a used car and you can't return the car. But if you buy this on Amazon, a customer has at least a week's time to make a return. Like anything on Amazon, they can go back to the dealer and be like, nope, I don't like this car. I want to return this. They can exchange for a different car or, you know, just get refunded. Yeah, I think. Sorry.
Deliberate Pumpkin: Yeah. Wow.
Ultra Automaton: One thing that I want to note here.
Deliberate Pumpkin: Yeah, that's very cool. Yeah. Again, this is a really cool story. I like it a lot. I think people are going to like it a lot. You should lead with that story.
Ultra Automaton: Awesome. Yeah, I'm going to remember that. Talk about like the other status manager. Awesome.
Deliberate Pumpkin: Cool. All right, so let's finish up. Are there any questions you have for me?
Ultra Automaton: Yeah, I think this might not be like a traditional question, but like, do you have any, like, suggestions in terms of like, dealing with nerves, like during an interview or pre interview? Right. Like you're confident when it's not an interview, but like during an interview that. Those 45 minutes. What do you do in terms of like nerves? Like, what's your thought process? Or like, how do you like, do you have like a pre interview routine that helps you calm you down?
Deliberate Pumpkin: Yeah, well, the number one thing is just being prepared. You practice your story lots of times. So a lot of times, like when I interview, even if I don't really want to work for that company, I'll take the interview just for practice because, you know, it's very low pressure if you don't get the job. Well, whatever. Yeah. And like at the same time, it's like a bit more pressure than what we're doing right now. It feels real. So that's the number one thing. The. Let me think about this. What else do I do? Oh, here's the other thing. Don't think about it as like, oh, you know, the employer is like, has all the power even in this economy, like, they are looking for somebody who can do the job. There aren't that many people who can do the job well. So. So, you know, you have as much power or you have a very similar amount of power that the employer does. If it's actually a good fit and you know, it's. It's very similar to, you know, say, friends. Like, you know, when you're making friends, it's. It's not that, like, you are a bad friend if somebody doesn't like you. It's that you're just not a good fit together. You have different priorities, you have different values, you have different hobbies. Like, all of these different factors go into making friends. So just think about getting a job as, oh, I'm making friends, and cool. You know, I finally found this company that I really gel with. They want exactly what I have to give and vice versa.
Ultra Automaton: Yeah, yeah. No, I think these are. Yeah, that. That thought process is a really good one. I think that in itself can, like, calm things down.
Deliberate Pumpkin: Yeah.
Ultra Automaton: We're both trying to give and take from this, so it's not just, like, me at stake. Yeah, I think those are really good, great points. Thank you. Thank you so much for this. And, yeah, I'm excited. Hopefully.
Deliberate Pumpkin: It was a pleasure.
Ultra Automaton: Thank you for your time.
Deliberate Pumpkin: Did you have a great story? Yeah, no problem.
Ultra Automaton: Yeah, I will utilize this. Yeah. Thanks again. Yeah. Hope you have a great rest of the day. And happy New Year's again.
Deliberate Pumpkin: You too. Bye.
Ultra Automaton: Bye. Bye. Thank you.

We know exactly what to do and say to get the company, title, and salary you want.

Interview prep and job hunting are chaos and pain. We can help. Really.