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

11–20 of 131 posts

Re: My Favorite Engineering Interview Question

#11

Post by derwiki »

bialecki wrote: post #4

I like this question, but I'm wondering what a good interview looks like if someone is completely blind-sided by the question because they don't have a lot (or any) systems experience? I'm imagining an engineer who's experience ends with MySQL so knowledge of stuff like tcb is a definite no. Maybe that's not an issue, because they wouldn't be interviewing for this job if that was the case.

... not an issue if the questions are relevant to the job. On the other hand, recruiting is hard and it's easy to let a great candidate slip by for any number of reasons.

Re: My Favorite Engineering Interview Question

#12

Post by zeraholladay »

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…

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 without telling me. I thought the guy was a jerk. He could just have pulled a gun on me and demanded my wallet if he wanted to judge my personality. I declined the second round.

Re: My Favorite Engineering Interview Question

#13

Post by cs_loser »

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…

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 least the complicated components of it and code the rest yourself.

You can think of two extreme answers to this as "buy oracle" and "buy some transistors". Those are both bad answers. The first is a bad answer because, unless the candidate can answer the follow-up question "how does oracle work?" it probably just amounts to wishful thinking and they almost certainly won't be able to say when it will fail. The second is a bad answer because you can't do that in two weeks by yourself.

Take for example, Foursquare's recent outage. From what I read online, it seems like they went with "use MongoDB" as a strategy without actually understanding what Mongo was doing under the hood. Presumably they didn't figure out how it would fail (the author's follow-up question, natch) and thus they discovered that the hard way. So they chose bad answer one. On the other hand, had they decided to implement their own database, they'd know all about its characteristics, but they wouldn't have launched yet.

Re: My Favorite Engineering Interview Question

#14

Post by jemfinch »

codeslinger wrote: post #2

Why 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?

This may come as a shock, but you can put more than one SSD in a server :-P

Re: My Favorite Engineering Interview Question

#15

Post by brown9-2 »

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…

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".

This is why interviews are so tricky - it's hard as a candidate to juggle answering the question and trying to decipher what traits the interviewer is really trying to expose with this question.

For example with this one: is the interviewer trying to see if I understand my data structures and the size of this data to the point where I could design such a system from the ground up? Or are they trying to see how practical I can be given real-world time constraints?

Re: My Favorite Engineering Interview Question

#16

Post by jemfinch »

zeraholladay wrote: post #12
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…

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.

Re: My Favorite Engineering Interview Question

#17

Post by albertzeyer »

zeraholladay wrote: post #12
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…

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.

Re: My Favorite Engineering Interview Question

#19

Post by ora600 »

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 different problem than 5000 disk reads a second. Lots of databases are optimized to efficiently maintain cached data in memory and swap as little as possible and as efficiently as possible.

Re: My Favorite Engineering Interview Question

#20

Post by brianm »

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…

I have gotten solutions which implement custom stores which I have had faith that the candidate could build, but not many. I am not dead set against it, but I will press for an estimate and a good explanation of it if they want to go down that route.

I try to emphasize that I want to know what they would actually do, on the job. Other questions (typically other interviewers) will explore algorithmic stuff, and folks I work with have used this question with that intent -- I use it to see how they think about building systems.

Another thing I didn't mention in the blog post is that up front I tell them exactly what I am looking to learn. I am not going on a fishing expedition, or trying to trick anyone. I find that kind of "second guess the interviewer" thing to be asinine, so strive to avoid doing it myself.

Post reply on HN