Live data from Hacker News

My Favorite Engineering Interview Question

skife.org

121–130 of 131 posts

Re: My Favorite Engineering Interview Question

#121
post #97

Earlier quoted context omitted.

I appreciate the feedback, but don't think I fall into, nor describe in the linked blog post, the interviewer category you describe (though it is certainly possible I do and just don't realize it). Do you consider this question to be unanswerable? As I stated, I'll accept pretty much any viable answer, my goal is to get folk to design something ~realistic (okay, this is a simplistic system, but we have finite time in…

Part of what's problematic about this interviewing approach is that while your (secret) internal mindset may be "I'll accept pretty much any viable answer", the full-court-press interviewing style effects the exact opposite impression on the candidate -- they're left thinking, "gosh, I have to get this right, dammit, no room for slack, can't leave out any details AT ALL or it's back to another month of ramen and job…

Is "full-court press" and "your interviewing technique" from personal experience with the OP? Or just from reading the article?

Because all I got from the article is that he has lots and lots of follow-up directions. I.e., that he is prepared.

Re: My Favorite Engineering Interview Question

#122
Great thought question. Being a junior developer, I haven't the slightest clue on how to answer it. Having been exposed to merely algorithms in school, would it be safe to assume that this wasn't really targeted at software engineers but more towards system designers?

Re: My Favorite Engineering Interview Question

#123
Using general purpose database in such case is just an approximation of a solution, ie. if the database supports index-optimized type of table and smart enough to cache index header blocks quickly enough.

Because of extreme primitiveness of this case, custom solution would work better here than general purpose db. Sort the pairs by key and place in the tree, with the root node containing 2^11 keys (512K), second level - 2^11 nodes of 2^11 keys each (512K each node size), 3rd level - 2^22 nodes of 2^10 keys (256K each node size). Keep root and all the second level nodes always in memory (1G RAM required). Given a key to find, look it up through the root and the second level nodes in memory - this would result in the index of the 3rd level 256K node to be read from disk. Time-wise reading a 256K block from disk is just one IO - pretty much the same time as reading 1 byte.

5000 lookups/sec at 1 IO/lookup - 20 disk array of 250 IO/sec disks - 15K ones would do it. 2 arrays of 400GB disks is still ~2 times cheaper than 1 TB SSD array. RAID5(6)-ing the disks will leave us with 6TB. Short-stroke the first 1TB (70Gb x 20) to get much better speed than 250 IO/sec (or just use less than 20 disks to start with) and enjoy the rest 5TB for non-IO intensive purposes.

Re: My Favorite Engineering Interview Question

#124
Sorry, I'm not a hacker, I wouldn't know the first thing about setting up an interface to a hard drive. However, the first thing that pops out at me is that you just described a 512 GB addressing scheme. You want half your disk to be unaddressable?

Re: My Favorite Engineering Interview Question

#126
If you have more data than, say, GDBM, can swallow in one bite, how could you break this data apart and then find the right chunk amongst multiple servers when given a key?

Also, what does the interviewer mean by this:

> I generally ask these folks if they think the problem of looking up a key by value has been solved before, especially given the two weeks to be live in production requirement.

Is that a typo? s/key by value/value by key/ ?

Re: My Favorite Engineering Interview Question

#127

Earlier quoted context omitted.

Part of what's problematic about this interviewing approach is that while your (secret) internal mindset may be "I'll accept pretty much any viable answer", the full-court-press interviewing style effects the exact opposite impression on the candidate -- they're left thinking, "gosh, I have to get this right, dammit, no room for slack, can't leave out any details AT ALL or it's back to another month of ramen and job…

Is "full-court press" and "your interviewing technique" from personal experience with the OP? Or just from reading the article? Because all I got from the article is that he has lots and lots of follow-up directions. I.e., that he is prepared.

From the article. The flip side of the fact that the interviewer has had time to carefully prepare while the interviewee has not is that what you get from that inherently contrived, lopsided discussion, kind of a long, drawn-out game of "gotcha." Fun for the interrogator interviewer, but tedious and buzz-killing for the interviewee.

It provides insight, yes, but a certain cost: many candidates fine this approach simply alienating, and more to the point, it upsets their thought processes (such that they don't really get a chance to shine).

As a candidate you can train for this kind of confrontational approach, of course, but I think lrm242 nailed what's most alienating about this interviewing style -- that ultimately the candidate is put into a position that's basically uncomfortable to be in, where they have to _placate_ their interlocuter according to some hidden criteria set -- and mostly they just want that particular thread to be overwith as soon as possible.

I just think we can get the same insight into candidates from different ways, where things are more on an even keel, and there's more "flow."[1] It takes more tact and creativity (and perhaps a bit more time), but it's not that hard, is more mutually enjoyable and (I think) ultimately provides a lot more insight.

[1] "flow" being of course a very important concept; e.g. in the sense of Murakami.

Re: My Favorite Engineering Interview Question

#128
It's everybody's favorite interviewing technique: Ask a fairly esoteric question that you are thoroughly familiar with and sit there and feel superior while the candidate struggles to get to an answer you will accept. Three kinds of candidates do well: those who are smarter than you are and spit out answers that surprise you; those who have heard the question and act like they're thinking it through for the first time; those who are unfamiliar with the area but have a personality you find congenial, so you coach them to a solution. In the end, it's all about ego.

Re: My Favorite Engineering Interview Question

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

It's not useful because it has nothing to do with what you're hiring them for. Frankly, if I were asked to draw a picture, I'd probably walk out. If that means you don't want to work with me, then I probably wasn't going to enjoy working with you either.

I've been hiring game programmers for a long time now. I think there are plenty of other ways to evaluate the non-tech personality/team-player side of candidates. Start with talking to them.

I ask very blunt questions in this area. Will provide examples if folks are interested.

Re: My Favorite Engineering Interview Question

#130
I'm in recruiting myself. If I would ask questions like this we would have been out of new employees very soon. Questions like this only intimidate the applicant and are much to complex for interviews. Also you seem to have the idea that you know the only "truth". This is ridiculous.
Post reply on HN