Amazon knows full well what the LP interview experience is like, and it's by design. It's not about "how much you want to work at Amazon", but it's also explicitly, intentionally not about "actually getting to know you".

My friend told me that every Amazon employee has to go through an interviewing training course where they are explicitly told they are not allowed to ask any questions that are not directly related to an LP. In most cases, they don't even get to choose the LP that they are asking about. They are given a specific list of 2-3 LPs, and told that when they come out of the interview room, they must have asked questions about those 3 LPs, taken the answers down as notes, and are explicitly told that they must not ask any other questions or take any other notes.

The explanation I was given is that this is all an intentional attempt to make the interview process as impersonal and consistent across candidates as possible. They intentionally do not want to ask any questions that would lead you to talk about your education or hobbies outside of work, and they intentionally do not want the interviewer coming up with their own, not-pre-approved questions. Apparently they think that this makes it less prone to bias, which I suppose is a good thing in theory, but in my opinion, the execution resulted in a piss-poor experience as a candidate.

Apparently it isn't fun for the interviewers, either. My recruiter warned me that my interviewers would likely be rushed, impersonal, and focused entirely on recording notes about our conversation, because apparently if you are designated as an interviewer you have very strict quotas on the amounts of notes you have to take, and then as soon as the interview is over you have to rush immediately to another interview where you again have to take a certain amount of notes. The entire process sounds awful for everyone involved.

As an ex-Amazonian that did my fair share of interviewing, I can share additional context on some of the above:

* Tardiness and just the general unprofessional handling of someone being interviewed: At least in the area I worked this would have been unacceptable and the interviewer would have had a very uncomfortable conversation with their leaders. I can't imagine a repeat offender lasting long. There was a huge emphasis placed on the importance of the hiring process, the importance of doing it well, and that finding the right people was about the most important thing to be doing. Obviously at a company of >700k people it's not going to be a consistent experience across the board. * I learnt this from various forums before I attended my own interview so it's not exactly a company secret: but yes, each interviewer is told the LPs they'll be asked to assess. You're expected to spend the full 55-60mins asking questions on those LPs to maximise the change the person gets the job. It's too easy to burn 20mins talking about hobbies and ultimately that's not going to help the candidate get the job. Even worse is that if there's suddenly some shared interest and experience that conversation derails into enjoyable but more unproductive conversation. The feedback skews to "I like this person" and is filled with bias vs "here is the examples for why they'll be successful here". * The standard set of questions is a leveller to give everyone a consistent experience and try to reduce the likelihood that someone gets a job just because they interview well. * Likewise the seemingly unrelenting questioning that's effectively trying to gauge examples for just 1-2 LPs in my experience provides a fairer experience to most other alternatives I've experienced. People with pre-canned answers that they're able to spin nicely start to fumble when people want to keep digging into the details on the same thing for more than 5mins. Conversely people who struggle to think of the right words off the top of their head, or are especially modest about their accomplishments, don't immediately suffer. They're given a time and space, and ideally a lot of guidance, to expand on things. * There's no quota the amount of notes you need to take. However, the debrief for every single interview loop I was part of was always 30-60mins. You don't get to show up with some vague feelings about what the next step is. You need to come with an opinion, with the evidence to support it, and not waste every other interviewers time. If you disagree with another interviewer you need to be able to point at the specific evidence you have either for or against the candidate. We'd often be told "absence of evidence is not evidence of absence". You needed the evidence for whatever point you wanted to make, otherwise you've just wasted the candidates time. * The rigour in the post-interview process and debate, which builds upon the foundation of all of the above activities, is ultimately what it's in service of IMO. Every candidate gets case heard with all of the most compelling evidence that can be provided. I've been involved in debriefs where all but one interviewer came with a "not inclined/do not hire" decision. The discussion and debate that ensued and the recalibration from the collective notes ultimately flipped everyone to a hire. I'm pretty sure every other company I've worked at would have had such a debrief be over and done with in a couple of minutes and we'd move on to the next interviews. * The other part of this that's not always immediately obvious is it's a pretty binary assessment. You can either do the job or you can't. If you can, as determined by the debrief, you get an offer. So first through successfully wins. There's no stack ranking candidates against each other and trying to apply some subjective assessment of who is in a relative sense the "best". Which is again why there's such a strong emphasis on consistency, removing bias,

