Hacker News Reader

Comment by tapatio | Hacker News Reader

Imagine that as an interview question!

Yep, the best interview questions are ones you yourself would fail before 2017.09.15 but would pass after 2017.09.15 based on having read a HN article.

This interview question is great for three reasons:

1. It identifies that someone is you.

2. It separates the bad-coder you (before 2017.09.15) from the good-coder you (after 2017.09.15). This means that it is immune from generating a false positive on a poor candidate due to time travel.

3. It identifies cultural fit: the person reads the same news articles you do. If you waste time reading random hacker news articles, you're going to want to hire people who do the same. Especially ones who were around and not too busy on exactly 2017.09.15! It easily weeds out people who were on vacation on that date, for example.

What I especially like about this is that it has nothing to do with anyone's code. (After all, anyone who works at a level that low can answer it very easily without having read this stack overflow question, so it's a strictly orthogonal puzzle: it's only hard for people who don't need it!)

You should go ahead and add this to your list of interview questions! In fact, why not make it the only one?

(It also avoids the fuss of having to come up with questions in any way related to the work that a candidate will be doing, which, in case the above sarcastic comment wasn't clear, is what you should actually be doing.)

Sarcasms are like lies: the more you talk, the more you dig your own grave.

I really, really (really) want to get people to stop asking these types of interview questions. I want them to realize how awful it is. (I've enumerated the ways.)

This type of interview question simply needs to die. An interview question shouldn't be about whether you've seen something that is unrelated to the job. Which is what this is.

(For jobs where it is actually something they need to know, it is a poor question because it's too simple.)

I should add that I personally found the stack overflow question itself and its answers (especially about the Intel compiler) very interesting.

OK, we get your point. But consider that there are jobs where this stuff is actually important, and it's useful to have working knowledge. If you were actually going to ask this in an interview, you would obviously want to ask something different but along the same lines, just in case the candidate was familiar with this post. But that goes for many interview questions.

For the jobs where this is actually important, this isn't a good interview question - it's not subtle/deep enough. (There are many deeper questions for those jobs - this one is a basic intro level question for a job such as that one.) The reason I enumerated so many ways this is wrong isn't to be funnier: it's because I really want people to stop doing this.

I actually think this would be a very good interview question for someone who would be working on performance critical C++ software (maybe not for an entry-level position though), branch-prediction is something that anyone working in that domain should understand at least the basics of and it could quite easily open up the conversation to other hardware or optimisation topics.

You learn branch prediction in most CS, CE or EE programs.

What kind of class would include that in their curriculum?

It's usually a topic on the first computer architecture class. It's a mid-of-the-book topic on most computer organization books, the classics like Hennesy Patterson or Tanenbaum have substancial portions dedicated to it. Both are books for a first course on computer architecture and design.

It's very important to understand it so that you can understand why sometimes pipelining is difficult or impossible.

Pipelining is done on basically every processor . It is like the laundry example you are not going to wait for dryer to finish before you load the washer. As soon as the clothes are done in the washer you will move them to the dryer and load the washer.

Yeah if you have branch prediction you can suddenly realize you put dirty clothes in the drier together with clean ones.

We learned about in Computer Architecture (EECS 314).

We used the textbook "Computer Organization and Design" by David A Patterson and John L Hennessy. Branch Prediction comes up on page 341. I have it sitting on my desk here at work because it's such a useful book.

Our school introduced it in a year 2 computer organization course that was required for all CS majors. It went into how the processor converts assembly into instructions for the ALU, instruction pipelining, branch prediction (though only qualitatively), and the instruction and data cache, amongst other things.

Really, I was going to say this is a good weed-out question for an entry-level position. Topics like pipelining, branch prediction and cache locality were covered in 2nd year computer architecture classes when I went to undergrad. Aren't they teaching this stuff anymore?

Yeah but if you don't use that knowledge for 10 years, you forget it. You wouldn't ask a web developer for the dates of the French Revolution in order to prove that they graduated high school.

I'm not sure what kind of developer works for 10 years and doesn't use knowledge of how microprocessors work. Is their code being executed by something other than a microprocessor?

On the other hand, maybe this is why my E-mail client has a 300MB memory footprint and my browser pegs the CPU when simply opening a web page.

> On the other hand, maybe this is why my E-mail client has a 300MB memory footprint and my browser pegs the CPU when simply opening a web page.

It sounds a lot more like you don't fully understand what the causes behind these things are and you're ready to arrogantly blame it on developers who dare use javascript without microoptimizing everything.

Your email client has a 300MB memory footprint most likely because of its dependencies and the appropriate amount of work invested into it. If it's a commercial product, the company probably doesn't care enough to spend decades optimizing every single layer of the stack down to the compiled assembly just to sell you something for twenty bucks. If it's an open source product, the devs behind it definitely don't have time to do that but OTOH you're welcome to apply your superior knowledge and show everyone how it's done.

I'm not sure what kind of developer works for 10 years and doesn't use knowledge of the chemical properties of silicon. Is their code being executed by something other than silicon?

> Aren't they teaching this stuff anymore?

They quite possibly are, but I didn't do a CS degree so I wasn't sure whether it was a standard thing to learn or not (hence "maybe" rather than "definitely").

> Aren't they teaching this stuff anymore?

You're describing a good question for an end-of-year test. Not an interview question for "entry level positions", most of which don't require or use any academic CS knowledge.

At my university it was the same, but this (second) class has become an optional elective that is cross-listed with the Computer Engineering major and no longer required. So, most CS majors no longer take it. The curriculum has "drifted" somewhat I'd say, to be a bit higher level, and perhaps more useful to people who go on to be developers at the application level.

In my school, we were taught about them, sure, but not in great detail. We certainly weren't taught how to detect code that has bad branch prediction behavior or how to write code that prevents branch mispredictions. I don't think we even covered cache locality.

I disagree on the original SO question as being a good weed-out question for an entry level position. This is a code optimization that I certainly wouldn't expect a newbie to know.

It would be an easy one, if applying for any speed/latency critical job (C/Java).

There are a lot harder micro-benchmarks related to L2 cache size, page faults, compiler optimizations (esp. JVM), pointer deference/indirections and so on.

I can perfectly imagine it as it may give an indication on whether your interest is in the field or not. If you know the answer, chances are you read HN or follow other communities as opposed to not giving a damn.

Not so great. Either you get it or you don't, and it's easily learned. Missing it just means you have more to learn.

If you are looking for someone to work on performance-critical code, you would probably prefer someone who has already learned this.

Apart from being useful knowledge for the job, it's a good indicator, showing if the person has worked on such problems before (or alternatively has good knowledge to tackle such problems)

Yes, I'd prefer them but only slightly.

If they don't know it, they're not an expert. But did they claim to be, and how quickly could they learn?

If they do know it, it doesn't mean they're an expert either. It's easy to learn these things just by happening to read about them.

What are you trying to say?

Reply on news.ycombinator.com