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

61–70 of 131 posts

Re: My Favorite Engineering Interview Question

#61

Post by jemfinch »

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" problem that you either get or you don't get. It's complex enough to reveal the candidate's thought process and problem solving methodology, but it's small enough for good candidates to get to a reasonable solution in the 45-60 minutes of an ordinary interview.

Nothing about the article indicates that the author has a chip on his shoulder, nor that he's a dork who wants to "battle it out for dominance as alpha-geek."

Nothing about the article indicates that author is looking for a specific solution reflective only of his particular prejudices in programming.

What in the world is the basis for your entire diatribe here?

Re: My Favorite Engineering Interview Question

#62

Post by garazy »

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.

Re: My Favorite Engineering Interview Question

#63

Post by jemfinch »

tbrooks wrote: post #36

Ning cut 40% of it's staff in April. Why are they hiring new outside developers?

Because some of us went on to better places :) Ning was recognized for its selectivity in hiring; though it did come as a shock, everyone that I knew in my short time there landed on their feet at similar or better operations (Google, Amazon, Etsy, etc).

In the intervening months since the layoffs, there's also been some attrition (as there always is) in those who weren't laid off. I know of at least two people who weren't laid off, but left for Facebook shortly after the layoffs.

I also know that they've already hired back at least one of my former coworkers since the layoffs.

Re: My Favorite Engineering Interview Question

#64

Post by jemfinch »

jhuckestein wrote: post #43
swaits wrote: post #34

Earlier quoted context omitted.

A picture? Are you hiring artists? Seriously. What do you get out of that?

A picture is a useful abstraction of reality. It forces people to think about what they'll 'answer' before they do. Some people might draw a diagram, some might draw a story, who knows. It tells a lot about people and how they think. For some people this may seem like a fun task and they'll get excited about it, some may not find it useful and argue about it and others (the ones you want to avoid) will frown upon it…

I think it's not useful because you're not hiring me to draw pictures. I'd pass on any interview where crayon drawings of my future had any impact whatsoever on the likelihood of my hire.

Re: My Favorite Engineering Interview Question

#65

Post by dbt »

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 know about you, but when I am interviewing people I am not trying to find "diamonds in the rough", I'm trying to find the best person to join the team and contribute. That may or may not include experience, but it certainly includes the ability to solve problems.

This isn't an unanswerable question. I've asked and gotten great answers to a very similar question about handling data at scale. And what I'm looking for includes the opposite of a chip on the shoulder.

Re: My Favorite Engineering Interview Question

#66

Post by tlb »

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…

Some interviewers are searching for talent, some are weeding out bozos. (The categories overlap: I know some talented bozos.)

Re: My Favorite Engineering Interview Question

#68

Post by ojilles »

ora600 wrote: post #19
barrkel wrote: 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…

The idea is that you don't have to write a DB - it is already there, usually even deployed and monitored by your ops team. Even if it gives absolutely no other value, thats a big plus. In terms of randomly distributed requests: I'm surprised the topic of "working set" is not part of the question. Even with huge amounts of data, if the working set can be stored in RAM and only rarely swap data in and out, its a much d…

Requests are evenly distributed, so caching will only be "effective" if it approaches the size of the whole dataset.

Re: My Favorite Engineering Interview Question

#69

Post by tlb »

mhewett wrote: 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.

Yet, companies who can pull off those feats are the ones who survive. A 1 TB database, even 5 years ago, shouldn't take more than a week or two to build properly. The solution I've used in the past, a Netapp file server with hashed directories of key-named files, takes zero programming and a couple hours to install. (You can easily read 5000 files / sec over NFS from one of their file servers.)

Re: My Favorite Engineering Interview Question

#70

Post by caustic »

olegkikin wrote: post #50

Easily solved with SSDs. Sort the keys, value is stored right after the key. On each request do a binary search. It takes 32 seeks in the worst case. Even current consumer level SSDs can handle 45K IOPS, so you'd get 1400 complete searches/sec from one SSD. You might need to spread your data over 4 SSDs, but you can search in parallel, so it will even be faster. If you want more speed, replicate your drives and load…

In your case it would be better to use interpolation search[1][2] instead of binary search.

[1] http://en.wikipedia.org/wiki/Interpolation_search [2] http://sna-projects.com/blog/2010/06/beating-binary-search/

Post reply on HN