Live data from Hacker News

The Mother of All Interview Questions

raganwald.posterous.com

41–50 of 136 posts

Re: The Mother of All Interview Questions

#41

Earlier quoted context omitted.

The question of bias is an excellent one to ponder. I agree that my phrasing is biased, but so is: The last three times you faced a "build or buy (/use open source)” situation, which did you choose, and why? ...in a way, as it only covers places where there is a perception that there was a straight-up choice. One of the things I am interested in is places where the invetion-oriented folks didn’t perceive there was a…

When I was at Google I wished they had a few 'uncoders', people who made it their goal in life to leave the source tree with fewer lines of source than they found it. True story: I went to a talk given by one of the 'engineering elders' (these were low Emp# engineers who were considered quite successful and were to be emulated by the workers :-) This person stated when they came to work at Google they were given the…

I hate to depart from the group think, but there's another explanation aside from a smart engineer getting carried away with their own brilliance:

    They remarked how they spent a couple of days looking over the system which was complicated and creaky, they couldn't figure it out
Now it may be the case that they didn't really try to fix it and are just using that as an excuse, but OTOH, they may actually have been stumped despite best efforts.

If the system really did defeat this smart engineer's days of study, then in my opinion, and the opinion of at least one discussion I've seen on HN, the software should have been rewritten. (IMO) this really needs more clarification before scorn is passed.

Re: The Mother of All Interview Questions

#42
Invention vs re-use. Unless the candidate is willing to take an honest, logical approach to this decision (involving defendable reasoning), I'd be wary.

Is it a solved problem? No? Invent it.

Is the solution available to you within your constraints? No? Make your own implementation (unless there's a way to acceptably compromise in the design).

Is the solution cost-effective to use (performance, ease-of-use, bugginess, support, etc)? No? Make a better implementation.

Otherwise just re-use an existing solution.

Re: The Mother of All Interview Questions

#43

Invention vs re-use. Unless the candidate is willing to take an honest, logical approach to this decision (involving defendable reasoning), I'd be wary. Is it a solved problem? No? Invent it. Is the solution available to you within your constraints? No? Make your own implementation (unless there's a way to acceptably compromise in the design). Is the solution cost-effective to use (performance, ease-of-use, bugginess…

  Is it a solved problem? No? Invent it.
Something to consider: Sometimes we can change the rules. If given requirements A, B, and C, and we discover that “A” is not a solved probloem, we could go ahead and invent a solution. Then again, perhaps we can push back and ask if some lesser requirement A’ (which is a solved problem) is sufficient for success.

The converse is possible as well. Given requirements X, Y, and Z, all of which are solved problems, sometimes we can raise our hands and say “Will we really be successful implementing another Me-Too thingummy? If we take a chance and try to add feature W—which is not a solved problem—we will have a competitive advantage.”

I agree with your basic premise, but want to point out that given a certain bias, we can sometimes fark around with the requirements to suit ourselves. So a candidate in an interview could easily convince you that he had to invent a way to synchronize documents while supporting offline editing, but aother candidate in the same situation might have avoided the requirement necessitating invention in the first place. Or the reverse!

Re: The Mother of All Interview Questions

#45
post #2

> Does your process involve invention? If so, please describe the three most recent things you have invented and why it was necessary to invent something new. If you're asked this in an interview, you can't respond "no". If I were being interviewed, I'd hear it as somewhat like "Do you like unicorns, which are awesome? If so, describe your three favorite awesome activities with unicorns." Which is fine, if you're on…

> If you're asked this in an interview, you can't respond "no".

I don't see why not! It would save lots of time.

This is a poor question as phrased. If you want to know about the developer's attitude toward reuse versus DIY, then simply ask that. The common usage of the word "invention" today invokes questions about intellectual property, patent rights, copyright et al - topics most developers would likely rather avoid.

Re: The Mother of All Interview Questions

#46
The word "invention" is ambiguous. I invent what I don't know, therefore, the less I know, the more I invent. Incompetence is the mother of invention.

IMHO, creativity is a better word: creativity builds on previous knowledge.

(I'd like to expand on this but after many rewrites of this comment I can't phrase properly what I want to say so I'll just leave it at that.)

Re: The Mother of All Interview Questions

#48

Earlier quoted context omitted.

The question of bias is an excellent one to ponder. I agree that my phrasing is biased, but so is: The last three times you faced a "build or buy (/use open source)” situation, which did you choose, and why? ...in a way, as it only covers places where there is a perception that there was a straight-up choice. One of the things I am interested in is places where the invetion-oriented folks didn’t perceive there was a…

When I was at Google I wished they had a few 'uncoders', people who made it their goal in life to leave the source tree with fewer lines of source than they found it. True story: I went to a talk given by one of the 'engineering elders' (these were low Emp# engineers who were considered quite successful and were to be emulated by the workers :-) This person stated when they came to work at Google they were given the…

Make no mistake about it. Being too quick to rewrite a system is bad. It causes unnecessary work for others and can throw a schedule behind drastically.

That said, I think it's important not to go to the opposite extreme. Personally, I'm in the camp of being too quick to rewrite things myself. And though I've learned to control my gut instinct in this regard, I've also learned that sometimes it's right.

I can name several instances where everyone would have come out better just by rewriting the damn thing up front rather than trying to fix or maintain the old system.

TL;DR - Sometimes discarding your peers' work is the best way to respect them.

Re: The Mother of All Interview Questions

#49
> please describe the three most recent things you have invented

The "most recent" qualifier makes this a short answer, which would be:

Of the last three of my inventions, two are trade secrets and the third has not completed the patent application process. I am not able to discuss any of these. Would you rather discuss some of the patents I hold that are public instead? While you are considering I would like to know what your company's exact policy is regarding the projects and things I will be inventing outside work hours using my own equipment. Obviously the policy will have a major impact on whether I decide to consider accepting an offer to work here.

Re: The Mother of All Interview Questions

#50

Earlier quoted context omitted.

When I was at Google I wished they had a few 'uncoders', people who made it their goal in life to leave the source tree with fewer lines of source than they found it. True story: I went to a talk given by one of the 'engineering elders' (these were low Emp# engineers who were considered quite successful and were to be emulated by the workers :-) This person stated when they came to work at Google they were given the…

I hate to depart from the group think, but there's another explanation aside from a smart engineer getting carried away with their own brilliance: They remarked how they spent a couple of days looking over the system which was complicated and creaky, they couldn't figure it out Now it may be the case that they didn't really try to fix it and are just using that as an excuse, but OTOH, they may actually have been stum…

Indeed. If i cannot understand a system (in my field) in a couple of days (depending on the size), and have been asked to work on it, chance is i'll ask for a rewrite, with documentation and readable code.

If your system is not readable and undocumented, don't blame the guy who will come and decide to rewrite it.

Post reply on HN