J'ai postulé en ligne. Le processus a pris 2 semaines. J'ai passé un entretien chez Amazon (Austin, TX) en août 2014
Entretien
Initial Communication - One of their technical recruiters messaged me on LinkedIn expressing an interest in my skills. I ignored it. A couple months went by, and I decided looking for other career opportunities would be a good thing. I applied online for their Austin, TX positions. I also found a few of their technical recruiters on LinkedIn and messaged them.
I got a phone call from one of their technical recruiters. She was really nice and excited to talk to me. There were a couple questions about my work experience mostly to make sure that I was who I claimed I was on paper. The next step was a timed test online that they would record in real time. She also gave me a small document that was prep for the test listing various topics that the test would include. She also claimed 'do not exceed one hour' on the timed test.
To prepare for the test, I recommend googling for Amazon Test questions. They won't be exact, but you'll get in the habit of answering questions fast. The test was composed of three questions. 1) Write a series of classes for a graphics API. 2) Implement a breadth first traversal of some tree. 3) Implement a method for the fibonacci sequence.
Then a couple phone calls and email exchanges. "You Passed, we love you!". The next step is an onsite interview that lasts 2-4 hours.
The onsite interview consisted of meeting with pairs of people. One of them was the lead interviewer, the other was someone who had started within the last six months and was there more to take notes. The first group seemed unhappy to be there at all. It didn't matter what I said. It was straight to the white board for more technical tests. This group asked questions about implementing a bit map editor. They purposely would ask vague questions with the expectation that you will ask them questions to figure out what they are really wanting answered. They would ask questions about big O notation. They would ask questions about memory usage. The next group was similar.
I asked each of the groups if they would be my actual coworkers. The answer was no across the board. I did want to meet whom I would actually be working with. The people I met in the interview seemed like they didn't want to be there. Toward the end of one of the groups, I thought of a better implementation to a question I answered. They responded, "We're out of time". They definitely had the attitude of "People apply here everyday, Anyone is replaceable, No one is unique"
I'm guessing I didn't pass their in-person technical test, but I wasn't too crazy about working with them either.
Questions d'entretien [1]
Question 1
For a bitmap editor, given an x,y location and a color, write a series of methods for a Fill operation like the paint bucket, except only change the color of the outer boundary of what would be filled.
Interviewed for silicon team. Have only been asked about the domain specific knowledge in 1st round and system design in 2nd round and C coding in 3rd round.
The interviews were 50 mins each.
First round with hr screening - 2 leetcode questions then hr manager screening then the loop which consists of 4 interviews each an hour long. The 4 interview questions they asked where three medium leetcode questions. And one system design interview question about how to shadow deploy a test software to millions of users.
The phone screen went longer than expected, focusing heavily on implementation details. The interviewer really grilled me on my approach to a Least Recently Used (LRU) cache, asking how I'd combine a hashmap with a doubly linked list. I felt well-prepared since I had gone through system design examples on PracHub, which made me comfortable discussing eviction policies. The later rounds included more technical questions and behavioral interviews, but in the end, I received an offer, though I ultimately decided to decline. Overall, I’d say the process was average, with solid questions.
Questions d'entretien [1]
Question 1
Design and implement a Least Recently Used (LRU) cache supporting get(key) and put(key, value) in O(1) average time. Walk through combining a hashmap with a doubly linked list, eviction policy when capacity is exceeded, and how you'd extend it to handle thread-safe concurrent access.