Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Favorite Engineering Interview Question

skife.org

Post reply on HN
Print view View original

81–90 of 131 posts

Re: My Favorite Engineering Interview Question

#81

Post by madaxe »

DannoHung wrote: post #44

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?

Because when you specify a disk, you realise he's guiding you in the direction of a specific answer.

Use the filesystem. It's what it's there for, particularly if the data never changes. Nice big cache, xfs, nested hierarchical datastore using folders based on keynames, 20 lines of code, job done. 5000 lookups a second is trivial throughput for a decent disk with a decent readahead cache.

Re: My Favorite Engineering Interview Question

#82

Post by lrm242 »

jemfinch wrote: post #61
lrm242 wrote: 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 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…

Seeing as you worked at Ning and likely participated in these types of interviews it's not surprising you don't get it. Surely Ning was a great place to work and I'm sure you found really top-notch employees through your well known tough hiring process, but I'd be willing to wager they all look very much the same when you blur your eyes a little bit.

My diatribe, as you so eloquently put it, is based on the article. The list of things that the author expects to see in the answer. The way the question is presented. The lead off with "interrogation". The "gotcha" follow-up regarding how things might fail. These questions are great at finding a very specific type of candidate, but the entire point of my comment is that this one candidate type is typically not indicative of the best engineer. Of course you'll disagree, I'm sure, seeing as you were part of this process.

Re: My Favorite Engineering Interview Question

#83

Post by follower »

garazy wrote: post #62
lrm242 wrote: 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 couldn't agree more, when I read the "interrogate" introduction it put me off reading the rest of the article.

Did you read the rest of the article anyway? The "interrogate" wording may present a bad first impression but the remainder of the article is pretty reasonable.

Re: My Favorite Engineering Interview Question

#84

Post by elliottcarlson »

ryandotsmith wrote: post #53
derwiki wrote: 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…

True. During my latest interview, Heroku asked me to design a billing/invoice system. I won the position and my first assignment was to work on the billing / invoice system. When I have the opportunity of conducting an interview, I will most certainly use this approach.

I truly apologize in advance - this is not meant to be flame bait or anything of that nature - but it bothers me when someone states they "won" a position. The interview process should be used to find a good match, both for the company as well as the candidate. When I am interviewed I am evaluating the company as well and will have no reservations turning them down if I feel I wouldn't be a good fit. If I have to win to get in to the company, then that alone would make me back off and possibly lose interest in the company.

Re: My Favorite Engineering Interview Question

#85

Post by palewery »

lrm242 wrote: 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…

How do you evaluate problem solving skills of candidates during interviews?

Re: My Favorite Engineering Interview Question

#86

Post by follower »

jtchang wrote: post #28

I've never been asked this question in an interview so when I saw it I started thinking about how I would answer it. The first thing I did was work out the actual bytes/sec (throughput) needed for this many requests. Also given the 2 week timeframe I would question really hard what the data set looks like. Since the requests aren't randomly distributed does that mean you can narrow it down to a small enough portion t…

> Since the requests aren't randomly distributed

Does this follow when the original article says:

  "The keys are not distributed evenly within the keyspace."
and:

  "Requests are distributed evenly (and randomly) across the keys"

Re: My Favorite Engineering Interview Question

#87

Post by follower »

I'm trying to work out if this is a thinko on my part or a typo on your part:

First you write:

> a system that lets you look up the value for a given key

and then later on you write:

> if they think the problem of looking up a key by value has been solved before

Did you mean to say "looking up a value by key" or am I misunderstanding it?

(Given that no one else has commented on it makes me question my question but I'm trying to get over my concern of being wrong on the internet and asking to be sure. :) )

Re: My Favorite Engineering Interview Question

#88

Post by ntoshev »

user24 wrote: post #76
ntoshev wrote: post #71

Earlier quoted context omitted.

Yeah, I also thought he expected to serve it all from a single disk. Hopefully in real life it gets clear in the discussion. It's a problem when asking interview questions: there are many ways in which the question may be unclear and the interviewer is mislead that the applicant can't answer. Another problem may be that the interview interferes with the thinking style of the applicant: you try to discuss it with him…

> there are many ways in which the question may be unclear and the interviewer is mislead that the applicant can't answer. yeah, when I was interviewed for my university, they asked me to design an algorithm to work out the n'th term of the fibonnacci sequence. They repeatedly said I didn't need to use recursion or loops. When I finally gave up, they said: well here's one way: f(n) = f(n-1)+f(n-2) I just looked at th…

They were likely trying to help you and wanted to say they don't care whether you write an iterative or recursive solution.

Re: My Favorite Engineering Interview Question

#89

Post by tsycho »

jsankey wrote: post #8

An idea I've tried a bit in the past (and would like to try more, given the chance): ask a question that you don't know the answer to. This shifts the power balance of the interview - you don't automatically have the answer over the candidate. You also don't have your mind closed by your expected answer(s). Both of these make the resulting discussion more comparable to how you will work with a colleague, which is wha…

That's a very good idea. I would go further and tell the candidate that I don't know the solution myself, thus hopefully putting him/her at ease and making it clear that I am more interested in the thought and design process, rather than figuring out the "trick" in the question.

The tough part here is to choose a good question.

Re: My Favorite Engineering Interview Question

#90

Post by ckoenig »

Hmm my first thought was ... well ... WTF Then I thought - man I'd like to work for this corp. but alas I think I'm to stupid for that. Some moments of reflection later I'm now convinced that I don't want to work there at all.

The question is somewhat similiar to "give me the fastest sorting algorithm and prove that it is" Everyone with a CS-degree or something similar will know this prove and Qsort from his very first years and I claim almost everyone will have forgotten the prove. (I can remember that you can prove this by looking at the "descision" tree passed on the 1on1 comparision which will have depth of about the needet size ;) - but this is it) I think most people will get the prove (even without google or wiki) in a resonable time (some hours?) but within interview-time and in this situation? In my case no way.

Post reply on HN