It's definitely not perfect. It can skew very heavy towards feeling impersonal and like the candidate is being interrogated for an entire day. The thing I missed most about vs other places I've worked was the interrogation feeling like a reinforcement of the power imbalance inherent in a job interview vs levelling the experience and making it just as much for the candidate "would I want to work here/with these people?". But on balance it's probably the most consistent and fairest approach I've experienced (when properly executed, which it wasn't for you, so I'm sorry you saw the worst of it).

Good intentions fail at some point, even when people have the best of intentions. Being distracted. Trying to do too much. Whatever. Where possible it’s better to design the environment and system so that the right things occur (or are more likely to occur) irrespective of an individuals good intentions.

So yes, you’re right!

Wasn't well treated at interview day (people forgot me in a room for several hours for example, also had interviewers arrive late, among other issues), and probably didn't pass because there was some questions about LP that I couldn't answer, basically all interviewers without exception asked the same question on how I handled an issue in a large team, except I never worked in a large team, whenever I told them that, they would ask the same question, but worded differently.

It became obvious to me that I should have lied, should have written before going to the interview some fictional stories that I could use to answer the LP questions.

1. They have a lot of problems with people who come and can't get stuff done in a giant organization

2. They don't try to teach newcomers how to get stuff done in a giant organization. Which would be the obvious answer to those problems.

I'm admittedly stretching a little, but I find more often than not the kinds of questions people ask tell you a lot about what they're trying to select for. (Or, for a lot of orgs, that they have no idea what they're trying to select for.)

Regarding the LP interview format itself, it's just a vanilla Behavioral Interview. See: https://www.thebalancecareers.com/behavioral-job-interviews-.... It's becoming increasingly uncommon in tech (because people are preferring whiteboard coding instead), but it's one of the most common interview formats you'll see in most white collar professions.

Not denying this part. Candidates at most companies are openly advised about the Behavioral Interview format, and told to come prepared with a collection of stories. Even Google's previous head-of-HR tells all job-seekers to do exactly this (https://www.linkedin.com/pulse/win-every-interview-6-steps-l...). This isn't unique to Amazon in any way, and Amazon might actually be better because they give you very strong hints as to what the questions will be, instead of expecting you to know this implicitly.

My previous comment was mostly responding to stuff like "ask very veiled questions and you're supposed to know that they're asking about an LP" and drinking the Amazon kool-aid.

Not when I interviewed with Amazon. Most companies don't tell you which questions you may be asked about. In my Amazon interview, the questions were directly from the LP. Not disguised as such. Not even rephrased. Example: "Tell me about a time you disconfirmed a belief." This may be a good thing in that it helps the candidate prepare, but it's a bad thing in that often the interviewers are just following a script.

I've never had a behavioral interview that was not a conversation. Only at Amazon was it a "drill". Rapid fire questions, with little to no scope for exploring a topic. It wasn't an interview, it was an interrogation, mostly phrased to put me on the defensive.

> Even Google's previous head-of-HR tells all job-seekers to do exactly this

I agree it's good to come prepared with a bunch of stories. However, the behavioral interview I had at Google was nothing like that at Amazon. It was actually a 2-way conversation.

The fact that Amazon told you what questions you'll be asked, whereas other companies don't, most people would say that is more interviewee-friendly. I certainly wouldn't see that as a negative.

Funny enough, the other commenter had the exact opposite experience as you. "I don't remember any interviewer at Amazon asking anything remotely straightforward about any of the LPs". Just goes to show that YMMV.

> Only at Amazon was it a "drill". Rapid fire questions, with little to no scope for exploring a topic. It wasn't an interview, it was an interrogation, mostly phrased to put me on the defensive.

Sounds like you had some bad interviewers. That certainly doesn't excuse Amazon for not better training their interviewers, but what you experienced is a bug not a feature.

Maybe it was the group I interviewed with? I do know the position had been open for many months, so maybe they were just terrible interviewers.

The questions didn't seem too veiled, but maybe that's because I knew what to expect.

Is this unusual in your experience? I don't think I've ever been to a job interview where I didn't bring along a notepad where I had prewritten talking points, and also used it to take notes during the interview. I thought this was standard.

[0] Situation - Task - Action - result, basically your story tellling format for Amazon interviews. Back the day it was even covered on their interview prep page.

Also, and I don't know if there is a nice acronym for it, but I like the formula where you:

1. Say what you're going to say

2. Say it

3. Say what you said

So if the question is "Tell me about some things you consider when you need to do task ABC," You structure your response like this:

"I'm going to describe the top three things I consider. 1. Foo. [Details here]. 2. Bar. [Details here]. 3. Baz. [Details here]. In summary, Foo, Bar, and Baz are the things I consider in that situation."

Is a much better response than unstructured word salad that contains the same detailed content but jumbles it all together and kind of trails off, leaving the interviewer wondering if the candidate is done talking.

Then finally, happy people generally don't go out an write a huge essay on why things are fine. unhappy people will go on-and-on about every bad thing to anyone who listens.

Thus, we're left with disorganized reports on various sites to glean culture. Eg HN comments on the story about Amazon suing Brian Hall. https://news.ycombinator.com/item?id=23461326

For those looking to move within the job market, it would be worth it to talk to a tech recruiter for a few hours who's job it is, is to know company cultures. (Traditionally, if you, the new employee that they managed to get into a company with a bad fit, leaves before 90-days are up, they don't get paid.)

