The Mother of All Interview Questions • Hacker News Board

Re: The Mother of All Interview Questions

#71

Post by KennethLStein » Wed, Aug 03, 2011, 12:57 AM UTC

raganwald wrote: post #70

KennethLStein wrote: post #68

Earlier quoted context omitted.

Appreciate your reply. This question likely places candidates in a difficult situation, especially younger candidates who are excited about the opportunity, or those needing the job. If the interviewer plans on asking this question, they ought to have conducted a patent search prior to the interview. If patents or applications are found - ask the candidate about the problem that was solved by the claimed invention. A…

If no patents/published applications naming the candidate are found, don't ask the question. We can’t possibly be conducting the same kinds of interviews with the same kinds of candidates. Or possibly you are talking a very narrow view of the word “invention.” Or you work in a phenomenally litigious sector. For my purposes, “Describe a technical problem you encountered at XYZCorp and how you solved it” is a standard…

search for patents and published applications at:

http://appft1.uspto.gov/netahtml/PTO/search-adv.html http://patft.uspto.gov/netahtml/PTO/search-adv.htm

the query to use is:

in/lastname-firstname

If you don't find any references, then asking the candidate to describe a technical problem and means by which they solved it is less likely to be received as a request for confidential information.

Hope you find the above links and search query useful!

Best.

Re: The Mother of All Interview Questions

#72

Post by lars512 » Wed, Aug 03, 2011, 1:14 AM UTC

tmp43522 wrote: post #41

ChuckMcM wrote: post #20

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…

The things which weren't said explicitly but which we can assume are that the original implementer wasn't around any more, and that nobody else understood the system either.

With these pieces of information, the decision to re-implement seems like a reasonable one.

Re: The Mother of All Interview Questions

#73

Post by Xorlev » Wed, Aug 03, 2011, 1:16 AM UTC

ChuckMcM wrote: post #20

raganwald wrote: post #8

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…

That's a pretty dim view. Sometimes systems are too complicated, or have swaths of dead code that you spend hours figuring out only to find out they're never referenced anymore.

I'm currently working on a project which was written somewhat poorly with little technical oversight, the result being a minefield of code which is slightly brittle and full of dead codepaths. The old system (which works, is complicated and creaky, and I spent some days figuring out out things worked) needs rewritten and if we weren't pressed for time I'd rewrite it in a heartbeat.

Given a goal, an API spec, expected behavior one can rewrite a system which one doesn't truly understand and still do it better.

Certainly, something built by one person is rarely the best. That being said, what's wrong with occasionally taking out the trash?

Re: The Mother of All Interview Questions

#74

Post by n09n » Wed, Aug 03, 2011, 1:24 AM UTC

Mikushi wrote: post #50

tmp43522 wrote: post #41

Earlier quoted context omitted.

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.

He didn't say this system was unreadable or undocumented, only "complicated and creaky," One particular programmer who was regarded as "smart" couldn't figure out what it did, but it may just have been too complex for him.

Re: The Mother of All Interview Questions

#75

Post by cdavid » Wed, Aug 03, 2011, 1:27 AM UTC

Xorlev wrote: post #73

ChuckMcM wrote: post #20

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…

That's a pretty dim view. Sometimes systems are too complicated, or have swaths of dead code that you spend hours figuring out only to find out they're never referenced anymore. I'm currently working on a project which was written somewhat poorly with little technical oversight, the result being a minefield of code which is slightly brittle and full of dead codepaths. The old system (which works, is complicated and c…

In my experience, when you have a system that works, is creaky, and you have to spend days to understand how thing work, there is at best a significant gap between actual and specified behavior. Most of the times, there is actually no spec at all, it is mostly implementation defined. And you rarely have the same team as the one who did the previous team (people left, have to work on other projects, etc...).

That's one of the fundamental issue with complete rewritea: the systems you could most easily rewrite are often the one you don't need to.

Re: The Mother of All Interview Questions

#76

Post by bluekeybox » Wed, Aug 03, 2011, 1:33 AM UTC

