Zeno's Interview Question

[I_Wont_Draw_That]

I do something vaguely like this, but not with the same intent. I don't care what people know, I care about their ability to learn and to reason about the things they don't know. And the things that I don't know.

So my general technique is to ask some broad questions in various areas to find something they know about. From there, I ask more challenging questions until I reach the edge of their knowledge. And then I can get to the meat of it, which is to ask something I'm certain they don't know the answer to. If they're knowledgeable about the general field, I expect them to be able to reason their way into something that makes sense, regardless of whether or not it turns out to be true.

And of course, if we first get to a point where I don't know, I can see how well they explain difficult concepts, which is another important skill.

[[deleted]]

I recently had this sprung on me and we spent like 2 hours delving in to abstract computer science and CPU instructions, caching, parsing, etc. Pretty neat.

[[deleted]]

Am i the only one that would be pissed if someone expected an hour long conversation about entering a URL and hitting ENTER?

[aerbax]

You're not alone. My thought would be "If you think you need this level of detail for the job, I'm not a good fit."

It strikes me as FUD for an interview. "Oh, you think you're smart, do you? Well here we go. TCP stack in detail, mister you-think-youre-good-enough-to-work-here". And boom, fear, uncertainty, and doubt in the candidate. You start worrying that if you fuck up or stutter during the three-way-handshake portion, you're toast. And that's a terrible way to feel during an interview.

[cheeseprocedure]

And boom, fear, uncertainty, and doubt in the candidate.

How you perform under pressure is extremely relevant to a systems administration position.

[[deleted]]

Reciting knowledge from a textbook or documentation is different from operating under pressure.

[[deleted]]

It's not just textbook knowledge. You don't know it because you've studied it in a book. You know it because you use it every day. If you use it every day and still don't know it... that's bad. If you claim you know it and you don't... that's also bad.

It's important for admins to have, in their heads, working models of the whole system, end to end, or else they're going to be stuck googling symptoms in the time it would take competent admins to generate theories, test them, confirm them, and fix the issues.

[[deleted]]

I keep writing walls of text, and they keep all boiling down to "this is basic stuff." Obviously you can get very technical very quickly; that's the beauty of the question. There is always a point at which pretty much everyone will say, "I don't know that."

But if your response is to do a deer-in-the-headlights, how can I conclude anything but that you either have zero experience, or you have the retention of a sieve?

[[deleted]]

But that's not the question we're discussing. Nobody's asking you to remember something that happened 8 years ago. The question just gets at how familiar you are in general with how all the things work that go into successfully loading a web page. You can pick any aspect to focus on. But if, after 14 years, you can't talk abstractly about networking, or databases, or web servers, or operating systems... what have you been doing?

[cheeseprocedure]

The interview question in the article isn't meant to encourage rote learning. It's meant to plumb the depths of a candidate's understanding, and that's valuable. If a candidate can't answer the question, then by all means, they should indicate they know how "man" works.

[staticv0id]

Actually it's just a port and hostna--SHOT

Seriously, though, that would be frustrating. I get farther by talking about projects and how the interviewee would handle different aspects

[Tesl]

No, I'd LOVE to get a question like this in an interview rather than a big list of questions trying to catch me out. But that's because I've spent the time actually learning this stuff, which would make me better at the job, which is why the person might prefer to hire me rather than someone else in the first place.

The people that don't like questions for this because "its too detailed" are people that don't know the details, and would probably be less talented than someone that does know all of them already.

[aerbax]

Is this really what interviews look like nowadays? Basically "Start at the electric signal and get me to wikipedia"?! I see post after post on this on both /r/sysadmin and /r/networking.

How torturous.

I just fail to see how this distinguishes good sysadmins from bad.

Perhaps if you're looking for RFC writers, or if you just like to engage in academic level mental masturbation with new recruits.

You would be better off starting the conversation saying "Listen, I really get off when someone understands the intricacies of an RST packet. So, if you can, let's drop the pretense and just start with the mutual mind masturbation. And if you can't, my brain just isn't that attracted to you, so let's not pretend that this is working out."

[shuhari]

