I'm not the parent but we're in very similar position (finding it very difficult to find decent .NET developers, candidates can't answer even the most basic algorithmic questions), so I'll answer your question for you.
I typically ask candidates to implement a function that calculates the nth element of the Fibonacci sequence, write a program that prints the values in a binary tree in ascending order and finally to implement an algorithm that finds the value of the element in the middle of a linked list. These are just "introductory" questions, but very very few candidates make past this stage so I very rarely get to ask serious / deep programming questions to candidates.
And believe me, I'm very forgiving on interviews and try to take into consideration that the candidate is probably very nervous, especially when they are fresh off the school, but what can I do with a candidate who can't figure out how to get the number of elements in a bloody linked list, even after carefully explaining how a linked list works? Or the ones who get the idea that they should be counting all elements but have no idea how? How could I discuss the finer details of type covariance or ask them how they would go on about implementing a face detection algorithm if they can't even come up with the naive solution to the Fibonacci "problem"?
> implement an algorithm that finds the value of the element in the middle of a linked list
I'm struggling to think of the last time I had to use a linked list for anything. I'd be tempted to give the troll answer: put the elements into a List<T> already, divide list.Count by 2....
Sure if it's doubly linked then you can walk it from both ends and meet in the middle, then think about how to handle the case where there are an even number of elements, but do you really want a serious answer about linked lists in .Net?
From a recruiting point of view, this kind of questions are indicators. They are easy to verify and they are correlated with some other, more relevant skills.
First, knowing your 101 Data structures is correlated to your Computer Science general knowledge. What relevance does it have? It depends on the job description. There are jobs that merely require churning out bland CRUD application code, and it does not make much of a difference if you know this stuff. But, in general, for anything that has strong performance requirements, it might be a concern.
By example, if you let me feed the troll, your solution shows a mix of cleverness, (potential) ignorance and unawareness of the high level goal.. that I might be concerned you would produce something like...
On the other hand, Linked lists also give you a hint of the ability of the candidate to manipulate pointers/references. This may or may not be relevant, again, depending on how often do expect to use this skill in your code base. A trivial solution would let you at least know that the person pays attention to detail and does not leave a mess behind. A more sophisticated approach gives you more information about actual expertise (like, if you know about cycle detection, this is a piece of cake).
> First, knowing your 101 Data structures is correlated to your Computer Science general knowledge.
I can't quite shake the idea that what you're really testing is if the applicant has been to the same kind of school as yourself.
> There are jobs that merely require churning out bland CRUD application code, and it does not make much of a difference if you know this stuff
I've seen some really interesting (and performance-constrained) code done in .Net that didn't use pointers or linked lists in any way. It's not either "bland crud" or pointers, that's a false dichotomy.
Of course, concepts like parse trees, A-B pruning or Hungarian method of optimization are things that are worth having a hold on. But "how often you expect to use the skill" of linked lists with pointers in many modern languages, Java and C# included, is effectively never.
No idea where the crap java code for a sorted list came from, hope you're not trying to put those words in my mouth!
In the .Net world, good companies do try to look out for "broader" developers who are aware of useful open-source software toolkits, and want to practice things like Dependency Injection, TDD, Continuous Integration etc. They generally make better coders.
Yes, I am aware of the CS vs street smarts debate. Everybody has its own opinion, and I am sure neither of us is going to convince the other, so I'd rather not go there.
At the end of day, you seem to miss my point altogether. Testing for the skill is not useful in itself. It is just an heuristic.
The industry is choke full with people that seem fairly competent and accomplished, who is able to produce code that fulfills the specification, but who also come with a collection of vices, bad practices, and simply cannot make trade-offs intelligently.
People like me wants to believe that, because CS foundations are not strictly needed for the task at hand, these people tend to ignore it for the same reason that they ignore other, more important, stuff that also is not strictly needed to complete the task at hand (but that will have a direct impact on the quality of your solution).
I am fully aware that there are great developers that do not come from a CS background. I am also painfully aware that there's people who excels at the CS 101 questions but cannot perform in a real world environment. At the end of day, this does not provide a final go or no go answer. It is just an indicator of whom you want to bring in for a deeper, longer interview.
> hope you're not trying to put those words in my mouth!
Not at all. I was just going on with the troll thing. Hope I did not offend you.
> At the end of day, you seem to miss my point altogether. Testing for the skill is not useful in itself. It is just an heuristic.
I see the point, I just disagree with it. There's some validity to using CS101 knowledge as a heuristic, but as you have admitted, it's not perfect. We just disagree on how imperfect it is.
That's not the point, the question is about understanding fundamental, abstract computer science concepts and being able to craft simple algorithms. Even if we don't manipulate these data structures directly these days in code, there are "real world" concepts that are very similar to these fundamental data structures such as HTTP redirection chains, various stages of a workflow and so forth. It is due to the very nature of computers that a good developer has to be able to find abstractions in real world patterns and solve problems using these abstract ideas. A linked list (or a binary tree) is a very simple abstract idea and it's a good device for measuring the candidate's skill at solving abstract problems.
Additionally, my view and experience is that unless we're trying to hire a specialist in a niche, domain knowledge (in this case, .NET) is considerably less important than general programming skills and abilities; a good developer with limited .NET skills would still write excellent .NET code, a developer who's very familiar with the .NET Framework but who's poor programming skills would be a liability for the company.
Last time my manager asked me to come up with a simple test for interviews I added a question with code and asked what it was: a bubble sort in C#. No one got it right, not even a "it sorts the array".
I typically ask candidates to implement a function that calculates the nth element of the Fibonacci sequence, write a program that prints the values in a binary tree in ascending order and finally to implement an algorithm that finds the value of the element in the middle of a linked list. These are just "introductory" questions, but very very few candidates make past this stage so I very rarely get to ask serious / deep programming questions to candidates.
And believe me, I'm very forgiving on interviews and try to take into consideration that the candidate is probably very nervous, especially when they are fresh off the school, but what can I do with a candidate who can't figure out how to get the number of elements in a bloody linked list, even after carefully explaining how a linked list works? Or the ones who get the idea that they should be counting all elements but have no idea how? How could I discuss the finer details of type covariance or ask them how they would go on about implementing a face detection algorithm if they can't even come up with the naive solution to the Fibonacci "problem"?