Hacker News Reader

Comment by etherael | Hacker News Reader

I had an interview for a systems administrative position way back when that was my primary gig, admittedly this was in the twilight after ten years of experience and I had already mostly gotten sick of systems administration and was deeply into coding so maybe I was just too jaded, but the single question I recall that they asked me I actually found so stupid it was insulting;

What's the default bytes per block in random linux distribution x version y when using filesystem z?

My response;

I'd google it.

Perhaps this is unique to the Australian branch of Google or something but I get the impression that they're much more into the whole meaningless rote memorisation of facts than is often let on.

I had a contact from another Google HR person a couple months back in Estonia, this time for a development position. I can't say I wasn't tempted but this time I turned them down flat.

View on HN

I think if I was in your situation and got that type of question I would have said 'id bing it'

Joel Spolsky gave a Google Tech Talk about Stackoverflow. At one point someone asked him about something he said. He had to look it up. He opened up IE and did a search on live.com (pre-bing). It got a good laugh.

Plus, doesn't stacckoverflow run on the microsoft stack?

Yes it is: http://blog.stackoverflow.com/2008/09/what-was-stack-overflo...

First time I've laughed out loud at a Ycombinator comment.. well done.

Perhaps the point was not merely regurgitation of facts but an analysis of your thought-process. It is almost impossible to have such an esoteric bit of trivia but you could have at least given them something:

"...Well I dunno but let's see...Filesystem Z(let's say reiserfs)...so this one's pretty good with really large files...its preferred to other ones(say ext2) for both support of larger files and better disk checking...at the time of distro x, version y, filesystem D(that you may be familiar with) hadn't even come out and was probably an improvement over Z, so I'd wager less bytes per block than filesytem D but more than...."

...or so could be a possible response...I hope I am getting my point through, though of course you're the one to have lived through the day and not me and I'm sure your reply was what you felt best, at the time.

If that's what they were really looking for, then they're really just testing whether you can figure out what they're really looking for, whether they know it or not. If you want someone to demonstrate their thought process, you give them a tricky problem and just tell them to solve it out loud. If it's a good problem, they're not going to be able to fake having an awesome thought process.

"I'd google it" is exactly the right answer, as far as I'm concerned. Unfortunately, it's never the answer interviewers want to hear. Regardless of whether they've asked good questions, it's invariably one of the most common responses interviewees will make when they don't know the answer. Whether or not the interviewer had a justified expectation that you should know the answer, "I'd google it" immediately gets you downranked by association with people who don't know their shit.

I'd agree. I'd rather hire someone who's willing to know what he/she does or doesn't know, and rather than pussy foot around the issue, trying to remember it, google's the answer, fixes the problem and moves on.

