Goshdarnit. I just sat down and started talking to myself about hash functions, filesystems, the wire protocol, and partitioning scheme for half an hour instead of making dinner. Nerd sniping?
My Favorite Engineering Interview Question
21–30 of 131 posts
Re: My Favorite Engineering Interview Question
#22I'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…
I would imagine that for a certain number of candidates, they answer with a custom solution because they believe this is what the interviewer is expecting to hear (and asking for) when the question contains "you need to design, build, and deploy...". I think to some people, the immediate thought is that the interviewer would deduct points for originality if you said "well let's just use this tool off of the shelf". T…
I agree, and I try to make clear that I really want to understand how the candidate would approach it -- if they genuinely would try to find a perfect hash and keep a hash -> offset map in memory, then mmap a big data file, that is fine. I will ask how they will find the perfect hash, etc. If you can describe well the approach you take, then this is fine.
Ofttimes, though, candidates have started designing a general purpose on-disk hash database. That is fine and dandy, and we always need a better database, but it is pretty orthogonal to the immediate problem.
Actually, ofttimes engineers have implemented general purpose on-disk hash databases as part of j. random project, so that path certainly does occur on real projects :-)
Re: My Favorite Engineering Interview Question
#23When I see "the data never changes" http://cmph.sourceforge.net/ springs to mind
Oo, very nice. This is going to get explored Thank you for the link!
Re: My Favorite Engineering Interview Question
#24Earlier 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.
Yeah, but it wasn't technical. The point of the question was to assess my entrepreneurial IQ, or so I was told after. Generally if an unemployed person's applying for a job, their entrepreneurial IQ is low at the moment and they need money. Nevertheless: I was to acquire a desk to work at, which needed to have certain dimensions for under a certain dollar figure. The internet is down, the local office supply company doesn't have it, etc, etc, until I'm starting to think the interviewer is nuts. OK, I'll sit on the floor. His point was that you need to generate options, which isn't bad advice. But it was a dumb interview question.
Re: My Favorite Engineering Interview Question
#25Why have SSDs killed this question? Seems like you could tweak the amount of data on disk and/or the size of the values and/or the requests/second requirement and keep using it. Also, there are no 1TB SSDs available at this point, so you'd still have to assume spinning platters for this, no?
I haven't thought about it deeply, but my first guess would be that the seek time of hard disks is what makes serving 5000 requests per second difficult; consumer-grade hard disks can perform something in the range of a few hundred (randomly distributed) IOPS at best due to seek time. SSDs make seeks (almost) free, so even one decent SSD should be able to service 5000 requests per second, assuming you can get a big e…
Multiple disks, across different physical servers (instead of RAID) would be good too.
You could also try increasing the throughput by having an in memory cache. The index/hash table can also be in main memory. Depending on the keys, locality can play a crucial role in prefetching data.
Re: My Favorite Engineering Interview Question
#26An 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…
I have done this before, usually if I am working on something interesting, and for which I don't like any solution I have yet hit on. In this case, I do the best I can to describe the problem, thinking thus far, etc, and turn the interview into a design session at the whiteboard.
I can only recommend doing it with a candidate you are more selling to then evaluating, and whom you think will be a good fit.
A strong candidate will jump in and you'll have a great session (I had one in particular with a great young erlanger whom we wound up losing to someone else, but the interview left a lasting impression and we kept in touch long afterwards).
Re: My Favorite Engineering Interview Question
#27My favorite: "Write a script that will save you one minute of time every day"
closely followed by
"Draw a picture of your job/Facebook/the future /whatever"
Re: My Favorite Engineering Interview Question
#28I'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 to fit inside RAM.
I think the question is a good one because it does touch on a lot of aspects of infrastructure and systems design.
Re: My Favorite Engineering Interview Question
#29Earlier 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…
Maybe the test was how you react on this.
It was, but if you can show me a person that deals well with failure then you've shown me a CEO or saint.
Re: My Favorite Engineering Interview Question
#30[deleted]