Live data from Hacker News

My Favorite Engineering Interview Question

skife.org

31–40 of 131 posts

Re: My Favorite Engineering Interview Question

#31
Why is binary search such a bad solution to this problem? Is it the number of required requests? We have no concept of how much memory is on the system, perhaps it's sufficient for the common parts of data that are traversed and you rarely have to return to the actual hdd.

Re: My Favorite Engineering Interview Question

#33

Earlier quoted context omitted.

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…

Very dumb question, indeed.

Re: My Favorite Engineering Interview Question

#35
post #21

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?

Why fret about the wire protocol? ZeroMQ will send messages plenty fast enough, and it's really very simple to use; just a few lines of code.

Damn you, now you've got me doing it. Nerd sniper. ;-)

Re: My Favorite Engineering Interview Question

#37
I love to ask something that is simple to start with, and then build on it interactively with the candidate.

One of my favorite questions is - Give me a normalized database structure that you'll implement if you were to build gmail - incorporate conversations, messages, multiple message participants and labels.

Then, depending on the candidate, I build upon the question,and go into various optimizations possible, the ways caching would be implemented, sharding/splitting/de-normalization would be done with load, etc. etc. With good candidates, its always a very interesting discussion. And even the bad ones can leave the interview thinking they know something and don't need to feel bad :)

Re: My Favorite Engineering Interview Question

#38

Earlier quoted context omitted.

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…

Perhaps the interviewer wanted to see if you could think up something like http://glinden.blogspot.com/2006/01/early-amazon-door-desks.... - and in the process test your willingness to be in an environment with such jury-rigged solutions.

Re: My Favorite Engineering Interview Question

#39
I was unsure on how to answer this question since most of my experience is in application development.

I'd like to not be embarrassed when asked this question. What advice would you give someone wanting to learn enough to answer this question?

Are there any projects, books or other resources one could undertake?

Re: My Favorite Engineering Interview Question

#40
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…

I feel the same way about little puzzles that companies like to present to the candidates, especially the ones with a "trick" answer.

I never worked in a place where I had to solve tons of small little puzzles all day, or have to memorize a set of obscure language features, and can't look them up online if I need to.

As you said, the best interviews are the ones by a white-board, working together to solve something resembling a real problem. Because, eventually that is what I will end up doing if I work there.

Post reply on HN