1/15/09 04:38 am - My Amazon Experience
A lot has been going on since my last post, some good, some bad. First, I unfortunately found myself in November out of a job, as the company I had been working for the last three years was finally coming under the strain of the financial crunch. This was really quite a tough transition, but not for the obvious reasons. My experience with the company had some of my best time, and I got paid to do it. I already miss the guys I worked with, and hope that I can find as comfortable work environments in the future.
The job hunt itself was pretty painless, especially considering that my family was not in immediate financial distress. I posted resumes on some of the bigger job sites and began looking for something in the region. While there weren't many opportunities close to where I lived, I did experience a pretty steady trickle of leads from recruiters. Fairly early on, I was called out of the blue by a recruiter from Amazon.com. Apparently, a project manager had seen my resume and thought they could utilize my background working with indexing and search engines.
While this was a great opportunity, and instilled some degree of confidence that I'd have little trouble landing a position soon, it was kind of intimidating. Amazon.com has an interview process that had a reputation online for being fairly competitive, and I'd never really gone up against a technical interview that went beyond simple questions about OOP or a specific language.
I did some research, tried to look at other people's experiences with interviews and what sorts of questions were normally asked. While I'd been working in software development for the last few years, it'd been about twice as long since I'd learned from a book on the topics I'd likely be quizzed. Despite this, it seemed like an opportunity that couldn't be passed up, so I schedule the first of what is generally three interviews(two phone, one onsite).
I won't go into too fine a detail about the contents of the interviews, as it isn't really relevant to anybody but a prospective employee. In general, although I studied pretty decently on a variety of topics, the interviews didn't really align with what I expected. I reviewed a lot on theory, on common algorithms for search and sort, and made sure I could easily answer any OOP definitions or concepts.
My first interview went reasonably at first, with him asking some questions about Java syntax and OOP concepts. It did hit a snag, though, when I was asked to code a very simple problem(code an indexOf() for an array). I had worked out something in a matter of seconds, and then spent far too long muddling through handing him syntactically accurate code over the phone.
I have to say that this is quite possibly the worst imaginable way to assess design abilities. I did probably dive into it a bit early, mostly because it was quite clear in my head and seemed so simple that it didn't even require my writing it down for myself to see. Nonetheless there are a number of flaws in asking questions like this. First and foremost, it is one of the only methods of explaining design that is essentially static. I can't "erase" something that I just told the person on the phone. I can't "re-arrange" snippets of code that occurred at past points in the conversation. Second, it requires describing things at length that could easily be described in subseconds visually. Whiteboard designs are really great in that they do allow for a quick dump of an idea, and this outline can easily be expounded upon dynamically. Finally, it doesn't account for the fact that there are many tools in common use for programmers in standard development environments, and asking anybody to program without them is slightly crippling. Yes, everybody should have a strong enough core that they can do design on paper, but it is rare that any person could spout off code with proper syntax without tripping over their tongue.
I'm sure I come off as somewhat of a dunce after this one question had burned up most of the remaining time, but finally got to the portion of the interview I was most interested in: my questions about Amazon for the interviewer. Although I was exciting about the chance, I wasn't yet convinced that this position was right for me. My previous job had afforded a lot of lifestyle aspects which I had come to value, and allowed me to work in a field I'd grown to like. Despite the onslaught of questions nobody up to this point had told me ANYTHING about the position...just that it was for the Amazon Search group. I asked him a few questions to try and gauge culture, then one question meant to get a grasp on how their infrastructure could allow for innovation from even the smallest cogs of the machine. His answers were very ambiguous and didn't really clear anything up for me, unfortunately. I ended the interview feeling even more uncertain about the position and wasn't so sure I'd get called back.
The second interview did come, a few days later, though it ran very similar to the first. A few questions about OOP concepts, then another over-the-phone programming question. The first(stack implementation that with O(1) push, pop, and find smallest element) only required an explanation, and I got to a solution in reasonable time. I think that I was overcompensating for working through things in my head, and might have verbalized my thought process a little too much. The second(binary search on sorted array), to my chagrin, was more over-the-phone Java code. I didn't want this time to confound the interviewer with revisions and verbalizations, so I was quiet for several minutes while I worked out a solution, then read it back to him. I'd done it recursively, and he confronted me about that fact, but said there wasn't much time left. I saw the iterative solution immediately and quickly explained(not in Java) the solution before moving onto my own questions.
This was the first time I found out a clear answer on what the position entailed. In asking my questions, though, I got the vibe that me and the interviewer were both reaching the same conclusions, that this position wasn't a good fit for me and vice versa. It seemed to me that Amazon.com was the kind of job I always swore I'd never do, the TPS-reports, Office Space type gig where I'd be a worker drone in some giant organization who never got to utilize my creative talents to shape the vision. Coming off a job where I played a pivotal role in doing some cutting edge things in a crowded and growing field, I didn't think I'd survive moving backward to move forward in my career. At any rate, I got confirmation just a few days later, with an email from the recruiter saying they were passing me up on the position.
But, as Shakespeare says, "All's well..." It turned out that one of the other positions I was looking at in northern Utah was moving fast on filling a position for a developer, and I was a prime candidate. After a really good interview, and a short wait, I was extended a fairly reasonable offer. The company seems to be a great environment, and thusfar I have been very excited about the work they are doing, as well as feeling pretty comfortable with my new co-workers. All in all, I feel quite lucky to be working again after such a short time on the hunt, and in truth, even with the Amazon.com opportunity, the position I ended up taking was my top pick.
The job hunt itself was pretty painless, especially considering that my family was not in immediate financial distress. I posted resumes on some of the bigger job sites and began looking for something in the region. While there weren't many opportunities close to where I lived, I did experience a pretty steady trickle of leads from recruiters. Fairly early on, I was called out of the blue by a recruiter from Amazon.com. Apparently, a project manager had seen my resume and thought they could utilize my background working with indexing and search engines.
While this was a great opportunity, and instilled some degree of confidence that I'd have little trouble landing a position soon, it was kind of intimidating. Amazon.com has an interview process that had a reputation online for being fairly competitive, and I'd never really gone up against a technical interview that went beyond simple questions about OOP or a specific language.
I did some research, tried to look at other people's experiences with interviews and what sorts of questions were normally asked. While I'd been working in software development for the last few years, it'd been about twice as long since I'd learned from a book on the topics I'd likely be quizzed. Despite this, it seemed like an opportunity that couldn't be passed up, so I schedule the first of what is generally three interviews(two phone, one onsite).
I won't go into too fine a detail about the contents of the interviews, as it isn't really relevant to anybody but a prospective employee. In general, although I studied pretty decently on a variety of topics, the interviews didn't really align with what I expected. I reviewed a lot on theory, on common algorithms for search and sort, and made sure I could easily answer any OOP definitions or concepts.
My first interview went reasonably at first, with him asking some questions about Java syntax and OOP concepts. It did hit a snag, though, when I was asked to code a very simple problem(code an indexOf() for an array). I had worked out something in a matter of seconds, and then spent far too long muddling through handing him syntactically accurate code over the phone.
I have to say that this is quite possibly the worst imaginable way to assess design abilities. I did probably dive into it a bit early, mostly because it was quite clear in my head and seemed so simple that it didn't even require my writing it down for myself to see. Nonetheless there are a number of flaws in asking questions like this. First and foremost, it is one of the only methods of explaining design that is essentially static. I can't "erase" something that I just told the person on the phone. I can't "re-arrange" snippets of code that occurred at past points in the conversation. Second, it requires describing things at length that could easily be described in subseconds visually. Whiteboard designs are really great in that they do allow for a quick dump of an idea, and this outline can easily be expounded upon dynamically. Finally, it doesn't account for the fact that there are many tools in common use for programmers in standard development environments, and asking anybody to program without them is slightly crippling. Yes, everybody should have a strong enough core that they can do design on paper, but it is rare that any person could spout off code with proper syntax without tripping over their tongue.
I'm sure I come off as somewhat of a dunce after this one question had burned up most of the remaining time, but finally got to the portion of the interview I was most interested in: my questions about Amazon for the interviewer. Although I was exciting about the chance, I wasn't yet convinced that this position was right for me. My previous job had afforded a lot of lifestyle aspects which I had come to value, and allowed me to work in a field I'd grown to like. Despite the onslaught of questions nobody up to this point had told me ANYTHING about the position...just that it was for the Amazon Search group. I asked him a few questions to try and gauge culture, then one question meant to get a grasp on how their infrastructure could allow for innovation from even the smallest cogs of the machine. His answers were very ambiguous and didn't really clear anything up for me, unfortunately. I ended the interview feeling even more uncertain about the position and wasn't so sure I'd get called back.
The second interview did come, a few days later, though it ran very similar to the first. A few questions about OOP concepts, then another over-the-phone programming question. The first(stack implementation that with O(1) push, pop, and find smallest element) only required an explanation, and I got to a solution in reasonable time. I think that I was overcompensating for working through things in my head, and might have verbalized my thought process a little too much. The second(binary search on sorted array), to my chagrin, was more over-the-phone Java code. I didn't want this time to confound the interviewer with revisions and verbalizations, so I was quiet for several minutes while I worked out a solution, then read it back to him. I'd done it recursively, and he confronted me about that fact, but said there wasn't much time left. I saw the iterative solution immediately and quickly explained(not in Java) the solution before moving onto my own questions.
This was the first time I found out a clear answer on what the position entailed. In asking my questions, though, I got the vibe that me and the interviewer were both reaching the same conclusions, that this position wasn't a good fit for me and vice versa. It seemed to me that Amazon.com was the kind of job I always swore I'd never do, the TPS-reports, Office Space type gig where I'd be a worker drone in some giant organization who never got to utilize my creative talents to shape the vision. Coming off a job where I played a pivotal role in doing some cutting edge things in a crowded and growing field, I didn't think I'd survive moving backward to move forward in my career. At any rate, I got confirmation just a few days later, with an email from the recruiter saying they were passing me up on the position.
But, as Shakespeare says, "All's well..." It turned out that one of the other positions I was looking at in northern Utah was moving fast on filling a position for a developer, and I was a prime candidate. After a really good interview, and a short wait, I was extended a fairly reasonable offer. The company seems to be a great environment, and thusfar I have been very excited about the work they are doing, as well as feeling pretty comfortable with my new co-workers. All in all, I feel quite lucky to be working again after such a short time on the hunt, and in truth, even with the Amazon.com opportunity, the position I ended up taking was my top pick.