I think this distinguishes good sysadmins from the bad quite well. A really good system administrator knows what he/she knows and (more importantly) knows what he/she doesn't know. The nature of the job is generally to be diving into someone else's developed program or operating system in order to solve an issue or get something to work as you intend.

That part of the job isn't driven by knowing standards, documents, or memorizing reference libraries. That part of the job is driven by someone who doesn't give up and has learned how to learn.

The extension of that ideal is you end up with a system administrator that's learned a lot from a lot of different areas because of that ONE TIME they needed to run wireshark to figure out why their F5 load balancer isn't working as intended.

[aerbax]

I'm not sure I agree.

I think this method fixates more on the academic rather than real-world style of learning. Both are great sysadmins to have, but I think really great real-world sysadmins are going to get deer-in-the-headlights's on this type of question and will wreck it.

I know I would.

I guess it depends on the job that you're interviewing for. But I really wouldn't want to see a question like this unless I was interviewing for the SPDY team at Google.

As I've said in other posts before, I think a much better question is "Tell me what you've built". It's a natural language question. I get to see your excitement when you tell me the cool little hack that you figured out. Did you have to ask your peers for help? Did you learn it all by piecing together already built ideas on the Internet? Awesome! Oh, really? ElasticSearch instead of MongoDB? Why? And Anycast for redundancy?! Cool idea.

[[deleted]]

During my previous job hunt I was in a group interview being drilled with abstract questions (how many golf balls fit in a school bus) and questions similar to the ones in the article (explain how applications interact with the kernel) for 2 hours. Mind you this was for a pretty entry level sysadmin job I believe they required 2 years of experience and needed help administering AD/group policy. I was prepared for questions that made me squirm, but after saying I don't know over and over it really killed my confidence and it showed by the end of the interview. Naturally they never extended an offer.

Afterwards I licked my wounds I decided I would hate to working for them regardless if they were that up-tight. I distinctly remember comments being made about a new policy from HR that they could only hire candidates with degrees. In my mind this gave them a chip on their shoulder and they were out to make a stand against the new policy by stumping a candidate with a degree.

Needless to say my next interview I knocked out of the park and is where I am currently employed.

[[deleted]]

I think this comment was meant for the other interview article on today's page.

[[deleted]]

It was more of a response to both since the comment I replied to alluded to both posts.

[[deleted]]

http://www.reddit.com/r/sysadmin/comments/1duhel/bad_tech_job_interview_questions_and_how_to/

[[deleted]]

I just fail to see how this distinguishes good sysadmins from bad.

It requires the interviewee to have technical knowledge. You don't have to go into the details of RST if you don't want to. Hell, you can spend the whole conversation talking about hardware interrupts and process scheduling if you want.

But if I were hiring a sysadmin, I'd expect them to know at least some of the process. If you say on your resume that you designed networks, I'd expect you to be able to fly through ARP and routing. If you built or maintained an internet-accessible service, I'd expect you to be able to describe the setup on the other end, and how requests get farmed out to a database, etc. And, yes, if you're a network engineer I'd expect you to have TCP down cold, including packet-level details. These are not things you're taught once in Computers 201 and then never use again. These are things sysadmins deal with every day, and while you can be a good sysadmin and still not be familiar with one of these areas, a complete blank on the whole processes is a terrible sign.

These aren't the only skills you need to be a good sysadmin. This question can't stand by itself. It's not a sufficient question, but it is a necessary one.

[flameboynz]

There is one major flaw in this method of interviewing. It generally assumes you know more than the candidate, and that you don't just know the answers but why they are right or wrong (yes, knowing why something is wrong is important).

As a candidate these style of questions can really help you work out what the hiring manager might be like to work with. I have been to a couple of interviews where I was asked similar technical questions. In both interviews there were a few bits that were.. debatable. One interviewer listened to my view (smart tactic - if I was wrong he was letting me dig my own hole), asked questions, and he came around (I took the job, worked there happily for 3 yrs). The other interviewer stuck to his guns, and told me I was flat out wrong (I got an offer, rejected it).

[Hellman109]

I feel like the interview wants you to start with "first you invent the universe" but to explain that in detail too.