IMO this is very good advice. Having been on both sides of the equation, I think a good tech recruiter (emphasis on good) brings a huge value to the process. As a hiring manager, I had one guy I knew I could rely on to bring me really qualified candidates every time. His own filter was excellent, and he only brought me people that were a good fit. I almost didn't need to interview them. Other recruiters were terrible, one even sent me a candidate who had faked their first phone screen so they weren't even remotely qualified for the job.

That is the guy you want to know. He has earned his reputation. And it cuts both ways, too -- his success isn't just when the company is happy with him, but when candidates are too -- all the best ones are his clients, after all.

https://www.teamblind.com/

Dig up some fake creds on BugMeNot and poke around Glassdoor

They often initiate contact. I respond. And they don't respond back.

Even worse is when they do. Several times in the past year I had a back and forth with some recruiters, did an online and/or phone screen, and they said "OK, you've passed all the screens, and we're ready to schedule you for an on-site. You'll get a call to schedule it." I never get the call and the recruiter stops responding.

Then the next recruiter that talks to me asks "I see you were ready for an on site but didn't have any. What happened - did you withdraw?"

My response has always been "You tell me. The recruiter stopped responding to me."

This is always followed by profuse apologies. And then it happens again.

A friend of mine suggested I tell them "Can you ask the previous recruiter, and once you find out put it on my account?"

A few days ago I got this message from an Amazon recruiter (his first contact with me). After the initial introductions on who he is, etc:

---------------

Good Afternoon, I hope that this message finds you well and with an opened mind. My name is * and I am a Recruiter with Amazon’s Worldwide Operations – HR team We have an immediate need for a Software Development Engineer (SDE) with Amazon. Your background looks like a really good fit. I'd like to see if the role aligns with your next career move.

We currently have multiple locations; Seattle, Washington and REMOTE, we will provide relocation assistance if applicable.

I have included a link to the full job descriptions to give you more details on the team and position.

If you would like to move forward in the interview process, please provide answers to the intake questions down below and I’ll follow up with you on next steps. If you have an up to date resume please send that as well.

(1) The best phone number AND email to contact you?

(2) Do you have any pending offers at this time and, if yes, what the deadlines are?

(3) Do you need, or will you need in the future, any immigration-related support or sponsorship from Amazon in order to begin or continue employment with Amazon and when does your sponsorship expire?

(4) Are you open to relocation?

(5) What are your salary requirements(range)?

(6)What coding language do you have the most experience with?

(7)Do you have experience using Cloud Platforms(AWS, MS Azure, Google Cloud)?

