Interview with an Amazon engineer.

An Interview with an Amazon engineer

Watch someone solve the online file storage problem in an interview with an Amazon engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type
Online file storage

Interview question
Design a file system storage like Google Drive or Dropbox

Interview Feedback

Feedback about Quantum Badger (the interviewee)

Advance this person to the next round?
Yes

How were their technical skills?
3/4

How was their problem solving ability?
3/4

What about their communication ability?
3/4

I am inclined to hire the candidate.
The candidate has discussed a multitude of things and has shown depth of knowledge in various parts of the design, especially in

Improvements -

  1. There was some back and forth on how the consistent hashing works. Is it for the write servers or the database servers or both? We lost some time there.
  2. Time management is one important aspect for design questions. I would recommend finishing the requirements & capacity estimates in 8-10 minutes and have a good amount of time for discussing the meat of the design.
  3. Minor - Regarding database design, I was expecting you to come up with 2 different databases: one for metadata & the other for object datastore, right away.
  4. File chunking I was expecting to be done on the client side rather than the server side.

I would recommend solving some design problems on your own and looking up the solution and see where you could improve.

Feedback about Infinite Shadow (the interviewer)

Would you want to work with this person?
Yes

How excited would you be to work with them?
3/4

How good were the questions?
4/4

How helpful was your interviewer in guiding you to the solution(s)?
3/4

Not sure about how mentorship session is conducted, but I was probably expecting both the interviewer and interviewee to work together to solve a problem. More like a conversation. Time could be challenging. Nonetheless, it was helpful to think through and get feedback from a professional interviewer.

Interview Transcript

Infinite Shadow: Hey, how's it going?
Quantum Badger: Good. How are you?
Infinite Shadow: Doing good. So this is for systems design mentorship practice.
Quantum Badger: Right.
Infinite Shadow: Gotcha. Can you provide a little background of yourself and where you're in the interview process right now? And what are your expectations from this interview?
Quantum Badger: Sure. So I'm a software engineer, and in the data side, so you can call me a data engineer. And I have had over 4 years of experience. And I'm right now working at Lyft. And then I have a few interviews coming up next week, for onsite. And, over the last year, right, I did take a few interviews, and then system design is sort of my weakest point. And so I want to make sure that, if I'm following the structure well, or I want to see where I'm missing things. That's why I chose to do a mentorship interview. Do you want like, the expectation from this call is to make sure like, you know, to understand from the other side, like what is expected out of system design? And what are the red flags? What are the things not to do and how to how to structure it and how to go about it. Obviously, I followed the structure given by grokking the system design interview, and I think that I failed because of following the structure because, and I thought to myself, like, you know, going with intuition is better than blindly following the predefined structure. So this is what I have in my mind at this point of time.

Infinite Shadow: Okay, so if I understand correctly, did you do system design interviews last year, and it didn't go well?
Quantum Badger: Right. Yeah, I think it's because coding-wise, I'm pretty sure I'm okay with that. I think system design is where probably, I might have offers rescinded because of that.
Infinite Shadow: And for data engineers, like what is the bar for system design interviews?
Quantum Badger: I think I have an interview with Instacart. And they have a dedicated round for system design. Initially, like, mostly people don't put system design for data engineers. But this is in the data influencing. So the bar is the same as software engineers, and I have a software engineering background as well. So the bar is pretty much the same as software engineers.
Infinite Shadow: Okay, sounds good. Sounds good. Want to get, you know, in the right direction, and get the feedback?
Quantum Badger: Right, yeah.
Infinite Shadow: Okay, sounds good. So, do you want to like solve a problem? And then you, as you solve it, do you want me to go through and what are the expectations?
Quantum Badger: Yeah, maybe that sounds good.
Infinite Shadow: Okay. Designing a file hosting service, similar to Dropbox or Google Drive?
Quantum Badger: Okay. I don't think I have done that before. So probably that's probably a good idea, I guess.

Infinite Shadow: So the first thing I would like to start is go with the use case as expected. Obviously, this is for interview sake and we can't. Like we have a limited time. So to understand like functional requirements of what is expected out of this. So to begin, right, this is Google Drive. So for accepting use cases, should we should fill? Is this something I have to come up with? Or should I ask the interviewer to give up to give use cases for me like to see what he's interested in?

Infinite Shadow: Yeah, so the, usually the expectation from the system design interview, at least in my sense, it is, basically, you will be given an ambiguous problem. And what I want to see is, how does the candidate deal with an ambiguity, let's say, once you join a particular team, I'm already working at least, I mean, that is a really good company. And you might already know about this. So basically, you will be given a design or a mini design in your project, and most of the time, you will know where to start with an arrival, you will know those requirements, and what are the design goals? The latency requirements? What are the other services that you have to interact with? Or make changes to? And what are the milestones and stuff like that there is a goal, like how do you deal with ambiguity? And how would you, you know, provide structure to the problem, which you're trying to solve, where you don't have any context of it. So most of the time, I would recommend the candidates, you know, to come up with their use cases and ask clarifying questions. And the interviewer should be able to correct and or add on to the requirements that you provide.

Quantum Badger: Okay. Sounds good. Yeah. Okay, then, in that case, Google Drive, the primary or the primary workflow, or the use cases are to upload a file.

Functional Requirement – Key Features

  1. Uploading a File: This is the primary function of the system.
  2. Downloading a File: Users should be able to download the file they have uploaded.
  3. Sharing Files: Users should be able to share files with others.
  4. Syncing: Users should be able to sync files across different devices.

Non-functional Requirements

Key Feedback from Interview

  1. Time Management: Allocate time effectively for design questions.
  2. Database Design: Expectations of multiple databases for different storage types.
  3. File Chunking: This operation should be designed for the client-side.
  4. Consistent Hashing: Should clarify if this applies to write servers, database servers, or both.

Further Steps

  1. Solve multiple design problems independently for practice.
  2. Keep iterating on solutions and adapting from feedback.

Conclusion

The interview scenario provided insights into requirements gathering, system dynamics, and a deeper look into server architecture. The focus should always remain on clear communication and an iterative understanding of expectations.