The problem with "practical application" questions is that the answer almost always comes down to "it depends". The correct optimization or fix is specific to the actual thing you are doing; that's what makes it practical.
In order for an interview question to be useful, both the interviewer and the interviewee must be able to answer it. The applicant doesn't know the interviewer's product well enough to make accurate technical diagnoses. The person doing the interviewing doesn't know about the applicants' products either. Bogging the interview down in specifics to fill in the background is usually not helpful - plus, it gives lots of opportunities for the applicant to bullshit the interview by listing a bunch of technical details that might not actually have been accurate or important.
Theory questions are favored precisely because they are not dependent on nuts-and-bolts practical details. "Reverse a linked list, writing your code on this whiteboard" is general enough that most applicants can answer.
I understand that people who lack CS degrees might not know the answer. Interviewing means accepting that you don't get a 100% accurate result. I would only switch away from the "basic CS question" problems if I was convinced that some other question has a higher accuracy rating, and I'm not sure of that.
> The problem with "practical application" questions is that the answer almost always comes down to "it depends."
Agreed. Talking about application of theory is way too vague and leaves way too much room for bs. But I think my original point was unclear. I'm not suggesting that interview questions be "When would you use a linked list?" but rather "Let's hack on something using a linked list (something beyond just simply reversing it)." Like the article mentions, once you've built a linked list before and have optimized (and reversed) it to death, there's little to be gained from doing it again for somebody else.
The problem with "practical application" questions is that the answer almost always comes down to "it depends". The correct optimization or fix is specific to the actual thing you are doing; that's what makes it practical.
In order for an interview question to be useful, both the interviewer and the interviewee must be able to answer it. The applicant doesn't know the interviewer's product well enough to make accurate technical diagnoses. The person doing the interviewing doesn't know about the applicants' products either. Bogging the interview down in specifics to fill in the background is usually not helpful - plus, it gives lots of opportunities for the applicant to bullshit the interview by listing a bunch of technical details that might not actually have been accurate or important.
Theory questions are favored precisely because they are not dependent on nuts-and-bolts practical details. "Reverse a linked list, writing your code on this whiteboard" is general enough that most applicants can answer.
I understand that people who lack CS degrees might not know the answer. Interviewing means accepting that you don't get a 100% accurate result. I would only switch away from the "basic CS question" problems if I was convinced that some other question has a higher accuracy rating, and I'm not sure of that.