This jives with an interview I did with a Google SRE a couple of years ago. He basically took me down a path of increasingly esoteric concepts, until we hit a point at which I couldn't recall the answer off the top of my head. He asked how I'd implement it; once I reasoned through it (and recalled the bit of information I couldn't remember at first), we quickly moved on to another line of discussion.

I assume this was an intentional approach: find an area of knowledge the candidate should understand at a high level, but probably hasn't committed the details of to memory, and see if they can reason it out.

You learn significantly more about someone when they're a bit out of their element; does their confidence evaporate, or do they work through it and come up with a reasonable solution?

You're right actually; I've considered that a few times, but decided against it based on the guy's reaction to my reaction, he wasn't hedging for another answer, it was just "Ah, right."

That particular thought did only occur to me sometime later though so could be it certainly.

That does seem like a strange question but then again I'm not a sysadmin so I really don't know what's reasonable.

I'll frame this in what I know, which is programming. I think it's entirely reasonable to ask someone how a hashtable or even a quick sort (or some other O(n log n) sort) works because programmers should be familiar with that even if 99.9% of the time (if not 100% of the time) you're using a HashMap or std::map or dict or whatever.

But number of inodes does seem somewhat esoteric.

In my view, it's stupid because it implies that if you're the kind of person that bothers to attempt to commit irrelevant or at best situationally relevant things like this to memory as a matter of course, you probably aren't making optimal use of your mental resources.

I found it pretty ironic actually as that's exactly the kind of thing we have search engines for.

On the other hand, if you are constantly working with certain systems, you will know this stuff. If they ask me something esoteric about a language or API that I know really well, I can answer all the tricky questions, or explain how I think it would work. If it is something I use rarely, then I could not.

Anyway, isn't block size standard across all OS?

I think these kinds of specific questions are justified, but only on the basis that (a) it tests that the candidate really does or has worked in this field in depth, and (b) you have a bunch of other similar questions, and knowing the answer to just one or two of them counts as a pass. Basically, it's like throwing spears into an opaque pool, hoping to find evidence of the salmon of knowledge.

Oh, should add, the specific version was not one I had had any experience with, nor claimed to have had any experience with.

I could totally see asking someone that question if they said that they were intimately familiar with some distro or another. Outside of that context, it seems like a really bad question. Maybe there was another purpose to the question (like seeing how you reacted to bad questions), or you just had a shitty interviewer.

FWIW I laughed out loud at "salmon of knowledge". Great analogy.

http://en.wikipedia.org/wiki/Salmon_of_Wisdom for those unfamiliar.

Just checked the mkfs.ext4 man page and no, that doesn't seem to be the case. This was about five years ago so the precise question I can't perfectly remember, but the nature of it was as stated; It was a question about a specific filesystem setting default value, on a specific version of a specific distribution of linux, inode size, bytes per inode or bytes per block.

Apologies for sounding a little addled but it's been five years since I have been a systems administrator so it's all melted together in my memory.

From the mkfs.ext3 man page:

-b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem (see the -T option).

I remember that Red Hat and Fedora used 1024 on my computer.

As for the distribution specific thing, maybe some distribution had their own version of /etc/mke2fs.conf (settings for mkfs, including block size).

Default block size for ext2/3 is 1K for common root filesystems size.

Perhaps a more "sysadmin-ish" answer would have been something more like "Whatever the command 'echo 1 > /tmp/one && du -h /tmp/one && rm /tmp/one' prints".

That doesn't exactly work.

echo "a" > a; du -sh a; rm a

2.0K a

dumpe2fs /dev/sda1 | grep -i 'Block size'

Block size: 1024

Interesting. Still, I'm no sysadmin; the point is that demonstrating you know how to find something out short of google is better than... well, not.

I'm curious how you got that. Are you sure "a" is on /dev/sda1? What OS and FS are you using?

$ du -sh /tmp/a

4.0K a

$ tune2fs -l /dev/mapper/VolGroup00-LogVol00 | grep "Block size"

Block size: 4096

Positive that 'a' is on /dev/sda1. Running CentOS 5.5 and /dev/sda1 is ext3.

I get similar behavior on the other partition:

echo "a" > a; du -sh a

8.0K a

dumpe2fs /dev/VolGroup00/LogVol00 | grep "Block size"

Block size: 4096

Though if I 'touch' the files to create them, they are the blocksize. Which seems odd, since on my AIX and HP-UX boxes that gives files of size 0.

This sounds like a question used judge character. I'm not sure it makes sense to be doing such a thing at google, but sometimes these kinds of things are asked more to judge your reaction rather than your answer. I'm sure you replied confidently, but others may get flustered, which could be a sign of how they act under pressure.

And of course there are those who would answer take a best guess stab rather than appear to not know the answer which would be undesirable as well.

I'd say I know it's greater or equal to 512 (depending how far back the date of the interview).

Typically if you get that one right, there is a serious of follow up questions each getting deeper and deeper into the understanding of the same topic.

That seems to assume that the deeper understanding necessitates the trivia. One can understand how a filesystem works without knowing the default block size.

Reply on news.ycombinator.com