Amazon Coding Sample

Transcript

0:00
I'm Erica Gomez and I'm a senior manager of engineering at Amazon. Today, what we're gonna
talk through is how to do coding on the whiteboard. Now, I know it seems really intimidating,
but it doesn't have to be. There's a super structured way to walk through these types of problems.

So, what is it that we're looking for when we talk about whiteboard coding? Well, there are a few
things that, as a company, we're trying to understand about your skillset. The first one is, do you
know your computer science fundamentals? How are you on data structures and algorithms? The
second is, do you have a heuristic for problem-solving, or do you just kind of randomly approach
problems? And the third thing is, do you write clean, logical, maintainable code that other people
can readily understand?

0:54
So why are we doing this? Well, because this is the kind of stuff that you do every single day at
Amazon. You're going to be using the core principles of computer science to tackle super hard
problems, and chances are at some point other people are gonna be reading and maintaining your
code.

So how do we go about this? Well, there are a few key principles that I want you to keep in mind
as you think about these types of problems. It's really not about whether you have done every
single sample problem that you found online. It's, one, do you not jump into the problem
immediately without looking at the space that it's in? Two, do you try and disambiguate the
problem, ask questions, try and understand the inputs and outputs? What are some of the edge
cases that you need to be thinking about? And three, do you talk this out loud? This is a dialogue
with your interviewer; it's, you know, not a recitation.

And so, try and make sure that as you're writing code on the board, you're helping us understand
what you're thinking and why and how you're trying to solve that problem. And so, once you've
gone through this process, I'm going to talk you through an example problem of how to actually
go through solving the problem on the whiteboard, talking out loud, and thinking about all the
things that you need to do in order to finish these types of problems successfully.

2:07
When you interview at Amazon, you can expect somewhere between two and four questions like
this. And so, this is a good framework to build for your interview here. So why don't we jump
right in?

2:24
One thing I do want to remind you of is this is not a test of domain knowledge. If an interviewer
asks you a question about rugby, we don't expect you to know the rules of rugby. This is about
seeing if you can take an ambiguous problem, try and disambiguate the edges, and then, you
know, come up with a reasonable working solution.

2:45
So the problem that we're going to work through today is run-length encoding. Now, it's fine if
you've never heard of this. This is an older lossless compression algorithm from the '60s or '70s,
and it was a way to compress image files. If you think of an image file as just a series of pixels
that you can then compress a run, if you will, what it looks like is this: So let's say I have a string
of characters: a, a, a, b, b, c, c. If I encode this, what I should get is this: 3a 2b 2c. That's the
desired output.

3:33
So to write a function that's going to do this compression, we've got to do a few things first.
Don't just jump into the problem. Think about what are the ambiguities here? What are some of
the edge cases or the gotchas that you might encounter when trying to solve this? For example,
what happens if we just throw another a on the end there? Well, sometimes candidates think, oh,
okay, this just becomes 5a, but that's not the case because order matters in run-length encoding.
What this should be is 4a 1a. So this is going to start dictating the kinds of data structures that
you might think about. A lot of candidates immediately jump to, oh, I need a hash
implementation, but if order matters, yeah, you can do it with a hash map, but it's not optimal.

4:22
So then I might think, okay, well, what about something like this: a, b, c, d? Well, yeah, it's as
inefficient as it looks: 1a 1b 1c 1d. And that's okay. Like I said, this is just how the algorithm
works. So now we're kind of teasing out the edges of this problem.

So, the next thing that you want to think about is, well, how am I going to actually solve it?
Chances are this is a pretty straightforward iterative problem. I'm gonna walk through each
character in the string. I'm gonna compare the character to the previous character. If it's the same,
I'll increment some kind of counter, and if it's different, then I know I've hit the end of a run, and
I'm gonna add that to my output.

5:09
In this case, I'll probably solve it in Java just because that's the language I'm comfortable in, but
it's up to you if you want to solve it in a language that you're more comfortable in. Just let your
interviewer know what you'd like to use. So, with that, let's get started.

