Live data from Hacker News

My Favorite Engineering Interview Question

skife.org

111–120 of 131 posts

Re: My Favorite Engineering Interview Question

#111
post #75

I'm confused... why specify a 1 TB disk ? It doesn't seem that the problem's solution has any dependence on the aforementioned disk aside from the data it contains unless I'm misreading how he's explaining the answer?

yep, that totally threw me too. It kinda implies that you're going to be handed a physical disk with some sort of k/v store in it and you need to write some software to access it. I immediately started thinking about seek times and elevator algorithms and that kind of stuff, which really threw me off course.

I immediately started thinking about seek times and elevator algorithms and that kind of stuff, which really threw me off course.

Not necessarily off-course. If you have 32 GB of RAM and you don't mind an average latency of 10000000 ms, a single 1 TB disk works just fine,

Re: My Favorite Engineering Interview Question

#112
post #97
post #46

These types of questions are terrible interviewing techniques. An interviewer who, even jokingly, goes into the room with an interrogative mindset is fundamentally failing at the core purpose of interviewing: finding good talent, preferably relatively undervalued talent. An interviewer should not be looking for someone who mirrors their way of thinking or or their approach to solving a problem. They should be looking…

I appreciate the feedback, but don't think I fall into, nor describe in the linked blog post, the interviewer category you describe (though it is certainly possible I do and just don't realize it). Do you consider this question to be unanswerable? As I stated, I'll accept pretty much any viable answer, my goal is to get folk to design something ~realistic (okay, this is a simplistic system, but we have finite time in…

Part of what's problematic about this interviewing approach is that while your (secret) internal mindset may be "I'll accept pretty much any viable answer", the full-court-press interviewing style effects the exact opposite impression on the candidate -- they're left thinking, "gosh, I have to get this right, dammit, no room for slack, can't leave out any details AT ALL or it's back to another month of ramen and job boards trolling."

So yes, with your interviewing technique (orthogonal to the technical content of the question itself) you've succeeded in conveying a stance and mindset that is quite literally the opposite of what you intended.

Re: My Favorite Engineering Interview Question

#113

Earlier quoted context omitted.

I would say that having "interrogation techniques" crossed out is a pretty good indication that the author's state of mind in an interview situation is aggressive and domineering.

I would say it's obviously a joke. Do you always assume the worst of people?

Maybe he thought he was making a joke, but the point is that it comes off "Ha, ha, only serious":

  http://sunsite.ualberta.ca/jargon/html/H/ha-ha-only-serious.html

Re: My Favorite Engineering Interview Question

#114

This guy is taking a lot of heat for bad interviewing technique, and this may or may not be the case - but it's hard to say, given that we don't know what kind of a position he's interviewing for. Given the job requirements of the position, this may be a perfectly reasonable question - i.e. if the job requires someone to build and maintain large custom data stores, it's pretty acceptable practice to ask questions tha…

> In the types of questions this guy is asking, you have to basically guess what they're looking for

Don't guess, ask. Having asked questions like this before, I can assure you that a reasonable interviewer will actually be pleased that you understand the alternatives.

