It's so stupid, all of it. They try to come up with random questions that doesn't mean anything if the candidate remembers the answer at that point in time.
I've read about Linux inodes. I know what they do. In fact I even have had Linux systems where I get inode related error messages because the partition had too many small files on it.
But given that question, in that situation, I would likely not know what they even meant with that question. Am i supposed to have all the inode details memoried forever in my mind? It's fucking ridiculous.
I’ve written a few Linux file systems and I’m not even sure I’d have answered that question correctly.
I’ve also failed job interviews where I was told there was no coding expected in the face to face and then got given a piece of paper and asked to solve 3 theoretical problems in SQL on paper while 3 interviewers watched. 10 years prior I’d worked for several years on Oracle middleware so I knew SQL inside and and out but I still lost my nerve at that interview and was told I wasn’t experienced enough.
There was another telephone interview where I was asked all sorts of command line questions, the problem there is they spelt out the command line flags differently to how I normally talk and read then (eg “what’s see hatech em ohh Dee seven hundred and seventy seven”, had i seen it written down I’d have been like “oh you mean see hatech mod seven seven seven” (chmod 777) but they way they read it out sounded cryptic has hell.
So there’s a valuable lesson I’ve learned for interviewing: putting pressure on interviewees is just as likely to filter out good candidates as it is bad ones. So you’re better off making them comfortable during the process. Good but nervous candidates will perform better. The interviewing process shouldn’t be about who can hold their nerve the longest.
There are moments in life when I wish everyone was forced to learn NATO phonetic alphabet early in school.
"Charlie Hotel Mike Oscar Delta Seven Seven Seven".
The reason to cram into people a standard spelling alphabet is that it minimizes confusion over the usual "see as in $random-first-name". The reason to standardize on the NATO one is that it's already an international standard, and a subset of the population that goes to work with anything resembling a radio transceiver will have to learn it anyway.
It wouldn’t have helped in the interview if they did use the NATO phonetic alphabet because when you read CLI commands or talk about them in the office, you don’t spell it out using the NATO alphabet.
The point was the interviewer read a written command differently to how I’d typically hear it. It’s a little like the S-Q-L vs Sequal debate and how that can sometimes throw people.
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.
I've read about Linux inodes. I know what they do. In fact I even have had Linux systems where I get inode related error messages because the partition had too many small files on it.
But given that question, in that situation, I would likely not know what they even meant with that question. Am i supposed to have all the inode details memoried forever in my mind? It's fucking ridiculous.