In terms of topical content it's a good question. The idea that the name is a link stored in a directory entry is a key part of filesystem architecture and anyone familiar with unix filesystems should be able to immediately talk about why.
The problem here is that what could be an invitation to showcase knowledge is reduced to a vague, one-dimensional and non-obvious trivia question. There are a ton of valid answers to this question, like:
* The file data
* Extended attributes (ACLs, etc)
The topic is fine, but the framing of the question is terrible.
If I wanted to test a candidate's knowledge in this area I would probably ask: "Why isn't the filename stored in the inode?" -- this initiates an architectural discussion, rather than a poorly designed guessing game.
Guessing games in general are a red flag for the employer. They tend to indicate the interviewer isn't competent freely discussing the subjects at hand.
If your question has that "gotcha there is just one right answer"-feel to it, you are doing it wrong.
I had a teacher once who constantly asked questions like these in such an imprecise fashion there was no way anybody could have guessed how the question was even meant to be answered. I still cringe when I think about it, because the only purpose of these questions was to show us that he is really clever and we don't know shit — and it didn't work at all.
Personally, I have always approached interviews as an opportunity to either teach or learn. I pick a subject and drill down until either the interviewee reaches their limit of knowledge, or I do. Why is it like that? How does that work?
Then, we have a discussion. One (or both) of us is learning and we work out the whys and hows together. If I'm the one learning, and I hope that I am, I fact check the discussion after the interview. If not, I get a strong indicator not just for the technical level of the candidate but also how they operate at the edge of their comfort zone. I've found this can be a strong predictor of future growth.
> They tend to indicate the interviewer isn't competent freely discussing the subjects at hand.
Ding ding ding.
Even the question, as asked, was OK. The interaction with the interviewee wasn't.
OP's joke was clearly just asking the interviewer to be more specific. Instead of exploring the question with the interviewee (e.g. "well, can you think of something that one might naively assume to be in the inode, but that is not"), they get pissed? lolwat?
Yes and that's true of ACLs as well which I think underscores my point: Questions should be an opener to dialogue. A topic, not a conclusion.
Discussion of these whys and hows and whens is the most valuable part of an interview and will more accurately illustrate depth and breadth than any number of fixed questions.
The problem here is that what could be an invitation to showcase knowledge is reduced to a vague, one-dimensional and non-obvious trivia question. There are a ton of valid answers to this question, like:
* The file data
* Extended attributes (ACLs, etc)
The topic is fine, but the framing of the question is terrible.
If I wanted to test a candidate's knowledge in this area I would probably ask: "Why isn't the filename stored in the inode?" -- this initiates an architectural discussion, rather than a poorly designed guessing game.
Guessing games in general are a red flag for the employer. They tend to indicate the interviewer isn't competent freely discussing the subjects at hand.