
Amazon software engineer interview - sobit
http://sobit.me/2016/07/08/amazon-software-engineer-interview/
======
scaleout1
This article makes me sad. Interviewing in our industry is so broken. I have
been out of school for a while and switch jobs every few years and this is the
technique I use to beat the bullshit interview process

. Make a list of companies that I would apply to and sort them from most
interesting to no-way-in-hell-i-am-working-here order

. spend a weak reviewing typical algo/data structure questions

. For the companies that I absolutely want to work for, I review every single
glassdoor review and write down the interview questions. Remember, most
companies have question banks and most interviewers have favorite questions
which results in same questions being asked over an over again. You want to
exploit that

. Then to get over my interviewing jitters, I interview at a few companies
where I would absolutely not work at. This results in no pressure interview
practise and you can literally laugh at their asinine interview questions and
walk out

. Finally, for the companies i actually want to work at, I try my best to get
rid of phone screen. This is usually accomplished by dazzling them with my
decent size github profile, contributing some fixes to their OSS project or
finding someone who already works there that is in my alumni network

. Then when you finally arrive for the interview, you have real world
interview practise, they are already impressed with your github
profile/references and biased toward you versus some random joe off the street
and you have made sure you have a pretty high probability of getting a
question that you have already seen or is similar to a question you already
know.

This technique has helped me get Jobs at top 5 employers in the valley along
with a few startups. The reason I am posting this here is to demonstrate how
broken, unfair and easy to game this whole process is

~~~
enraged_camel
>>Then to get over my interviewing jitters, I interview at a few companies
where I would absolutely not work at. This results in no pressure interview
practise and you can literally laugh at their asinine interview questions and
walk out

This sounds very unethical and dishonest. It's the equivalent of a company
interviewing a candidate they have zero intention of hiring, ever. Why waste
people's time?

edit: not sure why I'm being downvoted. Am I wrong? How would you feel if you
spent time preparing for an interview, did the interview and then found out
the company didn't intend to hire you in the first place?

~~~
mavelikara
You are right, this is not ideal - this is waste of time. Which is probably
why the OP lead the comment with:

> This article makes me sad. Interviewing in our industry is so broken.

Yet:

> It's the equivalent of a company interviewing a candidate they have zero
> intention of hiring, ever.

If the company has one position to fill, and if they ever interview/contact
more than one person for filling that position all the people who they
contacted other than the person who got the job has wasted time, right?

In short, companies have only themselves to blame for this (sad) situation.

~~~
enraged_camel
>>If the company has one position to fill, and if they ever interview/contact
more than one person for filling that position all the people who they
contacted other than the person who got the job has wasted time, right?

No, this is more like the company interviewing people when there are -- and
will be -- no positions to fill. It's like a hiring manager going, "man, I
really need some practice interviewing people, I should go post some jobs on
job sites!"

------
geoelectric
I'm all for interview prep, but this sounds like a fairly standard tech
company loop.

I usually take a few days to brush up on algorithms and structures for the
first one I do in a batch, and have some canned answers for the personal
questions, but otherwise go in with what I know. Some of that's experience
now, but I don't remember any point in my career where I'd have done something
this extensive. I hope the poster doesn't feel they need a month's prep every
time they want to go test the waters on the job market!

I do agree with the frequent recommendations for Cracking the Coding
Interview. As a lead who interviews frequently, my biggest tip is to be honest
about what you do and don't know--take what you do know right to the limit
then talk about how you'd figure out the rest given normal professional time
and resources.

I'm not usually grading someone on whether they can solve my specific problem
so much as whether I think they're someone I can work with while they do it.
That said, if it's on your resume you'd better be able to talk intelligently
about it to whatever level makes sense for your experience. I definitely probe
around that stuff to figure out if I can trust the rest.

~~~
soham
Interesting and valid points. I have some things to add.

