A. Pagaltzis wrote:
* Yossi Kreinin <yossi.krei...@mobileye.com> [2007-06-13 17:55]:
There are many programming languages solving the same problem
of programming, many operating systems solving the problem of
operating a system, many web browsers solving the problem of
browsing the web, and many idiotic programs solving the problem
of wishing to look at an idiotic program for amusement (dc.sed,
etc.). Some of them succeeded, some didn't. Few people would
agree that the ones that largely failed did so because they
largely failed to solve the problem.
Yeah, but that sort of success criterion is irrelevant to a
discussion in an interview; if someone brought along a copy of
some part of the BeOS kernel, say, or a short excerpt from a
REXX interpreter, I certainly wouldn’t mind talking about it.
Sure. I didn't argue with a suggestion to reject programmers who worked on
projects that failed for non-technical reasons or the like, since naturally
nobody proposed that. What I wanted to say was that some people don't like
working on "the next big thing", and would rather work on "the current big
thing". At least 3 great programmers I know are like that. And one of them
actually works for fun, since he's made enough money on a previous job to not
have to work anymore. But he *works for a company* for fun, not writing open
source stuff.
It took me some time to even realize that category of people exists, and I'm not
sure I fully understand their perspective today, which may be the reason I
didn't really make myself clear. I think that for this kind of people, something
doesn't even exist until they actually see people using it or asking for it, for
some of them that must be physical people around them. For these people, working
on problems someone finds important enough to pay for makes sense, and working
on something which theoritically can become interesting to people or it may not
doesn't make sense.
Usually, people who like the current big thing are into implementing stuff, and
people who like the next big thing are into defining stuff. Apparently the first
category is larger, and I don't think that it's unique to programming. For
example, 4 out of 5 strongest hardware hackers I know are into implementations,
not architecture definitions.
As to your other message, about writing code before the interview - sure, every
good candidate should be able to do it. I'm only saying I don't like the idea of
making writing code outside of one's job a precondition for an interview.