(8) Have you recently been in contact with someone at Amazon?

(9) Is most of your experience Back-End or Front-end and what Percentage?

(10) Do you have experience with System Design and how many years?

(11) Scale 1-5(5 being the best) how comfortable are you with Data Structures and Algorithms

For some reason if you are happily employed but know of someone with a similar skill set please send them my information.

Thanks

---------------

So let me guess: I'll spend the time responding to all his questions, and never hear from him again. Sorry, not bothering.

I expect Amazon has a high turnover of recruiters too.

Or in other words it tests how much free time you have to spend on unpaid activity, which can be a good proxy for ageism.

No kids or mortgage? Then you're a perfect candidate to spend countless unpaid hours studying for months, going through mock interviews, reading books, testing your skills etc. to have a shot at working for us.

This works well for tech companies because many don't care about your experience with languages and frameworks of yore. More so whether you can put in 80 hour work weeks.

>If there was a perfect correlation between pre and post entrance test performance there wouldn't be PIPs, performance based layoffs etc.

Nothing is perfect, saying it's useless because it's not perfect is a silly argument.

edit: I'm talking about large tech companies, not the startups blindly copying their policies with little thought or consideration.

edit: It is also very reasonable to study having done it myself and talked to people who have gotten into these companies. At 15 minutes a pop you can do 100+ leetcode questions a week. Spend a few months and you'll have studied almost every reasonable question. Most of them are repetitive patterns but around 5% have tricks you need to memorize. That covers 2-3 out of your 5 interviews. Behavioral you need to memorize around 5 questions that they'll basically give you ahead of time. System design is harder but there's videos for the 10 topics that will cover 90% of the potential questions.

By that logic, most people would have completed all 1500 LC's in 4 months.

Numbers say otherwise. Each medium difficulty problem takes an hour to solve, assuming you can come up with a non-brute-force solution. Most of them force you to lookup, understand and implement other people's ideas.

If you can do 3 problems a day, completely on your own without any lookup, you're doing good pace.

When someone comes in and bombs, that is at least valuable information: we don't want to work with this person. When someone comes in and seems smart and capable, but makes hardly any progress on the problem because it's obviously their first time on a whiteboard, it's just regrettable all around.

We're not selecting for preparedness. In fact, we try to select against it: interviewers take pride in designing twists that separate understanding from recall. If you seem to be recalling, we're supposed to pick a different question, or failing that, report a null signal. But we do need you to be prepared enough that your interview skills don't get in the way of your actual skills.

And you're missing what these tests are actually doing instead: Figuring out which people have already seen the problem at hand, and probably memorized all/some of it.

The problem is that these interviewers will not pass you if you don't solve the problem almost perfectly in an amount of time that is way too small for someone who has never seen it before.

To make matters worse, many of the solutions require some trick or mathematical trivia to get right. Does that really prove you know your Algos & DS?

That is literally my point. They are very much testing your ability to study for months on end. Study as in memorize. That is by design at this point and not a side-effect. If you aren't willing to show the ability to study successfully for months on end then they're not interested.

edit: Over the course of months of grinding leetcode you will see 99% of the problems they are going to ask. Then it's about memorizing the tricks and patterns.

edit2: And as I said below their recruiters are very open about what you need to do (grind leetcode) to succeed at the interview.

FAANG employers want innovators who think outside the box. You can't do that with sheer memorization. Nothing new would be developed if tech companies hired people who just worked with what they already knew.

There's a difference between software engineers and coders. If tech companies didn't want engineers, they would simply hire coders from a coding boot camp.

I think tech interviewing is somewhat similar: are you focused and dedicated enough to learn something arbitrary and produce code for it?

TIL I've been "hacking" all their "tests" :D acing them just by curiosity & interest in computers in general, a bit of intelligence and a lot of laziness!

But the same skill is transferable across arbitrarily many companies. This is why many prefer interviews to take-home tests, so that they do not invest too much time in any particular company.

Here's the truth that nobody wants to believe: you will never know how good someone you've never seen perform will perform until they actually perform.