Disclaimer first: I'm a technical interview coach. We run
[http://InterviewKickstart.com](http://InterviewKickstart.com), which provides
structured and intense group programs for early and mid-career software
engineers, with the sole purpose of preparing for technical interviews.

In an ideal world, brushing up is all what it should take before going into
interviews. Practicing Software Engineers shouldn't need to spend months
working through books and courses. Interviewers should be thoughtful enough to
interview for the thought process and experience, more than DS and Algos.

Trouble is:

* Many interviewers are not that thoughtful. Even for the most well-meaning ones, it takes a few interviews to truly be good at judging someone in those 30 to 60 minutes. If a candidate is caught into the cross-hairs of an interviewer's learning curve, that candidate is not going to get a fair evaluation. Preparation helps in that situation.

* With the plethora of prep material available for past several years, the bar for interviewing has just moved higher and higher at good companies. If you look at G and F (and some others), there is no way you can get away with just knowing the basics of trees and binary searches. It just takes time.

e.g. If they ask you to merge sorted arrays and you don't know that Heap sort
is the best way to do it, you've lost the interview no matter how clear your
thought process is. Not because the interviewer is not watchful. But because
your competition has solved it with Heap Sort. So even if both of you
demonstrated a clear thought process, the other person gets the job, because
s/he is more prepared.

* It takes a certain level of life-confidence to just go to an interview with what you know and take the rest head-on. Many people don't have that kind of confidence. Many many engineers are introverts, and to borrow an analogy from sales, they are artists, not hunters. They are equally ambitious as hunters, but their confidence comes from systematic, extensive, honest preparation, and not from experience thinking on the feet. That prep easily takes months, especially when they are doing it part-time.

* Most CS colleges do not actually prepare their students for interviews. Some top ones do, but a large majority of them are not calibrated to churning out students capable of handling interviews at top tech companies. If you went to one of those colleges, and want to try for better companies, you have to prepare explicitly and separately. You have to re-learn CS with a level of specificity, intensity and extensiveness that your school never provided. Yes, you only have to do it once, but that one time, it may take many months.

~~~
SonOfLilit
> e.g. If they ask you to merge sorted arrays and you don't know that Heap
> sort is the best way to do it

Sorry, I'm confused. I love heaps, but... what's wrong with this simple O(n+m)
time and space solution, that I can easily prove is the theoretical limit
(because the output size is O(n+m))?

    
    
        def merge_sorted(a, b):
            result = []
            la, lb = len(a), len(b)
            ia, ib = 0, 0
            while ia < la or ib < lb:
                if ib >= lb:
                    result += a[ia:]
                    break
                if ia >= la:
                    result += b[ib:]
                    break
                if a[ia] <= b[ib]:
                    result.append(a[ia])
                    ia += 1
                else:
                    result.append(b[ib])
                    ib += 1
            return result
        assert merge_sorted([], []) == []
        assert merge_sorted([1, 2, 3], []) == [1, 2, 3]
        assert merge_sorted([], [1, 2, 3]) == [1, 2, 3]
        assert merge_sorted([1, 3, 5], [2, 4]) == [1, 2, 3, 4, 5]
        assert merge_sorted([2, 4], [1, 3, 5]) == [1, 2, 3, 4, 5]
        assert merge_sorted([1, 2, 3], [1, 2, 3]) == [1, 1, 2, 2, 3, 3]

~~~
SonOfLilit
Ah, some googling got me here:

[http://www.geeksforgeeks.org/merge-k-sorted-
arrays/](http://www.geeksforgeeks.org/merge-k-sorted-arrays/)

Merge _k_ sorted arrays. Obviously that's a job for a min heap (not heap sort
though, just a heap to keep the values of the next item in each array).

------
spapas82
This is totally crazy to me. Why should somebody lose about a month of his
life to prepare for the interview? Why should the interview need preparation
at all? The whole point of the interview is lost if you read books and prepare
for that since you are not tested for your real on-the-work skills but you are
tested for your interview-answering skills, memorizing trick questions and
solving toy problems!

I think that this whole interview business is bad for both the candidate _and_
the company (that would hire an interview cruncher instead of somebody who can
produce work). Of course it is good for everybody else that promotes this kind
of thinking (hr people, interview books, interview coaches, recruiters etc).

The whole process as described in this article is offensive to me. I don't
want to prove myself by answering trick questions to people whose only skill
is asking them! It's too bad we have dropped to that point.

(Please forgive my English - not my native language)

~~~
linkregister
I didn't get the impression that the author took a month off work to do the
interview prep; judging by the work load (3 exercises per chapter, a few STAR-
format essays), it looks like the amount of time one would have after work and
on weekends.

For someone working full-time it would be grueling, but no more grueling than
the workload in an after-work Master's degree program.

I view the interview prep ritual as a necessary evil. Some companies prefer to
give a take-home coding assignment. Amazon, Facebook, and the rest use this
method to optimize for their interviewers' time. I think that "interview
crunchers" DO correlate to developers who can produce work. I emphasize that
many fantastic developers who produce great work perform badly in interviews.
patio11 and tptacek address this with their recruiting startup, Starfighter.

Your English was flawless.

~~~
spapas82
Thank you for your last comment :)