(And, of course, if you get an unreasonable interviewer, you probably don't want to work there anyway.)

Re: My Favorite Engineering Interview Question

#115
post #78
post #54

Expecting a good answer to this question in 30 minutes without any warning is totally unreasonable. Expecting anyone to implement a deployable, generalizable, tested solution to this in two weeks is totally ridiculous. I wouldn't work at a place that asked questions like this or made development calendars with schedules like that.

I did this in three weeks: http://bitbucket.org/rogueops/vinzclortho/wiki/Home I worked on it on average two hours per day. It's not that ridiculous to believe that it would be (near) production quality in two weeks of fulltime work.

It's not hard to get "near production quality". It is hard to get to production quality.

Re: My Favorite Engineering Interview Question

#116

Earlier quoted context omitted.

I would say it's obviously a joke. Do you always assume the worst of people?

Maybe he thought he was making a joke, but the point is that it comes off "Ha, ha, only serious": http://sunsite.ualberta.ca/jargon/html/H/ha-ha-only-serious.html

It does at first, but upon reading the entire essay I was convinced his intentions are honest.

Re: My Favorite Engineering Interview Question

#117
post #5

Advice for new questions: instead of contrived ones, pick a problem you've actually encountered in your job and ask the candidate to solve it. I've never had to implement a datastore like this -- so unless that's what you're actually doing, it doesn't seem particularly relevant. Another plus is that if you're doing interesting work, you have an almost endless supply of questions to choose from. Candidates also seem t…

Upvoted. Just for once, I'd like for an interviewer to present a question that they themselves don't know how to solve (or didn't know how to solve in the first few times they thought about it).

Re: My Favorite Engineering Interview Question

#118

Earlier quoted context omitted.

Asking relevant questions at an interview is a good idea, but I've noticed that a lot of technical interviewers ask questions it took them weeks to understand and fix when they use this approach. Understanding a problem is often more difficult than solving it ... knowing that the interviewer understands the problem and constraints is even more of a challenge. I once had an interviewer give me the kobayashi maru witho…

Can you describe your kobayashi maru question? I'm curious.

You can look up the Star Trek reference, but in an interviewing context, it refers to an question that is essentially impossible to answer and/or basically never occurs in real life and yet is somehow meant to judge a candidate's ability to "think outside the box" or under extreme pressure.

As well as, of course, to showcase the interviewer's vast wealth of experience and keen insight into the human condition that enables him/her to assess as much in 5 minutes from candidate's response to a completely contrived question.

Re: My Favorite Engineering Interview Question

#119
post #7

I'm interested in why he's so against the "custom solution". Almost everything a DB will try and add in for key-value lookup is predicated on the idea that the requests aren't randomly distributed. The DB index will probably be based around b-trees, which will do a logarithmic-time search for the top few levels cached in RAM, but will fall over fairly miserably with multiple seeks as it has to page in leaf nodes and…

Were I asked this, my general approach would be: (1) Given the available building blocks (disks, ram, cpus, etc) what strategies are workable? An example of a strategy would be "store it in a btree and keep all but the last two levels in ram; therefore we'll need enough ram for the top of the tree and 2x seeks for each lookup." (2) Find existing software that implements a workable strategy if at all possible, or at l…

Or, they simply didn't have failover in place at all.

Re: My Favorite Engineering Interview Question

#120

Earlier quoted context omitted.

I don't understand your objection here. The question presented is a simple, open-ended question with a number of acceptable solutions. It's not even remotely "unanswerable". It's at least mildly interesting as indicated by the number of responses at a similar question on StackOverflow: http://stackoverflow.com/questions/2573653/given-a-1tb-data-... . It's not far from the problems Ning solves. It's not an "aha" probl…

I would say that having "interrogation techniques" crossed out is a pretty good indication that the author's state of mind in an interview situation is aggressive and domineering.

What is the meaning, in an essay, of a cross-out word?

Generally, I would say that any time an author takes the extra trouble to write in an extra word and cross it out, they are making some kind of meta-comment deliberately, rather than straightforwardly revealing that the crossed-out word is representative of their true state of mind. The crossed-out word is a meta-comment on what the author thinks about the shared idea-space of the author-plus-audience, usually to say "hey I know that we all know that this concept exists", usually to also say "and that this concept is an unmentionable", and often to also say "and I think that's a bit funny".

In this case, we all know that some people conduct interviews as interrogations (and some people think that indeed they should do so), and on the other hand some people think that this is offensive. And brianm wants you to know that he knows we all know it.

MAYBE it's on his mind because he's an aggressive domineering jerk who likes to interrogate people, but he's sensitive enough to be a little defensive about it. MAYBE it's on his mind because he's NOT aggressive or domineering, and he's frustrated by how easily interviews become interrogations, and his whole deal is trying to prevent that without making the whole interview meaningless. MAYBE something else. How're you going to find out? Read the article!

My point, tl;dr: If you see a word crossed-out, by an author you don't already know, and you think "Oh this author really means the crossed-out thing", I think that's a poor comprehension strategy.

Post reply on HN