Do you think that being able to implement a linked list is a fundamental programming skill? Because if an advanced programmer is lost her ability to relate with novices ("my boss can't even implement a fucking linked list") I'd say that'd be a bad thing.
In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently mastered a skill.
It's a pretty damn fundamental skill; even so fundamental that I'm not sure if it even deserves a specific name.
As a linked list is nothing else but pointers and blocks of memory that are the nodes, and setting the pointers of nodes to point to other nodes. This is something any programmer worth his salt would soon deduce on his own even if he, for some mysterious reason, didn't know linked lists.
Many probably have in their younger days. And when they finally read about linked lists they go "ha, what I have written actually has a name". If you just merely keep doing allocations of similar structs or objects that you want to stash some place, you're implementing a singly linked list the minute you think of a "next" member in your struct.
Depends on the position. I have worked, recently, on codebases where that kind of thing was absolutely a core skill and we asked people to write linked list code in the interview process. We were also doing manually-managed core OS and display manager code for a mobile operating system.
In my current job writing server-side Java and Ruby on Rails code, I wouldn't dream of asking that question. It would be pointless.
Amen. I've worked perfectly happily and successfully in software for the last 10 years, writing what most of the software industry is writing - database apps.
I've never, ever, needed to write a linked list, a sorting algorithm, access memory directly and pass around pointers or any of the sample problems that are being cited here. I know the theory, I've done them in academia many years ago but I've got more important and useful things to remember on a day-to-day basis. These are firmly under the category of 'look them up if I ever need them again' and I'd be perfectly happy with a hypothetical candidate (I've not interviewed anyone in years) who said they knew the theory and would look up the exact details. I do that all the time with the more esoteric features.
At my last place, we did have a coding test as part of the interview. We checked all sorts of little things but could usually mark the entire test with some accuracy on the first question.
1. Please write a valid SQL inner join statement.
Seriously. For a position specifying SQL, to maintain an SQL backed custom business application, a majority of applicants couldn't write an inner join.
I suppose I'm saying - do whiteboard / paper coding tests, but do the _right_ ones for your projects. Don't give them a test on something that's clever but unnecessary for what you do, check they know the basics and are up to speed with independent learning and they should be fine.
In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently mastered a skill.