←back to thread

1764 points fatihky | 2 comments | | HN request time: 0.442s | source
Show context
lordnacho ◴[] No.12701486[source]
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing.

It's a bit strange to have someone non-technical interviewing a techie. You end up with stupid discussions like the one about Quicksort. If you point out qs is one of several things with the same big-O, you'll probably also get it "wrong". But the real problem is that a guy who is just reading off a sheet can't give any form of nuanced feedback. Was the guy blagging the sort algo question? Did he know if in detail? Does he know what the current state of research on that area is? There's no way to know that if your guy is just a recruiter, but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad.

I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.

replies(34): >>12701588 #>>12701606 #>>12701620 #>>12701625 #>>12701648 #>>12701659 #>>12701722 #>>12701725 #>>12701748 #>>12701796 #>>12701805 #>>12701854 #>>12701894 #>>12702003 #>>12702005 #>>12702106 #>>12702118 #>>12702186 #>>12702310 #>>12702312 #>>12702327 #>>12702439 #>>12702478 #>>12702496 #>>12702544 #>>12702566 #>>12702572 #>>12702655 #>>12702699 #>>12702757 #>>12702829 #>>12703332 #>>12706141 #>>12708605 #
tptacek ◴[] No.12701606[source]
I knew all these answers too, because I was a developer in the 1990s.

There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part of being a practicing programmer; knowing how to find out is.

replies(9): >>12701685 #>>12701692 #>>12701960 #>>12702093 #>>12702100 #>>12702332 #>>12702334 #>>12702435 #>>12702610 #
rayiner ◴[] No.12702435[source]
I don't think these questions are unreasonable as a spam filter. Yeah, they're trivia, but if you had actually worked in that space, I'd be surprised if you didn't know a lot of that trivia just by virtue of exposure.

The rejoinder, of course, is that it's probably misguided to structure your recruiting around a spam filter.

replies(1): >>12702443 #
tptacek ◴[] No.12702443[source]
The length of an ethernet address is a trivia question. It's a good way to score a board game. Filtering out candidates based on it is lunacy.
replies(1): >>12702546 #
rayiner ◴[] No.12702546[source]
I agree with the first and second sentence. As to the third: what would be your thought process as to someone who claimed to be a network programmer on the phone but couldn't answer most of those questions?
replies(3): >>12703003 #>>12703536 #>>12704492 #
tptacek ◴[] No.12704492[source]
I think you can probably predict it: I would generate a work-sample test for it. For a network programmer, I might have them implement a 3WH coded directly to pcap_write() (which requires you to populate the Ethernet frame header). Like the best work-sample challenges, doing a raw 3WH is kind of fun if you haven't done it before.

My friends and I used to spend bar nights drinking over torturous interview questions (yes, I have always been this nerdy). For instance: we had a gruesome sequence of questions on how to implement the fastest possible traceroute that you could only clear if you knew about a trick using the IP timestamp option.

Later, I got (what I thought was) smarter about interviewing, and moved to more surgical questions. I'd ask candidates to debug a C program that segfaulted in malloc, or ask them to describe the utility functions they carried with them from project to project.

After taking over recruiting for a company that really needed to hire at a specific clip in order to balance sales and delivery, I'm embarrassed that I thought I was interviewing effectively with stuff like this.

You can't learn about someone's capabilities by putting them on the spot with trivia questions.

replies(3): >>12704800 #>>12706853 #>>12709788 #
delroth ◴[] No.12706853[source]
> You can't learn about someone's capabilities by putting them on the spot with trivia questions.

But that's not the point of these questions. These questions are a 5-10min phone pre-screen before getting to the actual interviews. They test if the candidate has experience in a given field, not if they can search for information or what are the precise bounds of their capabilities.

It's trivia, but it's trivia that is a reasonably high confidence proxy for experience in e.g. network programming/design (resp. other fields). If someone claims they have networking experience and don't know SYN/SYN-ACK/ACK it's in my opinion a large red flag.

replies(1): >>12708753 #
1. tptacek ◴[] No.12708753[source]
These screens pass people who can answer trivia but who can't effectively code, and they reject people who have a gift for solving engineering problems with code but who can't answer trivia questions when put on the spot.

The ostensible reason they get deployed (I say "ostensible" because we all know that in reality the on-site interview consists of the same stupid kinds of questions) is to keep the employer from wasting time conducting more sophisticated interviews for candidates who have no hope of passing. But that's dumb for at least two big reasons:

* The filters obviously reject candidates who would do well on more serious challenges --- worse, they do it insidiously, because you can't tell that they're rejecting good people, only that you're seeing fewer bozos, which makes them look like they work. In reality, a new norm has arisen where the most qualified candidates get to skip these processes entirely, because we all know they're a crap-shoot and don't want to lose good people.

* Properly administered work sample challenges actually take less employer time than these stupid trivia screens do. That means there's literally no purpose to the trivia screens whatsoever; they do nothing but harm.

In my last comment, I just wrote off the top of my head a sketch for a work sample test that addresses the same concern as the dumb TCP/IP trivia quiz from the original post. It took me I think something like 30 seconds to come up with it. Think about how you'd score that (remember: the bar here is "must be more predictive than that dumb trivia question"). I'm thinking something along the lines of "run the code and see if it opens a new TCP connection".

Assuming your team has enough sophistication to build work sample challenges like this, try to justify the trivia interviews. I think you can't.

replies(1): >>12712948 #
2. Klockan ◴[] No.12712948[source]
> These screens pass people who can answer trivia but who can't effectively code, and they reject people who have a gift for solving engineering problems with code but who can't answer trivia questions when put on the spot.

SRE's are hired to fix outages and other problems asap, knowing trivia is very important then since at that point you might be losing a million dollars per second.