Allow me to translate: work indiscriminately long hours in their prime years to make someone else rich from a product or service that will close up shop as soon as the VC money dries up.

Usually, it’s when startups want employees to work longer hours than the value the they’re calculating on receiving from the equity+pay that’s being offered.

With the recent VW scandal of modifying software to cheat at pollution tests we can eliminate safe in for that company.

Anyone remember when Ford accountants calculated that a Pinto defect in which people would burn to death would be more expensive to fix than the lawsuits so they decided to not recall the car?

"Profit from selling cars" would be a much more honest mission statement for most of them.

The vast majority of people who work at FAANG type companies do not do any of this.

"Grinding leetcode" is a phrase for a reason!

Think about it: you are passing an exam. Why wouldn't you study the questions that you know are going to get asked?

It got even worse lately since every candidate does this, it raises the bar for the expected solution.

maybe the people you know there don't want to admit they spent some time studying questions? Maybe they bought into the cult of the "Google only hire the top 1%?" (which is very far from being the case).

FAANGs interview are the most predictable tech interview in the industry, why wouldn't you do it?

Looks like you got rejected and found a reason to attack everyone who works there. Like I said, this works both ways.

This is the exact attitude that makes people have terrible interview experience.

Companies that don't do the above usually advertise requirements for X technology with Y years of experience. A smart programmer without knowledge of X can learn it easily, but he won't even be called for an interview.

Most devs use a handful of algorithms in their entire career. And any algorithm they do use was probably adapted from pseudocode on Wikipedia.

It really comes down to what do you want the developer to do? Are the things you're testing them on even relevant to the job?

I'd argue what most companies are testing through their interview process is largely irrelevant.

If it's a generic programmer, then it's perhaps a position where's there's a range of technologies, maybe a range of languages to pick up and a range of existing software to support. Well in that case you want someone who's quick to learn and eager to train themselves, not afraid to ask questions, not afraid to admit they don't understand something, etc. Whether they can write quicksort on a whiteboard is probably the stupidest thing you could interview them on.

I think the best kind of interview isn't overly technical, but rather one that prods the interviewee to think about problems. Describe a fictional system, what would they suggest to make it scaleable? What would they suggest to improve performance? What would they suggest to reduce the time between writing the code and shipping it. Do they understand what a CI/CD system is? Are their first thoughts "rewrite everything!"? Do they think about iterating software development or are they the kind to dump 200 files on someone for code review?

These questions are very senior dev focused, not so sure I'd ask a junior candidate much in this direction. But I always did a question like this when I did my share of interviewing. And the idea is basically to see if the candidate has been around the block. Have they seen the sausage being made, or do they only have academic understanding of the software engineering profession?

And being on the other side, some of the best questions I've gotten was always like "describe the weirdest problem you've encountered". Talking about unexpected shit usually leads to a fun discussion, and you can showcase your ability to problem solve.

But what's the content they should be interviewed on? You say no to quicksort. How about date parsing? That shows you have to handle messy cases.

What do you want them to write if not algorithms? Maybe we have a different expectation of what "algorithm" means? The term is pretty generic, but I feel captures more of the cross language stuff.

Compare a "How does javascript handle equality?" question which falls under "trivia", vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.

But why? The vast majority of programmers don't ever need to write code to parse a date. It's just another test completely irrelevant to the job.

>Compare a "How does javascript handle equality?" question which falls under "trivia", vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.

Both are pretty bad interview questions. Is this a Javascript position? If they don't know how it handles equality do you really think that is the end of the the world for the interviewee, does that make them a bad programmer? It's something you could explain to them during the interview in under 5 minutes (and you should, it eases the pressure on the interviewee). So really what's the worth of asking it?

Likewise, "implement a hash table". Pointless. Ask them "Do you know how a hash table works under the hood?", chances are they might not know exactly how to implement one but they do understand roughly how it works. If they don't know then describe a simple implementation and quiz them on why it's built this way, do they understand the "why" even if they don't understand the "how". Most competent programmers can implement a hash table given an explanation of how it works which is why I don't think it's a good question to ask someone during an interview. It's just a memory test, not a test of how good they are as a programmer, how good they'd fit into a team, how good they would be at designing a large system, how good they'd be at weighing up the pros and cons of different solutions.