ChuckMcM wrote: post #20

raganwald wrote: post #8

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…

> My experience has been that things built by two or three people, working as peers, are often much 'better' (meet the needs better, cover more cases, have a more consistent model) than things built by one person

I concur, but for a different reason than you seem to imply (which seems to be "being conservative with changes and goal-oriented" -- nothing wrong with that on its own though). I noticed that my own coding improved dramatically after I started working with others. This is due to several things: (1) competition and trying to be better than others, (2) once you work with several people, you take extra time to document what you are doing, which occasionally leads to you rethinking how you should be doing what you are doing in the first place, (3) don't know about you, but I am personally far more prone to taking "shortcuts" when working on my own (no one to embarrass myself in front of), (4) last but not least, when working with others, you can learn directly from others.

Re: The Mother of All Interview Questions

#77

Post by gdesouza » Wed, Aug 03, 2011, 1:43 AM UTC

ChuckMcM wrote: post #20

raganwald wrote: post #8

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…

It's just good engineering practice to ask yourself periodically, why are we building this new component? If the answer ever ceases to be convincing, yell, scream and bitch until your team (btw, you should probably spearhead this effort) can convince you otherwise.

That's really the hardest part of working by yourself; it is very hard to strike the right balance between self-criticism and unwavering focus required to create something, be it code or a work of art.

Re: The Mother of All Interview Questions

#78

Post by daemin » Wed, Aug 03, 2011, 1:57 AM UTC

bambax wrote: post #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.)

I'm a bit confused with what the word invention means in this context. Does it mean truly inventing some new algorithm (not in Knuth) as a normal part of your work. Or does it mean just writing new code from scratch rather thanh using a library?

I've written a lot of code in my career (and as a hobby), but I doubt that I've truly invented something new.

Re: The Mother of All Interview Questions

#79

Post by tmoertel » Wed, Aug 03, 2011, 2:20 AM UTC

ChuckMcM wrote: post #20

raganwald wrote: post #8

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…

You wrote that reasonably smart people couldn't figure out the old system, even with a couple of days' investigation. How is this a good system? If people can't figure it out, how are they supposed to use it?

Then you wrote that, when the new system appeared, "nearly everyone" moved to it. Doesn't this suggest that the new system was actually better? Why would most of the old system's clients, for example, pay the price to move to the new system unless they believed it was improved enough to be worth the migration cost?

I'm not saying that your conclusions are wrong, just that from reading your anecdote, it's not clear how to reconcile your claim that the rewrite was an mistake with the evidence that the result of that mistake seems to be preferred by nearly everyone who had the choice to keep using the old system.

Re: The Mother of All Interview Questions

#80

Post by raganwald » Wed, Aug 03, 2011, 2:21 AM UTC

xilun0 wrote: post #69

Once you start calling anything an invention, the next logical step is to allow to patent it. OK it's too late for the US, but we still have some hope in Europe, so unless you are writing stuffs using concepts and algorithms never used before, and not even appearing in TAOCP, which i highly doubt, stop calling your shit an invention. Also don't do it because that is very probably insulting to Knuth, Dijkstra, et al.

Once you start calling anything an invention, the next logical step is to allow to patent it.

“Invention” and “Patent-worthy Discovery” are not synonymous:

  An invention is a better or more effective composition,
  device, or process. An invention may be derived from a
  pre-existing model or idea, or it could be independently
  conceived in which case it may be a radical breakthrough...

  An invention that is novel and not obvious to others
  skilled in the same field may be able to obtain the legal
  protection of a patent.

https://secure.wikimedia.org/wikipedia/en/wiki/Invention

It is possible and normal to invent things that are not novel, or may be obvious to others skilled in the same field. It’s still invention, it just isn’t “Big I” Invention, it’s a more modest creative process.

Think of it this way: We have the expression “re-inventing the wheel.” If it wasn’t possible to invent things that already exist, it wouldn’t be possible to “re-invent” anything, would it?