> while I peck at my smartphone and sigh every time you pause

This is a much bigger deal to me than difficult algorithm questions. Shitty interviewers give shitty interviews, regardless of what kinds of questions they ask.

The worst interview I ever had was like this. The guy showed up late, told me he forgot he even had an interview, gave me a strange question with little detail, and told me to start coding. Then ignored me for an hour while he typed on his laptop. Even when I directly asked for feedback to make sure I was solving the problem he asked and not a misunderstanding, he gave me basically no feedback. I've had interviews that I bombed before, but this was the first and only time that I felt like I bombed an interview and it was utterly not my fault. It was also the only time I've had a bad interview that actually ruined the rest of the day for me because it threw me off so much.

I think I would just walk out at that, at the end of the day this is someone you are going to have to work with or for.

I wish I had. If something like that ever happens again, I will.

> implement a red-black tree in bash

The only good answer to that is "I can't imagine why I'd ever need to do that, and if I had to anyway, I'd use a 3-2 tree instead because it's almost as good and nobody ever gets red-black trees right the first time."

I had two people this week, 10+ years "experience", fail at writing a function removing duplicate values from an array.

I have interviewed two "senior web developers" with "10+ years" of experience that were unable to tell me the difference between a 404 and 500 http response code. Of course, they had perfectly memorized answers about JavaScript closures.

who memorizes http response codes?

Presumably, programmers who are working with the web should have a passing familiarity with the most common categories; this isn't memorizing all of them, but being able to recognize the significance of 2xx vs 3xx vs 4xx vs 5xx codes isn't an unreasonable expectation.

Who can't tell the difference between a 404 and a 500?

Somebody who rarely instructs a user agent to make requests to a server.

This isn't entirely accurate. I told my RN Fiance this story and she said "oh 404, that's like... page not found or something isn't it?" She has zero programming experience.

So, basically, somebody who never uses a web browser? 404 and 500 should be familiar just from browsing the web for more than a few weeks.

Modern browsers seem to do quite a bit to insulate users from error status codes in their default configurations.

The people in question do in fact use internet browsers on a daily basis.

That's good to hear.

Programmers who want their REST API to return correct http response codes. I have a good many of them memorized by now. :(

...someday I'll find an excuse to return a 418.

Bah! Just always return 200 and if there's an error, make your users look for an error property in the json return value that contains a thoroughly unhelpful error message, like "I'm a teapot." ;)

Web developers spend most of their time in javascript - coding fronted where closures and functional programming matters a lot. Maintennable modern fronted is done that way.

They spend very little time staring at http error codes. Like, none.

Web development includes server-side, and that API the fancy JS code is interfacing with.

Node.js is javascript too :). Even there, error codes are something you maybe handle once when the project is setup and the rest of the time you deal with everything else.

Are you sure it was exact question about largest element in a one-dimensional array and not some highly obfuscated question about bees, trains and traveller bags?