This is why interviews should be discussions, not tests.

I disagree, anyone can write out an algorithm from memory. That's not hard, and does not prove that you know what you're doing.

I've done my small share of interviewing, and I always did a little bit of whiteboard coding, but the objective was never to see if the candidate remembered algorithms, but to see if they could execute code in their head.

Because I've encountered "programmers" who clearly couldn't execute code in their head, and whose idea of programming was copy-pasting something and heuristically modifying it until it did what it was supposed to do, instead of knowing what the code does. And you really want to make sure you screen for this group so that they fail the interview.

From this relatively simple question, I get a lot of insight into the candidate's skill level, i.e. how well do they write code? and it has nothing to do with algorithms.

That doesn't indict the fact that's the exception and that software programming almost never looks like that.

The real problem is that take home problems are trivially gameable - it's obvious to someone unscrupulous who's not a well-seasoned coder, that it would be well worth paying someone else to do their take-home-interview-homework. (Sure, that would come out eventually, but that's only one of the problems I have with take-home assignments.)

Some places have "open book" interviews, where it's like "here's a laptop, do this thing, and google/stack overflow/devdocs" your way to victory, which is at least better than the older "how much trivia do you remember about this API"-style questions. But I have no idea how to go further and make that unbound by time when an employee is on the other end of the table listening to the interviewee's thought process, if only because it makes it very hard on the interviewer to plan their own time. (Especially considering maker vs manager time.)

In the years I have been doing take-home exercises for candidates, I have yet to see a single instance of a great take home leading to a terrible on-site or hire in terms of technical skill. There have definitely been great take-homes for candidates that we later chose not to hire, but usually due to challenges interacting with the product team, or in some cases too much fixation on technical perfection with no focus on business realities, etc. If there are a large number of candidates paying others to do their take homes for them, they should be asking for refunds.

Second, even if this is a problem, there's a very simple solution. For candidates that do well on the take home, either on a call or on the on-site, do a live code review with the candidate and ask them to explain a bit more about why they wrote the code the way that they did. Ask them questions about other approaches, or what they'd do if they have more time. Candidates will be significantly more comfortable talking about their own code they wrote. It'll be quite clear if the candidate didn't write it themselves.

Anyway, I thought it was robust but not too time-consuming interview process. I think such an interview could use a reasonably-sized open source project for this, instead of their internal code base.

For large companies like FB or Goog, if they lose a few people to false negatives, it's fine because there are hundreds more lining up.

Either way, from the large company perspective, the system works. Most notably, it's really efficient.

The issue is when small company A starts asking you to implement Tarjan's or something. That's where this interview process seems particularly damaging.

As a result, he pushed them to move more in the direction of "behavioral interviewing," asking people, for example, to describe difficult problems and how they had worked to solve them. That way you at least learn a little something about how the candidate thinks and about their style of communicating with a potential colleague about technical problems.

If I recall correctly, the only formal process that has been shown to actually predict job performance well is standardized testing of job-relevant skills. Maybe companies should spend more effort on identifying the more important job-relevant skills and work with testing professionals to come up with appropriate tests? Then they could save interviews for finding out which of the top performers seem like they're going to be pleasant to work with.

After the usual "tell me about yourself" stuff, the HR rep asked me what I knew about the company and was noticeably disappointed when I said I had only accessed the homepage and Glassdoor reviews. She swiftly ended the call after that, leaving me with "homework" to go through (go through more of their web page/web presence, meditate about their mission) after which I would be qualified to resume the screening call.

Later I re-read their Glassdoor reviews and they had other people had had basically the same experience. Strangest interview I ever had.

15 minutes gets you a general outline of what they do, a superficial notion of culture etc. I had that, but they wanted more in-depth knowledge of their products and culture.

Well, you dodged a narcissistic bullet, that's for sure.

Maybe I'm too old and jaded, but I can't stand corporate bullshit. I don't give a shit about mission statements or your product portfolio. Who has time for that shit?