If someone feels "insulted" by having to actually write code suggests that you're looking for a role where you aren't expected to actually write code. That's fine, but probably not what they're looking for.
Also, I'd advice you to be little more open to a fact, that someone with less experience than you is asking you questions. That's not a great attitude to find good jobs at big IT companies, that are often full of young, often brilliant people.
edit: typo
There's an old saying: a job interview is a two-way street. You are interviewing them (or should be) every bit as much as they are you. If the applicant asks a basic question about the position, the interviewer has a duty to either answer the question or say "I'm not sure what role this is for; I've just been asked to check your technical knowledge, and then we'll get you to the actual manager who can give you a better answer. Okay?"
If the interviewer is immature, arrogant, rigid, etc., and regards the interviewer-applicant relationship as an antagonistic one, and views the applicant as incompetent and dishonest until proven otherwise, the interview will have that flavor. To me, that is a red flag about the organization. Indeed, I've heard from many sources that Amazon is a toxic environment; I have yet to hear anyone say "Amazon is a terrific place to work! [for engineers/programmers]" I suspect that if you're a high level product person who comes up with a clever idea like an AWS feature, and are able to pitch it to the top management, then you're a star, you're well paid, and life is good. But for the people in the trenches... not so great.
Amazon isn't great environment in most of the pockets of the company (haven't worked there, but worked with a lot of people who came from there), so it's quite possible that you "dodged the bullet".
But only when pressed, you start to complain how interviewer is immature, arrogant, rigid. That's not what you originally stated - you had issues with an interviewer age and being asked to do coding. I'm not trying to defend the interviewer - it's very possible that they were bad interviewers - big tech companies push people early to start interviewing. But things that you complained about initially make it sound like you maybe also not a very pleasant candidate to work with, that comes into the interview with a lot of bias.
I work with younger folks all the time and 90% of them are perfectly fine; actually I enjoy their energy and drive (and there are plenty of older jerks out there). This guy, I didn't enjoy. When I hung up the phone, I was not angry, as I recall. Just disappointed that a great company would have such petty people vetting applicants. You don't have to agree with me. I'm not even sure what we're arguing about at this point; if you're just trying to prove I'm a jerk... fine, I was a jerk that day. Happy now? Have a nice day. I don't work at Amazon and I'm having a wonderful day :)
Unnecessary description.
The interviewer has no choice other than to ask you write code. You describe the interviewer as arrogant and immature, but to me the candidate who hangs up fuming because he was asked to do a little bit of typing is the one who is antagonistic.
Because most people can't. And they want to make sure you can.
I interviewed lots of people for a small company and multiple times I became convinced the person across a table would be a good hire (based on past work experience and soft talk) only to see them bleed to death on the first technical question. Demonstration of technical skill is absolutely crucial for an interview.
Personally I don't care about pseudo code vs real or syntax errors, but the price of a bad hire is much higher than a few more questions or round for a candidate. Also FAANG will always have enough senior CV on their desk to miss a few good hire...
Usually it's just some simple question that requires a single loop. We explicitly tell them they can use any language including one they want to make up as long as they are ok explaining how it works. When possible, I try to relate it to the conversation we've had up to that point.
I've had someone start off by writing "four" on the board when prompted to write a "for" loop and get stuck. I'm still not sure if he was truly inexperienced or just trolling. The resume looked solid to me and he spoke well about his experience. I had almost decided to just skip the coding question as a result.
It's basically "find the first string in an array of string that has the letter 'b'" difficulty of questions. Anyone who actually codes can whip something up in a minute and we can move on. But it's always surprising how many people spend half an hour on that and still don't get anything workable.
If some guy had a good employment history, maybe a GitHub with some examples of their skills and described an algorithm to me... Why would I doubt their ability to write it in code?
I wouldn't take that for granted. It's easy to gloss over details and edge cases when talking through an algorithm and it's not apparent until you actually write the code. Similar things happen when discussing things in meetings vs writing a formal document. I've interviewed plenty of people that were able to quickly come up with algorithms to solve a problem but really struggled to translate them into code.
> [I] let them think they made it all the way through the interview
Maybe then, although they get rejected later, they still won't be particularly upset at your company -- since the in person interaction was friendly and positive (i suppose), and you can take some time and write a friendly rejection email or phone call too (i suppose you have a template)
We always get several applicants with 10-20 years of experience who have programming projects on their resume or described in their cover letters.
But in our (very minimal) technical evaluations, lots of these candidates can't do anything at all. No coding, psueudo-code, nothing.
Usually, it turns out they have been really doing light IT work for years - using reporting tools, maintaining little scripts, even just some Excel jockeying. But they still think of themselves as software engineers.
My gut feeling is that lots of these candidates could learn (relearn?) to code, but have spent years not coding.
I don't have the numbers in front of me, but I would guess that the majority of these types of candidates (10-20 years of experience) that apply to our roles can't code in an interview situation and haven't been programming recently.
It is definitely not all of the experienced candidates who fit that profile. The few very experienced candidates we get who can code are often excellent but are looking for salaries well beyond our range.
But we had 3 devs. I think he gave some great advice (and looking back - still think so 12 years later), but it just wasn't what we needed at the time.
The funny thing is, when we let him go (he knew it was coming - he wasn't blind to the problems) he got hired at a company we worked regularly with. Things worked out much better for him there.
The expense and time for study excluded many people and I have heard that whole villages would pool resources for just one son to buy the exam materials and take the time to study for the exam. Richer families didn't have need to sacrifice as such, of course. Typical success ratios were ~1:50 exam sitters. The Taiping rebellion was a direct result (among many) by such a man that failed his exams a few times (later declaring himself the brother of Jesus, but that's whole other story).
Though exam subjects changed over time, it typically included recitations of Confucian poetry, calligraphy, instrumental music, and other such gentlemanly subjects. You know, things you really need your bureaucrats to know to run an empire well.
Similarly with FAANGs (and previously with GMC/Ford/Chrysler, or in academia), the interview/exam is geared not towards the actual specifics of the job, but rather in the 'pruning' of the people and the appearance of legitimacy. They are selecting for people that will go through the hoops and the nonsense without questioning it and will make good bureaucrats (loyal, command-able, lacking vigor). Boat-rockers are selected out before they even start the irrelevant studying process.
Subjecting such person to a CS exam totally unrelated to what they will be doing (such as project management and leading a team of developers) is a complete waste of time for both sides and you still don't test whether that person has the skill they will actually need for the job.
But yay, you have found that they are great at inverting a tree or designing a complex hashing scheme at the whiteboard under pressure. Exactly what your company needs. Not.
Is the idea here that you wanted the interviewer to beg you to stay on the call?
I interview for a BigCo. Most of us do it not because we love interviewing but because 1) It's a way to check the "citizenship" box on performance reviews. 2) A director or VP sent a mass email exhorting us to join the interviewer pool. Everyone I know in fact views interviewing as a chore that takes away from one's day job. But, there's standardized training and emphasis on objective tests and rubrics to minimize bias. Given this assembly line process and the fact that most interviewers want to be elsewhere, there's very little reason to expect a random interviewer to want to sell you on continuing a process that you consider yourself above.
If a candidate proclaimed that they didn't agree to the terms of one of my interviews midway through, I'd certainly exchange a few words with them to try to make them more comfortable, but in the end I would by fine with bidding them farewell and being glad that writing up that interview feedback would be easy.
Some were doing it because they had to (last-second substitute) and it showed as they were rude about it or highly disorganized.
You don’t have to take it and it’s okay to cut interviews short as the interviewer (I’ve done it before), but it’s a mistake to be unprofessional about how it’s cut short.
Those same skills that let you plug Machine Learning Library A into Tracking Database B could make things that vastly increase productivity for a bunch of regular people, and if you're doing it for yourself or a small enough shop, it could actually pay off.
Source: Interview trained at Google
I recently had an interview where I had to use some remote collaborative web application and it was genuinely a horrible experience. The main interviewer (lead for the team I was applying for) was visibly annoyed with me because, for whatever stupid reason, some of the keyboard shortcuts he kept trying to bark at me, as I was working through some truly asinine leetcode-style questions, for things like block indentation were not working on my end and I had to manually tab multiple lines, etc...
The entire editing experience threw me really hard and was so distracting that I was fumbling what would've otherwise been trivial algorithm questions for me. Despite my 15 years of professional experience and a deep understanding of their tech stack (which, of course, was not a main discussion point at any stage of my interview process -- one of many red flags for me), if you had watched this you'd have thought I barely know how to write code.
I don't know what the answer is here but I have decided, and thankfully I have the privilege of making this decision, that I am done interviewing for a while.
This reminds me of the test for cooks. Make them slice up some fruit or vegetable. If you have worked in kitchens for years, you can do it really quickly. Fast and easy test, and nothing to prepare weeks or months for.
The point is that when you write out the code, there will be several other people who will end up looking at it as part of your “packet”. This can actually be beneficial for the interviewee: if you use some technique or library that the inexperienced interviewer has never seen, they might be confused and write negative feedback, but someone down the line will be able to see what you wrote and say, “Oh, this is actually really good.”
I get annoyed with those tests and interviews too, but I’m aware of the challenge on the other side so I take it with a grain of salt and would never let my ego make me arrogant enough to take umbrage at being asked to write down a piece of code. I can understand the frustration, but this process is applied equally along all levels. Hell, the most talented people I worked with were regularly interviewed on coding by people more inexperienced/less talented than them. I would have a hard time any of them expressing anything other than mild annoyance at the system that this is still the best we’ve managed to do and no one would think to say “what right does this young inexperienced person have to ask me questions”. If anything, that attitude would instantly disqualify someone on the “fit” axis of the interview even if they passed on the technical merits.
Additionally, I would probably translate that to be, "Unwilling to put up with what appears to be needless effort."