I'm not sure about how much time is lost for preparation to the interview in
the general case (however I saw people recommending whole books in other
comments) but the real issue is that even one day lost to preparing for
something that you shouldn't prepare for is way too much!

I don't agree in comparing the interview preparation with the work for the
Master's degree because, although both will lead somewhere if successful (to a
Job offer or to a Master), for the Master you will learn something that is
useful or you will advance as a human being (education) while, the preparation
for the interview is just that: Preparing for an interview! Why should anybody
waste his time like that?

I'm not really sure that people that are good at interviews are also good at
producing work - this depends on various factors (i.e the interview process -
I remember to my horror some legendary interview questions of the type "why is
a manhole round"). I believe that such big companies could invent various
other, much better methods to hire their stuff. For example after the
candidate successfully passes a quick interview with some technical questions
(but without any needed preparation) hire them temporarily for some months and
evaluate them at the end.

~~~
linkregister
I hear the temporary-work evaluation advocated on HN frequently, but this is a
viewpoint almost exclusively held by junior developers. Those with families
would find it difficult to accept the risk they may be terminated after the
eval period. Senior developers aren't going to quit their job on the hope they
won't be terminated at the end of the evaluation period. Job searching from
scratch takes time and is stressful. Companies aren't going to spend half of
the eval period training a new hire only to realize many of them aren't good
enough (since they didn't screen them in a rigorous interview process). The
risks don't align with anyone's incentives except for new grads, who have much
less to lose.

I hear the argument, "if you know you're good, you'll make it," but if the
hiring decision is pushed out to the end of an evaluation period, then the
same arbitrary factors that lead interviewers to decline good candidates will
also influence the long-eval period method as well. Case in point: Google
Finance hires new grads almost exclusively from their pool of interns. Most
don't make it, though many are talented. For a student, taking an internship
is a no-risk move, since they will be returning to classes anyway. I can't a
rational developer with a family accepting a similar arrangement: where the
odds suggest _she won 't make it_.

~~~
spapas82
Agreed to your argument about the temporary-evaluation job being only possible
for a junior developer and not to somebody that already has a job. However you
should also add to them all the cases of senior developers without jobs (yes,
such cases do exist) -- a temporary evaluation job is better than nothing.

Senior developers that have jobs won't take the risk of leaving their current
job and going to an evaluating position. But these people also shouldn't be
interviewed -- since they have already have jobs, a talk about their previous
projects and work should be enough for anybody to decide if they are good
enough.

~~~
linkregister
Excellent point. Thanks for reminding me of this very important demographic.

------
driverdan
Between bad interviews I've been in or read about and spending the past 6+
months working on our hiring process I've become very opinionated about
hiring.

The process Amazon and many other tech companies use is fucking terrible.
Algorithm tests and surprise CS 101 questions do not identify good employees.
They're biased towards recent grads, do not address most real world
situations, can be gamed through studying, and do not identify people who can
actually think. _You should not be testing for people who interview well, you
should be testing for people who will make good employees._

You need to test real world scenarios. If they're going to be re-implementing
bubble sort and doing binary math then fine, use HackerRank. Otherwise you
need to have candidates work on a project based on what they'll actually be
doing. Will they be working on APIs? Have them build or integrate with an API.
Mapping in an iOS app? Have them do that.

Do not drop big surprises on candidates. Respect them and they will respect
you. Tell them what to expect up front. The first email we send includes an
outline of our entire hiring process with a list of each step. I've lost track
of how many people have thanked me for this. Going through an interview blind
is extremely stressful and increases the likelihood of losing good candidates.

My goal is to set people up for success. If their skills match what we're
looking for I want them to succeed. I don't want them to fail because they are
bad negotiators, didn't have time to study CS questions, or don't fit the
typical stereotypes of a programmer.

~~~
nojvek
This is awesome. What company is this?

~~~
exolymph
> Director of Engineering at Ownlocal (YC W10).

[https://news.ycombinator.com/user?id=driverdan](https://news.ycombinator.com/user?id=driverdan)

------
blueatlas
_In total I had a little less than one month to prepare for the interview._

I can't help but to wonder if it was really worth it. Surely, his prep helped
him get the job, but the entire prep stage he describes seems like a very high
up-front cost.

I've always felt that if I can't get through an interview with a little prep
and my existing skills, I don't belong.

 _You should know exactly why you want to work for Amazon._

It would be interesting to know more about his desire to work for Amazon that
badly.

~~~
outworlder
> I've always felt that if I can't get through an interview with a little prep
> and my existing skills, I don't belong.

I have this feeling too, but I am not sure if it is warranted.

Let's do a thought experiment: grab an engineer at random, don't tell the
interviewers that they are already a colleague, and subject to the same
interview process as everyone else. Now, is this engineer going to pass the
interview? Maybe, but I would not be surprised if most failed.

It's very rare that the interview process will actually test anything that's
used on the job.

~~~
jghn
We've talked about doing that. My fear was always that I'd fail and they'd
reconsider my own employment :)

~~~
outworlder
The idea was to reconsider the interview process. But, in the corporate world,
you never know.

------
mratzloff
If you feel a great sense of accomplishment from being hired at Amazon, that's
fine. If you believe that you are a superior engineer on the basis that you
were hired by Amazon (or Google, Facebook, Microsoft, etc.), you are making a
very bad assumption. Some current engineers and alumni believe this fallacy
because it supports their beliefs about themselves. It's a trap that stifles
their growth. It's as if people aren't aware that these companies desperately
need engineers.

~~~
plandis
I actually think you have it backwards. A lot of those engineers probably feel
the opposite because those companies have some amount of truly amazing
engineers that those other employees get to work with. For instance I'm like 4
day old garbage compared next to the technical leaders / senior engineers at
these companies.

One of my friends used to work right next to some of the engineers that
initially created EC2. I'd be feeling more like I'm not worthy because I
haven't created anything as cool or worth near as much.

~~~
tluyben2
> compared next to the technical leaders / senior engineers at these
> companies.

You feel that way because you actually didn't do anything you consider cool or
you didn't do anything others consider cool? I did a lot of cool stuff; not
really interested if others find that cool or not and certainly, without
meeting the perceived 10x engineers you are referring to, I am not going to
blindly say I would somehow rank lower as an engineer because I don't work in
one of those companies or because I was not in the startup phase of one of
those companies (you know, at the time when you didn't have to do those silly
tests and the bar or entry to jump to the top rank was lower because it was a
startup).

------
yanilkr
There is an amount of Social Engineering here embedded in the process. You
have to be cool to be part of our club (Amazon|Google|<your startup>....).
It's not the pay, its some other form of darwinian merit system. If you want
to be that fit person branded by us for life, jump these hoops. Take a month
and deal with it. It's a lifelong gold star in your resume. These hoops are
designed to select people who can do these tasks without asking too many
questions or claiming ownership of your inventions if any. Like Army expects
soldiers to just do it and be loyal. Just build this spec using the hammer we
chose for you. It's a system of hiring and retaining that works and scales
very well. The computer science algorithms and data structures are a fit
function and this method is widely deployed and tested and its almost an
Industry standard. It may be too late to find an alternative.

Startups and incubators like YC are also competing for the same talent. They
are defining a new fit function to identify people who can find problems in
their surroundings and want to solve them with the tools available to them.
The startup founders are also writing blogs about how they got funded, my
series A looks better than your series B etc. They are unable to leverage
social engineering as much as these enterprise crowd. Many of the graduates
still come out of universities and aim to get a job in a respectable company
than I will do a startup mostly because the startup based social engineering
is weak.

/end rant

------
cs2818
This whole prep for interview testing seems very unpleasant and of
questionable value to me. Are these interviews in any way representative of
day to day operations in the job you are applying for?

I worked as an independent software developer while doing my undergraduate in
CS and was very successful just by using fundamentals I learned in courses and
then reading and supplementing new things. I then transitioned into a PhD
student role in robotics, where I regularly need to come up to speed on topics
from all fields of engineering and implement solutions. I love learning and
solving problems, but the types of coding interviews discussed seem so far
from evaluating that. I produce reliable and novel things I am proud of that
take a lot of work, but that would not be enough to pass these interviews.

I know employers need proof of a good fit and competence, but I just dread the
day I have to go through one of these things.

~~~
bespoke_engnr
Don't worry too much about it. I had the same feeling, since I read HN a lot.
Now I'm going through the interview process with several companies and have
had a great experience with all of them. Not at all what I expected, based on
HN interview threads.

I don't have a CS degree and don't have a clue when it comes to the "rebalance
a red-black tree" stuff. In all of my interviews, this hasn't been an issue --
I can think intelligently about problems and solve them, ask questions, and
show correct, well-documented, maintainable code that I've written in the
past. I'm good with people and with translating between biz problems and tech
solutions.

Even in a large tech city (Boston) with lots of well-funded tech companies, my
experience has been FAR from the hell you'd imagine from reading HN. I think a
lot of this just comes from the SV bubble overrepresented here. And maybe from
the huge crowd of people here who, for various reasons, desperately want to
get into one of the big 4.

Those few enormous advertising companies (G, F, A, etc.) represent such a
small fraction of the actual work out there, and make so much of the noise,
that it's hard to keep an accurate perspective.

Anyway, don't worry about it. It sounds like you'll have an easier time than
me, and I've had it surprisingly easy during this whole process.

------
rdtsc
Mine was more fun (I shared this before, so sorry if you have to read it
again):

Didn't call on the agreed date for phone interview. Then when visiting on-
site, future manager, probably the main person I should have been talking to,
wasn't there. Quickly assembled together an interview schedule in 20 min with
people who , except maybe two, seemed distracted and just wanted to go do
something else. Forgot about me during lunch. So was left sitting in an office
for an hour without anyone checking on me (eventually got up and started
wondering the hallways hoping someone would stop me and ask me -- "Hey I don't
think you belong here" and I was hoping to reply with a silly joke about
trying to steal AWS's root CA private keys). Then of course they promised to
call back with a decision in 2 days, which was more like 2 weeks. Didn't get
an offer, no surprise (I did get snarky about the "leadership principles",
they probably didn't appreciate that), but it did make a good story I like to
tell every time interviews come up.

------
pfarnsworth
If he signed an NDA, I probably wouldn't write a blog post about the interview
process, that's a good way of getting fired for cause, since the late 1990s.

~~~
krschultz
I don't think you need to treat an NDA as a blanket 'you can say absolutely
nothing'. The post is 90% about his own preparation process, and 10% about the
day-of schedule for interviews. The schedule of the day-of process is not
exactly a secret, everyone that has interviewed at Amazon went through
something like it. The recruiters should be telling you what to expect before
you even get there. It's not like he gave a hint as to what the questions
were.

Here's the thing, posts like this are just making searchable what many people
already know. The difference is that the tribal knowledge of how to get
through interviews is one of the reasons why our profession has a diversity
problem. If you don't know that you should read those books and plan for those
questions, how well do you think you will do? Plenty of this wisdom travels
over beers among the circles of friends in the industry, but putting it on the
internet democratizes the knowledge for everyone.

~~~
chris11
Yeah, there really wasn't anything surprising in the blog post. The prep work
was somewhat interesting. But all the info looks like stuff easily available
elsewhere. And I didn't really learn anything unexpected about Amazon's
process. Besides I think NDA's for tech interviews generally just cover
specific questions.

------
jpgvm
It still seems silly that a working software engineer would need to take time
out to practice stuff they don't generally use in their actual work (which
they will probably continue doing when hired).

Knowledge of algorithms and datastructures is useful, perhaps essential in
some fields but definitely not all - or even most. Even then just
understanding the tradeoffs is probably enough.

Unless I'm interviewing someone for something like a database product I am not
going to drill them on LSM trees/B+ trees/Fractal trees.

I'm not going to bust a dudes balls over not knowing what a priority heap is
if after I explain it he can have a decent conversation about where it might
be useful.

These sorts of interviews are dumb and I have never accepted a job where I
have been subjected to them and probably never will.

------
einrealist
I don't understand why to have all these tests for an applicant? Why not
integrate an applicant into a team for a day and have pair programming
sessions?

I found, that nothing else works.

~~~
dpark
> _Why not integrate an applicant into a team for a day and have pair
> programming sessions?_

I'm not sure what you think you'll learn in one day like this. You're throwing
someone into a high-pressure peer-programming session with someone they don't
know and a codebase they've never seen. In order to get them to complete
anything you're probably going to have to stage a bunch of stuff and basically
give them a fake assignment anyway ("fill in the body of this
'findUserByOrderNumber()' method for us") which has turned it into the
equivalent a whiteboard coding question anyway. If you give them a single
pair-programming partner, you only get one hiring opinion which is a pretty
bad idea, and if you give them multiple pair-programming partners the work
will have to be even more trivial.

I don't think a one-day trial like this will tell you more than a standard
interview loop. Some people might do better with it, others will do worse.

I also don't think you should expect to get real work out of someone before
you hire them, either. If you want me to spend 8 hours building you a feature,
I expect to get paid. And the overhead of paying me for 8 hours of work is
probably not worth it to your company, because it's a ridiculous amount of
paperwork. (And not even possible for people who need visa sponsoring.)

~~~
lj3
> I also don't think you should expect to get real work out of someone before
> you hire them, either.

This has grown on me. It's a lot of time invested per company, but it's still
a hell of a lot less time than the interview prep mentioned in the article.
It's also more pleasant, since I'm programming something real instead of the
fibonacci sequence.

~~~
dpark
I don't honestly think you're going to get much more than Fibonacci in a one
day pair programming session on an unknown codebase. It's just too much to
learn before you can really accomplish anything. Beyond one or _maybe_ two
days it just becomes an unreasonable request, regardless of whether they pay
you.

~~~
lj3
Oh, I think I misunderstood what you meant by "get real work" out of somebody.
IMHO, pair programming isn't getting real work out of somebody. I'm with
tptacek on this one: take home programming tests. Specifically, tests where
they give you specs for something and you build it however you like.

~~~
dpark
I'm ok with something like that if it's a reasonable amount of work, and if
it's not going to be followed up with the standard interview loop. Extremely
long take home work is unreasonable to me. Studying for interviews is at least
applicable to many companies. A take home is just for the one. And if it's
followed up with a normal interview loop, then it's just _more_ but not
_better_.

------
kafkaesq
_It was never communicated which languages the coding test would be limited to
before I started it._

Brilliant. They expect near-flawless execution (under tight time constraints)
on these algorithm quizzes -- but can't manage to communicate up front which
languages you'll be actually be allowed to code in.

------
64bitbrain
"It was never communicated which languages the coding test would be limited to
before I started it. Those I could choose from were C, C++, Java and a couple
of others, which ruined my plans to use Go or PHP - the languages I was the
most proficient in. So I ended up choosing Java."

Similar thing happened to me. I was never told or asked which programming
language I would prefer. I click the link, filled some info and I landed on
programming question with only two choices C or C++. I was like wait?! Though,
I tried to solve the problem, but couldn't finish on time. I contacted the
recruiter about this and I never heard anything back. All I got was email,
Sorry you didn't qualify. I really liked the Hackerrank interface, but I was
disappointed in lack of language options I was given.

------
preordained
Gross...but that's just me. I know some people really do thrive on this kind
of technical rigor and hard-nosed meritocracy type of culture...but if that's
the price of progress I'd rather go back to the caves and tepees.

------
lxe
> It was never communicated which languages the coding test would be limited
> to before I started it. Those I could choose from were C, C++, Java and a
> couple of others, which ruined my plans to use Go or PHP - the languages I
> was the most proficient in. So I ended up choosing Java.

I never get this. The first thing that should be understood by the combination
of the resume and the phone screen is the candidate's preferred language.

------
lohengramm
This seems like a very standard process, but personally the best interview I
have done was a take-home exercise involving a real world problem. It took me
a whole day to do it, but I only had to do exactly what I do best: write code,
silently, "in the zone".

No interview environment will ever simulate "the zone", and there is no way to
truly test a programmer out of it.

------
willtim
I can't help but feel that there is too much focus on data structures and
algorithms. My kids have Amazon Fire Kid tablets and Amazon's software is, to
put it mildly, unreliable. I'm sure the data structures and algorithms are
probably fine, they're mostly shipped with the plethora of open source that
most software is now built from anyway.

------
hippich
All of that looks really painful.. And surprisingly reminds me of pains of
dating. (although I seriously dated only once in my life looong time ago)

In dating people trying to find right fit for look, in tech interviews - right
answers for arbitrary tech problems.

Nor look not answers to these tech problems is not predictor of success, yet
this is what everybody are still using...

------
wyc
How unfair that you're expected to sign an NDA on the spot. I'm sure that
Amazon and other software companies have spent tens/hundreds of thousands of
dollars to protect their IP, yet you don't even get the most basic legal
counsel. Why couldn't they mail it out after the phone screening? This almost
feels like duress.

~~~
twblalock
You aren't being coerced, so it isn't duress.

You want to interview? Sign an NDA. Otherwise, Amazon is under no obligation
whatsoever to offer you an interview. Nothing is being taken from you, because
you are not entitled to receive a job interview.

------
exabrial
When I interviewed for Amazon for a Java position, they had a C guy give the
interview. When he asked me to implement atoi() on Java, Integer.parseInt()
was the not correct way to do things at Amazon. After that it was all sys
admin questions about the version of Linux they use.

Somehow I managed to pass to the next level. I told them no thanks.

~~~
lostcolony
I had the same problem with Microsoft (atoi), and the same issue with the
interviewer (being a C guy)...the issue there was that he thought
(stringInstance).length() was an O(n) op, so the fact I was calling it in my
loop meant my algorithm was O(n^2). My explaining that, no, Java stores the
length as part of the object...kinda tanked the interview.

~~~
linkregister
You describe the "interview anti-loop," a term coined by Steve Yegge, a
prolific blogger who wrote about the Google interview process. Better luck
next time. I've come across it a few times myself. Also I've legitimately
bombed interviews, sending apology emails to the recruiter immediately after
leaving.

~~~
lostcolony
Oh, there won't be a next time. A bit of sour grapes, but I also legitimately
don't want to work for Microsoft. Even then it was more exploring my options;
that interview tanking was more cynically amusing than it was disheartening.

------
ideaskid
one question.

i'm a total noob in my 3rd year CS undergrad.

I've just started prep to crack companies like Amazon.

Any pointers or tips to get started?

~~~
pconner
Get the book, "Cracking The Coding Interview." It was the most valuable
resource for me in preparing for technical interviews near the end of my time
in undergrad.

~~~
ideaskid
Yes, I bought it last week. But, couldn't answer through the questions because
I didn't know the concepts and DS's. Could you answer these 2 questions?

1\. Where did you learn how to implement the Data Structures and Algorithms?

2\. Also, I'm in a dilemma between using Python and C/C++. Which one would you
suggest?

~~~
rifung
Not the person you're asking but I previously passed the interview at Amazon.

If you don't know the concepts/data structures, just read more about them,
either on the internet or from a book. The internet is usually sufficient for
most things but if you want to go more in depth, CLRS is the book that most
people recommend. I haven't read it personally. Don't feel bad if you can't
answer the questions, a lot of it is practice, and if you don't know the
concepts beforehand it's better that you just read the solutions.

1.) I learned in school 2.) It doesn't really matter, just use the one you're
more comfortable with. If you're equally comfortable, I'd recommend Python
because you're going to be writing on the whiteboard and I imagine C/C++ is
more verbose, so you'll waste more time writing. Your hand might also get
tired.

You can also go on careercup.com to get more questions after you're finished
with the book so you can practice.

~~~
superuser2
>CLRS is the book that most people recommend.

CLRS is a good reference if you want to look up some canonical algorithm and
read the accompanying discussion. It is a _terrible_ way to learn if you're
not combining it with something more explanatory, like a professor. It's an
extremely dense wall of pseudocode and proofs.

Kleinberg and Tardos is a little handwavy with its mathematical proofs, but
does an excellent job of motivating the examples, holding your hand and
explaining _why_ the next step is next, etc.

It is _not_ , however, a survey of the canonical algorithms and data
structures. You will not learn how to balance or invert a binary tree. (My
algorithms class was based on K&T, and while I learned a ton, I don't feel I
learned how to pass a whiteboard interview). More of an introduction to
algorithmic thought, with algorithms selected for their pedagogical value.

~~~
Apocryphon
CLRS is a huge tome. I have no idea why it's always recommended as an
introduction to algorithms. It seems like it has the breadth, if not the
depth, of TAOCP in terms of being a perennially recommended work that no one
actually reads all of the way through.

------
CobrastanJorji
> Recruiters usually cannot dive deeply into technical topics, but she was
> very open to discussing the reasons I used to name them differently.

I could be wrong, but based on what you are saying here, I'm pretty sure you
were being interviewed by a software engineer and not a recruiter.

------
a_imho
I have always wondered if I were to ask an interviewer to do some white board
coding exercise for me would they take the challenge?

------
Illniyar
Wait, is it normal for a recruiter todo a tech interview? I never heard of
such a thing.

------
brett40324
Very helpful write up, thanks.

------
serge2k
> I only had two days so I brushed up on the essentials in algorithms and data
> structures. Specifically, I focused on the following: [list follows]

No graph problems? Seems like a possible hole, I got graph problems in
interviews for Amazon.

Edit: Nevermind, I realized this was your phone screen prep.

