> But does anyone else get embarrassed of their career choice when you read things like this?
What specifically is embarrassing about it? 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. They're also fairly discussion based rather than having one silly trick answer (like the XOR trick that came up recently here). The whole point of an interview is to check that the candidate can do their job. What would you propose instead? We don't bother to interview and just cross our fingers and blindly hope they'll know what they're doing?
I can only assume that the real reason for your objection is that your job actually doesn't involve solving problems like these ones. Well, that's fair enough, and then I'd expect the interview for your position to look different. But why would you assume that there are no jobs that really need these skills?
Your comment about using a CSV file for a database seems unrelated. Maybe I missed the real point of your comment?
> 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.
> 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.
> ... 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.
What specifically is embarrassing about it? 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. They're also fairly discussion based rather than having one silly trick answer (like the XOR trick that came up recently here). The whole point of an interview is to check that the candidate can do their job. What would you propose instead? We don't bother to interview and just cross our fingers and blindly hope they'll know what they're doing?
I can only assume that the real reason for your objection is that your job actually doesn't involve solving problems like these ones. Well, that's fair enough, and then I'd expect the interview for your position to look different. But why would you assume that there are no jobs that really need these skills?
Your comment about using a CSV file for a database seems unrelated. Maybe I missed the real point of your comment?