[anon_e-moose]

> None of these questions seem especially hard, and they're exactly the sort of problem that I face on a daily basis in my work.

Really? Do you invert linked lists all day? When the last time you had to traverse a binary tree? Genuine questions. I'm sure there has to be a mismatch between what we define as "those questions".

> They're also fairly discussion based

They're also performed wildly differently with no standards at all. I've had good coding interviews with the coding as a starting point for a conversation. But I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. The latter is particularly great at hiring professional interviewers rather than actual professionals at the job.

[quietbritishjim]

> I'm sure there has to be a mismatch between what we define as "those questions".

When I said "these questions" in my comment, I meant the questions in the article. That's what this discussion is about! Those are not inverting linked lists or traversing binary trees. They're about networking, asynchronous actions and time outs.

And yes, I do deal with those things all them. Maybe not every day, but certainly multiple times in each project. Ever had to deal with a timer where it might still be triggered even after you've cancelled it [1] (because its underlying implementation has already fired but the callback is still waiting in the completion queue)? Or even trigger twice because you then re-set it while the first callback was still in the queue? That's just an example, but that's exactly the sort of fiddly condition that permeates every corner of a heavily async or multithreaded / distributed system. If your work involves that then it's totally fair to ask about them in interviews.

[1] https://think-async.com/Asio/asio-1.10.6/doc/asio/reference/...

> ... I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. ...

Well, I agree, that's bad. But, as you say, the same questions can go either way depending on the interviewer. The very reason that I mentioned these being "discussion based" in my comment was because I took it as read that silly tricky questions are bad and to make the point that these questions don't seem to be designed for that.

Are we not allowed to ask technical questions in an interview just because some interviewers are bad? Should we be "embarrassed" about the questions in the article, as was said in the comment that I was replying to? That was what I was objecting to.