Amazon’s Interview Questions And Why I Don’t Work At Amazon
xyhd.tv
xyhd.tv
Rather than go into great detail on why I don't like their questions, I'm going to pick out one that stands out as an example. It starts:
"Suppose I want to <description of some user story>, so I want you to design a system that <vague description of an implementation method>."
Okay, I'm thinking, done this before a lot of times, it's bland but not an unreasonable way to find out how somebody approaches problems. But they haven't finished talking, and they add one more sentence:
"Make sure you show me the objects and classes that your system will use."
This is the point when I try not to let my disappointment and irritation show. It's not just that they've completely prejudiced the question, by forcing it down one particular design path, it's that they've made it clear this is not a test of my ability to design systems, it's a test of my ability to mimic their design of the system. Worse yet, in one stroke this destroys any hope of finding out how the candidate thinks; instead, it just measures how well they can think along certain lines.
I don't have a problem with object-oriented designs - I'd probably have done things that way anyway. But I do have a problem with companies that hire based on conformity to groupthink. I don't want to work with a group of people who were selected based on their performance at this kind of question.
Did the other interviewers also ask similar questions?
"The other reason is that when I asked people what they were working on, they all said they were rewriting all the Perl code in Java "because Amazon is a Java company" - apparently that was the biggest business need at the time"
Having sat in on these kinds of discussions before at companies large and small, while it is certainly sometimes true that companies make a ridiculous platform decision like, "We're a java company", more often than not the decision is a lot more complicated. They might have felt that it was easier to hire people who knew Java, or they leveraged off the shelf software that was written in java, or they acquired a company with interesting tech based on java, or a million other reasons.
That doesn't mean they made the right decision, but I'm just making the point that what may trickle down as "we're a java company" didn't start out that way, and may not be based in that fundamental stupidity.
I could see many reasons to port one of the worlds largest sites off of Perl and onto something like Java, one being the availability of developers that are proficient in Java vs Perl.
Also, if the company you work at uses OOP to design their systems it's perfectly normal to ask you to design something with regards to those restrictions.
anyway, to my culture, your reply seems inappropriately respectful (i am not saying it is since this is obviously a culturally-dependent judgement, just trying, clumsily, to explain...). hence the idea that they must have a hostage.
Better to live in mud huts!
[0] http://www.businessinsider.com/companies-ranked-by-turnover-...
i.e. The faster a company grows, the less likely/harder it is to maintain culture and enforce hiring/recruiting standards - I can see how that may lead to shitty interview questions.
At that growth rate, you'd expect the tenure numbers to be dominated by hiring rather than turnover, a point the article misses completely.
(Per their annual reports, Amazon had 88,400 employees on 12/31/2012, 56,200 on 12/31/2011, and 33,700 on 12/31/2010)
It seems superficial and cynical, and doesn't seem to have anything useful to say. (Also, the post is tagged as 'Industry News'...??)
I worked for Amazon, and looked over the list of allowed/prohibited interview questions on the internal wiki. I did not see any of these question. Furthermore, they are against asking puzzle-type and behavioral questions.
He insisted on grilling me on a metaphor in my personal statement as if it were literally true. I honestly don't know if he was trying to piss me off, or was (slightly) autistic and didn't understand metaphors. Once I'd gotten him off that, I mentioned I had a friend who worked at Lab 126, which he was also completely uninterested in. When your interviewer isn't interested in the fact that someone you worked with for 5 years works down the hallway from him? You're not getting that job. It was pretty clear a decision had been made against me before the interview ever took place and Amazon was just wasting my time.
Left a bad taste in my mouth.
FOR EXAMPLE, 132456789101113 is 1-13 and not very random. most answers below have misunderstood me (well, less now that some have been deleted in shame... ;o)
you can get the digits, just by seeing what is missing. but then you seem to be left with a rather tricky partition problem. so i guess dynamic programming? is there a better way?
would it help to pick out unique combinations (if the pattern 249 occurs just once, it must be 249, unless it is the missing number)? how far would that get you?
i guess since you know the missing digits you should check for each permutation - you might get lucky and not find one.
is there some cute trick? something involving suffix trees?
[edit: anonymoushn has a good point - it's not guaranteed unique]
1727321173475
could be 1, 72, 73, 211, ... or 17, 27, 32, 117, ... or 172, ...
but you can get the formula by imagining the numbers as piles of pennies and then completing them to make a square and then splitting down the diagonal
*
**
***
*..
**.
***
\.. \
*\. + \
**\ \
where a \ is half a penny. so * = \\so it's 1/2 * n * n (ie half the square) plus an extra 1/2 for each one on the diagonal.
so it's n * n/2 + n/2 = (n+1) * n/2
# arr must contain all of the numbers from 1 to k except one
# returns the number which is missing
def missing_number(arr):
return ((len(arr)+2) * (len(arr)+1))/2 - sum(arr)
I can't really talk about the article, since it is down :(Edit to reflect edit in the parent: The problem as posed is not soluble in general. For k=21,
1 2 12 3 4 5 6 7 8 9 10 11 13 14 15 16 17 18 19 20 (21 is missing)
==
1 21 2 3 4 5 6 7 8 9 10 11 13 14 15 16 17 18 19 20 (12 is missing)
You can discover the missing digits in linear time, but determining from there whether the input has a unique solution seems a bit annoying.If a valid permutation of the missing digits is missing, you win, but you can have a unique solution without that being the case:
11 21 13 3 2 4 5 6 7 8 9 10 14 15 16 17 18 19 20 1 (12 is missing)1 2 3 4 5
12345
At this level it's no big deal. What happens when you get to double digits?
11 12 13
111213
Now what happens when they're not in a nice order?
5121892178
...11123...
Is that a 1, an 11, a 12, a 112, a 123?
I'm ridiculously curious to know if there is a clever trick to this! :)
Once you know the actual sum, you can do it either: sum all, subtract total - sum. Or with data structures: it would be a variant of the "given an array find all pairs of numbers that add up to a sum". The benefit of using the data structure approach would be that you can now find x missing numbers in the range 1 - 250.
note* the closed form might have a off by one error
Since there are no spaces in the list: 1) I would count the instances of didgits 0-9 2) compare those counts to the counts produced by the complete set of didgets 3) The ones that fell below in count are the didgits in the missing number 4) Count the instances of the permutations of your missing didgets 5) compare those counts to the counts from the full list 6) Done.
In case anyone wants a starting point:
import random
from collections import Counter
rand_list = range(0, 250)
random.shuffle(rand_list)
missing = rand_list.pop()
shuffled = ''.join([str(x) for x in rand_list])
full_list = ''.join([str(x) for x in xrange(0, 250)])
cntr = Counter()
for digit in full_list:
cntr[int(digit)] += 1
for digit in shuffled:
cntr[int(digit)] -= 1
digits = []
for k, v in cntr.items():
for _ in range(0, v):
digits.append(k)Then you find a set of tuples which cover 1-250 (missing one number) and which don't overlap.
You can start by filtering out all the 3-tuples which are over 250.
I might use a hash table to put together a list of all duplicates. Any hash table entry with no duplicates has to be right. Use the indexes that have been removed from the "eligible" pool to remove tuples from the hash table. Iterate.
Of course it's entirely possible that iterating like that could still leave you without a solution. At which point a guess has to be made and to continue solving. If said guess is bad, backtrack and make a different guess.
Obviously it's harder to implement than to outline. And I've probably missed a bunch of optimization.