[alaaibrahim]

I've interviewed a lot of people, and I've asked LL questions, besides other algorithmic questions, and mostly I ask these questions to new grads with no much experience. The reason is, if you don't have much work experience, what else would I ask you, it's something that you've been learning about recently in your CS degree, and I want to see if you can apply what you learned.

If you have work experience that is relevant, or don't have a CS degree, I'll ask something else.

For me I feel that a lot of people don't understand that an interview is a conversation, feel free to think out loud, ask questions, and ask for help. I want to see your thinking process, I don't really care about the actual solution.

[ramraj07]

Thanks. Unfortunately this is not the case always. I explicitly start interviews telling I'm not academically trained in CS even though I've been practically coding for decades, and I tell them if they ask some "in paper" CS question, I might not answer well. People still ask me to do merge sort - which frankly isn't even in theory that hard - but I think I've subconsciously refused to learn a sorting algorithm just so I can answer a stupid interview question (the day I need to optimize a sorting problem myself I'll learn it hopefully). Whenever the person still insists on asking this without any help, he also comes off as a douche who can only see in black and white.

Should I suck it up and learn these things to do better in interviews? Maybe. But thankfully this handicap became a nice filter and I'm in a nice job where people value real experience and "getting things done" more than linked lists and merge sort, so won't need to worry about dealing with these folk for a long time hopefully.

[valtism]

This is why I'm not going to apply for Google any time soon. Their entire hiring process seems to revolve around how much CS trivia you memorised at school.

[mark-r]

Merge sort is incredibly practical though, any time you have to sort a data set that doesn't all fit in memory at once. I've used it a couple of times. As you say, it's not that hard.

[giaour]

This has been my approach as well. I always make sure to talk about the experience with projects new grads may have encountered during their CS degree, but it’s hard to have an in-depth talk about your experience if you don’t have much.

[Jach]

Being on the interviewer side of the table more than the interviewee side, I like to think that almost all complaints about the terrible way "the industry" interviews are still valid, but that for the people I've interviewed, even if they share many of the complaints, I like to think most of them also think "well except with that guy, that wasn't so bad." Even though I've always been frustrated about not being able to really try the interview styles I want to try and have to somewhat conform to a terrible mold.

I may be kidding myself but I do think having an interviewer who gives a damn and recognizes "the industry" standard sucks is key. I disagree with you in that I do actually care about (aspects of) the solution, but that's not all I care about. Interviewers disagree with each other all the time on better ways to interview, but there's a whole class of interviewers who just don't care and will perform whatever HR or their manager or some other interviewer tells them to do. I think these also get the most complaints from interviewees. The possible exception is if you actually have a robust work-sample test with objective metrics.

Whatever the case interviewers should strive to make sure interviewees understand the parameters of the interview rather than hope the interviewees can read minds. Not all interviewers believe "it's a conversation" and some will penalize you if you ask questions, some will penalize you if you don't ask questions... As an interviewee it's an adversarial experience and without any indication from the interviewer to set expectations to the contrary it's no wonder interviewees will be guarded or choke or whatever else.

I don't like to give straight-up algorithm problems like "implement this data structure and one or two common client use cases for testing". But interviewees should prepare for it, even if they're not fresh grads, because "the industry" sucks at interviewing. What if you're forced to give an algorithm-type problem by someone higher up? I think interviewers who give a damn even a little can make this significantly better than the default archetype characterized by complaints.

For the interview I got hired from most recently I had the fortune of having interviewers who weren't robotic, they said "use any language you like, can you implement a stack?" and I typed "In python, stack = []". They had me elaborate a little, then we talked a bit about Python, I mentioned it can also be a queue if they wanted as the built-in array is quite flexible, then they had me do some other stuff. Having brainfarted "implement a stack with plain native arrays holding ints in Java (and the clever implementation of a stack with memory by self-referencing an object of itself)" in a prior interview I'm aware that even basic stuff can end up taking many minutes of time, I'm sure my interviewers thought that most candidates would take a certain number of minutes for the stack question, but they were dynamic and could ask other things rather than waste both our time. Meanwhile another interviewer I worked with did an interview where he gave someone a "standard" "reverse this string" problem and the person responded in Python with something like "str[::-1]" or similarly concise, but coworker made them do it again in the "standard" way. No, instead that should have been an indication to move on to a more interesting problem.

If I were made to give a linked list problem and someone responded with a good old (cons) from 1959 we'd be done. I wouldn't make them (defstruct) and (defun) their poor equivalent but instead move on to a more interesting algorithm problem that can use linked lists as a building block, e.g. something involving a BFS or DFS (and even though I like iterative versions of such they might very well hit me with a recursive solution, and that'd be fine). Back to the twitter thread I don't think the reason the linked list has endured has anything to do with lower power computers back in the day, since it was a common abstraction on much weaker hardware and came built-in with a variety of popular languages long predating C and long after C.