

I'm a linux noob, that thought he knew something, got destroyed in an interview. - bsdpunk
http://bsdpunk.blogspot.com/2011/03/linux-job-interview-from-hell.html

======
X-Istence
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.

------
slashclee
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.

~~~
bsdpunk
I tried to put as many of them up here:
[http://bsdpunk.blogspot.com/2011/03/questions-and-
aftermath....](http://bsdpunk.blogspot.com/2011/03/questions-and-
aftermath.html)

~~~
calloc
Here is some trivia for you, seeing as how your blog name is bsdpunk:

"shutdown -r" on FreeBSD runs the rc.shutdown script{s}, whereas "reboot" does
not.

See this thread:

[http://lists.freebsd.org/pipermail/freebsd-
stable/2010-Decem...](http://lists.freebsd.org/pipermail/freebsd-
stable/2010-December/060537.html)

------
delineal
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.

~~~
th0ma5
Wanted to come here and say this! It seems to me a lot of this is to inflate
the ego of the interviewer almost.

------
alexgartrell
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 :)

Still, awesome guys, hard problems, I encourage you to apply :)
<http://rethinkdb.com/jobs/>

------
mfukar
Start by 'man kill', dude. And let go of the damn attitude - even your 'I was
crushed' post is full of it.

------
hacker-gene
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.

------
Animus7
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.

~~~
bsdpunk
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"

EDIT FOR FATHER QUOTE

~~~
X-Istence
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.

------
asymptotic
"In my walks, every man I meet is my superior in some way, and in that I learn
from him." --Ralph Waldo Emerson

Humility my man, humility. Everyone's eaten humble pie before; if you don't
eat it on a semi-regular basis you're not pushing yourself hard enough.

------
16s
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.

~~~
ciupicri
You have to run _rm -- -f_ or you can always cheat and use _mc_ (Midnight
Commander).

------
bsdpunk
Guys I put the questions and my dealing with the situation up here:
[http://bsdpunk.blogspot.com/2011/03/questions-and-
aftermath....](http://bsdpunk.blogspot.com/2011/03/questions-and-
aftermath.html)

If you want to check it out

------
IvarTJ
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.

~~~
personalcompute
You're correct. Specifically, Ctrl+d sends EOF, and Ctrl+C sends a signal,
SIGINT.

~~~
X-Istence
And what does a Ctrl + Z send? ;-)

~~~
tedreed
<http://en.wikipedia.org/wiki/SIGTSTP>