5:27
So let's get into implementation. So now that we know that we're gonna take an iterative
approach to solving this problem, we're just gonna walk through a string array. Let's start by
thinking about our inputs and outputs and how we're going to specify the function. Reminder
right now: I'll just preface that I'm going to write this in Java. My function header, because it's
going to return a string and it's also going to take a string.
So, what do I want to do first? Well, we don't generally get very fussy about whether or not your
input's validated, but for this case, because we've got a simple input validation that we can do,
which is namely, is our input null, let's just do a quick check here.

6:30
So if it's null, we return the empty string. Now, we need to start initializing the variables that
we're going to need to solve the problem because we're going to be walking through an array of
characters. We should probably convert this to a char array, and also, because we need to track
whatever the previous character was, we should create a variable to store that. And because we're
going to need to keep a count of how many we've observed in the run, we need a counter. So
now let's get into the algorithm. Well, the first thing we want to do is see if the current is equal to
the previous, and if it is, it's simple: we just increment the counter.

7:45
Now, if it's different and it's not null, then we know we've hit a switch in the run. We've hit the
end of a run, and we're going into a new run. And that means that we want to append to whatever
return string we're going to be building out. And one thing that I notice I've done here is I have
forgotten to actually initialize my string builder, and that's okay. Like, if you don't get everything
the first time, that's fine. Just notate here and make it clear for the interviewer what you're doing.
And so, I'm just gonna say, all right, I forgot this line; I don't want to erase everything. So, let's
initialize the string builder.

8:33
Now, it's going to be super tempting to use really shorthand variables or to just say, okay, we
know we're initializing a new string builder, but I'm gonna really recommend that you don't do
this. Just take a couple extra seconds and write out everything fully. It'll be clear for you; it'll be
clear for the interviewer. It'll also just result in overall clean code. It's a good habit to get into the
practice of. So now that we have our string builder, we can actually go and append to the
previous char and whatever the counter value is.

9:10
And then, if these cases don't hold and we've already switched, well, then we need to reset some
of our variables here. So, we're going to say previous char is equal to the new char that we're
iterating through, and our counter equals 1. And that terminates our for loop, but that means
we've reached the end of our input array, so we need to spit out the last of our compressed
values. So, I will just make it very clear that I'm continuing my code over here. And then, finally,
I'll return the string. And there's our implementation.

10:15
So we have our implementation, but there are a couple of things that I want to point out that I
was doing throughout the implementation process. You probably noticed that I was talking out
loud the whole time, and that was very intentional. It's not something I'm doing for this; it's to let
the interviewer know what I'm thinking and what I'm trying to accomplish with the code that I'm
writing because sometimes it's not obvious as you're going through the process. The other thing I
did is you probably noticed these somewhat trivial comments. It might seem trivial, but it's a
great cue for both you and your interviewer, and it shows that you care about writing
maintainable code because someone's eventually gonna look at it and try to understand what you
were doing, and that first person, in this case, is your interviewer.

11:16
And the other thing I was doing is, you know, I can't really ask questions in this context, but you
can ask questions to clarify with the interviewer, and the interviewer may interrupt and ask some
questions with you. It's a dialogue. That's fine. If they cut you off, don't worry about it. They're
just trying to maybe give you some new information or maybe change the problem a little bit to
see if you can take your framework and adjust it a little bit to whatever they might want to talk
about. And the last thing is it's okay to make mistakes. I made a mistake in here where I forgot to
declare my string builder. That's not a problem. Just make it clear, be upfront about it, say, "Hey,
I noticed I did this, and I want to go back and fix it," and the interviewer will totally understand.

11:59
So with that, we've implemented run-length encoding. There are a couple of other things you
could think about, such as optimizations. If you're familiar with them, you can bring them up, but
that's about it. We've talked through the problem. We've asked some questions. We talked about
some edge cases. We implemented our solution, and we've covered how to actually handle this
problem.

12:20
So remember, this is about showing us how you tackle a problem, how you think through it, and
how you communicate it. It's not about whether you've solved every single algorithm problem
that you can find online. If you have a framework for this, you're gonna do great, and you're
gonna solve these kinds of problems every day at Amazon. We hope to see you in the interview
process soon.