This post would be so much more useful if it had a list of the questions asked, what the wrong answers given were, and an explanation of why the answers were wrong, along with links to the information needed to come up with the right answer.
I dislike interview questions that sound like they were pulled from some industry certification test. What's the point in asking people questions that test their memory?
Today the fact is that we DO have Google and other tools at our fingertips. If it means that we have fewer definitions and facts committed to memory, so be it. It's not a bad thing to look up information on an as-needed basis. The information will be fresher and likely accompanied by recent developments. Even doctors do this when they're about to perform an operation they haven't done in a while.... they'll look up the procedure beforehand and refresh their memory to ensure that they follow the current standard of care.
Interview questions should focus on exposing problem-solving ability and getting to know the person to determine whether he/she is a good fit for your existing team.
Honestly, from the sound of it you just hadn't been paying attention over the years as you were learning all of the commands, it seems like Google is your go to tool of choice.
I've been there, and I had to stop myself. The fastest way to learn something is the hard way using the man pages, as looking up the same argument to a program over and over is going to get it stuck in your head much faster than anything else. At least for me, I will qualify the previous statement with that.
I too have written countless of scripts to do meaningless tasks, it is one of the reasons why I became a computer programmer, I'd rather spend 2 hours writing a script that works in all corner and edge cases and never have to do the same menial task again than spend the 30 minutes it would normally take to just finish the problem (knowing that it would most likely come up again, and it would once again take me 30 minutes ...).
The thing is that certain things should start to sink in even while using scripts. I have scripts to set up an entire FreeBSD system in under 30 minutes with custom software deployed, configured and running, but if it ever doesn't work right I know exactly how to fix it because I know all of the steps in that script.
--
It comes down to some rote memorisation and the rest becomes ingrained to the point that you can yell the commands across a cubicle to your colleague. I recently learned git inside and out, and now have no problem while standing next to a co-worker dictating exactly what they need to type to get it to do what needs to be done. I'm the same way with FreeBSD system administration (Linux not so much, but I can find my way around an Debian and Ubuntu box).
I started playing with Linux and FreeBSD when FreeBSD 4.6.2 was released (I ran an open email relay on my home cable box at age 13 (I am now 22), by mistake). Some of the things you have mentioned in your blog post are some of the simplest concepts of Linux.
I've definitely been in that awesome "hopelessly incapable of answering an 'easy' interview question" situation before. The worst time was when I was interviewing with RethinkDB, and one of their guys asked me a dynamic programming question. Did I know that dynamic programming was fair game for any technical interview? Absolutely. Did I prepare for it at all? Nope (which is not to claim that I would have aced it with some amount of preparation -- I just know I couldn't have done worse).
I remember thinking as I was leaving "Well it was cool of them to buy me lunch, and the weather's nice." Later that evening my doubts in my interviewing prowess were confirmed :)
Actually, I was impressed how the OP handle his setback and how he took it as a learning experience.
== Below was a supposedly reply of mine to the top commenter in Reddit, but keep getting an 504 error message ==
Not to disagree with you here since this seems to be the sentiment here, but the questions (ie. boot process/signals) he was asked was broad and would have shown if the candidate have a solid grasp of Linux fundamentals.
Hypothetical situation, say he applied for sysad job in big Linux shop like Google. Describing the boot process would have given the interviewer an idea how well he would recover from a system crashed using a rescue disk. Understanding signals are important for making non-trivial Bash scripts. And describing a symmetric/asymmetric encryption is crucial if one of you job responsibilities is to administer certificates.
Not saying the questions are easy, they're not. But if you're applying for something like a Linux sysadmin job, then these questions are good indicator how strong your skills are in this area.
You've been a cloud admin for over five years and working with Linux for over 20, but you don't know the difference between symmetric and asymmetric encryption?
I'm as arrogant as the worst of them, but this sounds borderline ridiculous.
That said, I'm looking forward to see how you're looking to change this.
What exactly would require a Linux sysadmin to be able to articulate the differences between symmetric and asymmetric encryption? Some probably could, but I'd guess most couldn't give you more than a basic one liner.
As long as they have a basic understanding of how SSH, GnuPG, and SSL function and a thorough understanding of how to use them that's probably the extent of the cryptographic expertise required.
Just because it's not required to do the job doesn't mean a curious sysadmin shouldn't know the difference. The difference between symmetric and asymmetric encryption is a pretty basic part of cryptography and if you read about cryptography at all you should know it. I think it shows a lack of interest to not know more than the minimum required to do your job.
Well maybe they were more curious about filesystems and wrote their own? Or they know all about event-based programming but you didn't ask about that because you don't know anything about it?
I think it's wise to avoid "grading" on specific technical questions about things that aren't actually required for the position.
That doesn't mean you shouldn't look for bonus knowledge, but I don't think it's good to be too specific about what it is.
Well, I asked the interviewer if by asymmetric he meant something like PKI, and all I got was a frown. And I was like symmetric encryption is just normal. I think I was more caught off guard, as well as just not thinking much about it. I got all the PAM questions right if that helps. Probably doesn't. I feel genuinely humiliated by the whole situation.
Seriously in the back of my head I heard my Father's voice: "You done fucked up good, boy"
The difference is rather simple. (Although I have a feeling that tpatcek will tell me I am wrong on some count)
Asymmetric encryption has two parts, a private key and a public key. One encrypts data with a public key and then the only key that can decrypt it is the private key. The private key, as the name suggests, has to stay private and is a secret, whereas your public key you can hand out as you please.
In symmetric encryption you have a single key, it is used to both encrypt and decrypt the data, and thus if that single key were to fall into the wrong hands that person could then decrypt the data, whereas with a public key that is not the case.
This is a very simplified overview of the differences.
It sounds more like the role was for a senior admin or architect rather than a line admin. I wouldn't beat yourself up too much about it... unless you thought you were a senior admin. Those guys do have to know and understand the nooks and crannies as well as the general processes.
It'd be hard to have worked with Linux for over 20 years at this point since the first public Linux release happened just under 20 years ago (September 1991).
And even in the post, there are more factual errors... Ctrl+D doesn't ask a program to quit. How can you use Linux for 10+ years and not know why kill -9 is "force" and what the difference is from normal kill?
I said a very amateur enthusiast since 1999, which is closer to 10 years. And the Ctrl-D is what I said in my interview I apologize if it is not factual. Looking it up it appears to be end of file, is this correct, I will change my post to reflect this if so.
Yes, Ctrl + D sends an EOF to a program getting input from the console, this can be used to notify mail(1) that you are done typing your message and that it should send the message now.
If he understands how PKI works. If he understands that people share a public key which is in turn paired with a private key. And if he understands that said private key is the only key capable of decrypting messages that were encrypted using the public key, that should be fine.
If he knew that much, he'd probably be able to reason out what 'symmetric' vs 'asymmetric' meant, if given enough time.
Is knowing the exact terms better? Yes.
Is it shameful to understand the concept pretty well without knowing every bit of terminology used to describe it? I'd say no.
Don't feel too bad about it. Many of those questions are arcane/trivia rather than practical day to day knowledge you must know. Don't get me wrong, it's important to understand concepts (like the encryption question they asked), but knowing off the top of your head how to rm a file named "-f" is not important, but knowing how to figure out how to unlink it is.
I believe Ctrl+D should send end-of-file to console applications, ending the input stream to the program from the shell, while Ctrl+C kills the application.
