From: Eric Smith
Subject: Employment puzzles and Lisp
Date: 
Message-ID: <ld3tn0df1c10u0k7j77l6gqh3to7vtojoq@4ax.com>
I saw a news story this morning with the headline "Google Working to
Recruit Brainy Elite."

The story mentioned anonymous billboards that read "(first 10-digit
prime found in consecutive digits of e).com"

That website led to another one, with another such puzzle, which led
to a login where the person who solved both puzzles would be asked for
their resume to apply for work at Google.

Lisp made it easy to solve both puzzles, but after solving them and
using the resulting password to log in, I got a message saying Google
was no longer accepting responses.

What I'm wondering is whether Google actually hired people based on
such puzzles.  Or was it just a recruiting stunt whose only purpose
was to increase the number of resumes they received, and then filter
those exactly the same way as all the rest?

It seems to me that if this kind of puzzle solving actually gets
anyone hired, and turns out to be a successful way to get good
employees, other companies might do the same thing, and it might
become much more common.  In that case, those who use Lisp would have
a big advantage, because of how good it is for solving such puzzles.
So even if we can't get Lisp jobs, we might get good jobs because of
Lisp.

Getting a good job normally requires a lot of incidental skills.  You
need good interview skills, etc.  Technical ability usually takes a
back seat to such things.  But if some companies actually start hiring
on the basis of puzzle solving ability, it could change that.  I bet
there are huge numbers of Lisp users who aren't very good at getting
jobs, who might end up getting much better jobs than in the past if
this becomes a trend.  But will it?

--
(do((x(coerce "iukd9/.-<`[kl_b^b^ _Uc"
'list)(cdr x)))((not x))(princ (code-char
(- (char-code (car x)) -18 (length x)))))

From: Steven E. Harris
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <jk4oeip45qo.fsf@W003275.na.alarismed.com>
Eric Smith <··························@from.sig> writes:

> In that case, those who use Lisp would have a big advantage, because
> of how good it is for solving such puzzles.

Perhaps if the job openings were akin to a race, with Lisp helping one
to solve the puzzle faster, but I suspect that Google would rather see
an applicant solve the puzzle in whatever language is exercised most
on the advertised job -- no matter how long it takes. Picking the
right tool for the job is admirable and often advantageous, but such
freedom, or even the taste for it, may not be encouraged in the work
place after all.

As you likely suspect, luring a great puzzle solver will also catch
iconoclasts, of whom demanding happy conformity amounts to a
bait-and-switch.

-- 
Steven E. Harris
From: Bernd Beuster
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <clmamu$enb$1@online.de>
I read it in /. and after reading the solutions in the web (Python, 
Java, even C) I was curiously to find a LISP example.  So I wrote one 
for myself (http://www.profibing.de/lisp/google-billboard.lisp).




-- 
Bernd
From: Frank Buss
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <clmsek$ir1$1@newsreader2.netcologne.de>
Bernd Beuster <·············@lycos.de> wrote:

> I read it in /. and after reading the solutions in the web (Python, 
> Java, even C) I was curiously to find a LISP example.  So I wrote one 
> for myself (http://www.profibing.de/lisp/google-billboard.lisp).

your calc-e function is inexact in the last digits and system:primep is 
not a Common Lisp function. I've found a better function in C:

http://groups.google.de/groups?selm=3e0374e6.0307080228.de07bce%
40posting.google.com

My version:

(defun compute-e (n)
  (let* ((len (truncate (/ (* 10 n) 4)))
         (a (make-array len :initial-element 1 :element-type 'integer))
         (digits (make-string n)))
    (loop for j from 0 below n do
          (let ((q 0))
            (loop for i from (1- len) downto 1 do
                  (let ((x (+ (* 10 (aref a i)) q)))
                    (multiple-value-bind (div mod) (floor x (1+ i))
                      (setf (aref a i) mod)
                      (setf q div))))
            (setf (elt digits j) (digit-char q))))
    (concatenate 'string "2" digits)))

It uses only short integers and can be enhanced, if larger integers are 
used. The hyperspec says "There is no limit on the magnitude of an 
integer". I'm right that all Common Lisp implemenations must support this 
and can I use arbitrary long integers?

Ok, now we need the prime. It's only 10 digits, so a very simple test is 
sufficient:

(defun is-prime (n)
  (let ((root (truncate (sqrt n))))
    (loop for i from 2 to root do
          (when (= (mod n i) 0) (return-from is-prime nil))))
  t)

(I don't like the "return-from", any better idea?)

Finally the function to find all 10 digit primes in e:

(defun find-prime-10 (max-digits)
  (let ((e (compute-e max-digits)))
    (loop for i from 0 to (- max-digits 10) 
          for check = (parse-integer (subseq e i (+ i 10)))
          when (is-prime check) collect check)))

For example there are 5 10 digit primes in the first 200 digits of e:

(find-prime-10 200) =>
  (7427466391 7413596629 6059563073 3490763233 2988075319)

=> http://7427466391.com

And it is fast in LispWorks:

> (time (find-prime-10 200))
Timing the evaluation of (FIND-PRIME-10 200)

user time    =      0.340
system time  =      0.000
Elapsed time =   0:00:00
Allocation   = 182304 bytes standard / 3850 bytes conses
0 Page faults
Calls to %EVAL    34
(7427466391 7413596629 6059563073 3490763233 2988075319)

-- 
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Gareth McCaughan
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <87brep2aq7.fsf@g.mccaughan.ntlworld.com>
Frank Buss wrote:

> your calc-e function is inexact in the last digits and system:primep is 
> not a Common Lisp function. I've found a better function in C:
> 
> http://groups.google.de/groups?selm=3e0374e6.0307080228.de07bce%
> 40posting.google.com
> 
> My version:
> 
> (defun compute-e (n)
>   (let* ((len (truncate (/ (* 10 n) 4)))
>          (a (make-array len :initial-element 1 :element-type 'integer))
>          (digits (make-string n)))
>     (loop for j from 0 below n do
>           (let ((q 0))
>             (loop for i from (1- len) downto 1 do
>                   (let ((x (+ (* 10 (aref a i)) q)))
>                     (multiple-value-bind (div mod) (floor x (1+ i))
>                       (setf (aref a i) mod)
>                       (setf q div))))
>             (setf (elt digits j) (digit-char q))))
>     (concatenate 'string "2" digits)))
> 
> It uses only short integers and can be enhanced, if larger integers are 
> used. The hyperspec says "There is no limit on the magnitude of an 
> integer". I'm right that all Common Lisp implemenations must support this 
> and can I use arbitrary long integers?

Yes, though of course in practice there is always a limit
(if only because memory is finite) and I'd be surprised if
the HyperSpec actually makes it impossible for the limit
to be, say, 2^32.

Anyway, assuming we don't have such a pathological implementation,
I suggest the following completely straightforward code:

    (defun compute-e (n)
      "First N+1 digits of e, as a string. Last digit may in principle
      be wrong, but I bet it never is in practice."
      (let* ((10^n (expt 10 n))
             (bound (* 10^n 1000000))
             (e (loop for k upfrom 0
                      for k! = 1 then (* k! k)
                      while (<= k! bound)
                      sum (/ k!)))
             (10^n.e (floor (* 10^n e))))
        (format nil "~A" 10^n.e)))

If for some reason we needed an actual guarantee of accuracy,
it wouldn't be hard to tweak it so that it stops when it can
prove that it has the first N digits right. (It's easy to
provide an upper bound on the truncation error when summing
the series.)

If for some reason we needed better efficiency, it would
probably be a win to avoid using rationals inside the loop:
our approximation to e is 1/0! + ... + 1/m! = (m!/0!+m!/1!+...+m!/m!)/m!
and each term in the numerator is an integer, etc. We can
find all these terms without ever actually having to do any
division; start with 1 and multiply successively by m, m-1, ..., 1.
Doing this makes the aforementioned guaranteed-accuracy test
trickier.

> Ok, now we need the prime. It's only 10 digits, so a very simple test is 
> sufficient:
> 
> (defun is-prime (n)
>   (let ((root (truncate (sqrt n))))
>     (loop for i from 2 to root do
>           (when (= (mod n i) 0) (return-from is-prime nil))))
>   t)
> 
> (I don't like the "return-from", any better idea?)

    (defun is-prime (n)
      (loop for i from 2 to (truncate (sqrt n)) never (zerop (mod n i))))

-- 
Gareth McCaughan
.sig under construc
From: Steven E. Harris
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <jk47jpc416l.fsf@W003275.na.alarismed.com>
Frank Buss <··@frank-buss.de> writes:

> (defun is-prime (n)
>   (let ((root (truncate (sqrt n))))
>     (loop for i from 2 to root do
>           (when (= (mod n i) 0) (return-from is-prime nil))))
>   t)
>
> (I don't like the "return-from", any better idea?)

(defun is-prime (n)
  (loop for i from 2 to (truncate (sqrt n))
        never (zerop (mod n i))))


See CLHS Section 6.1.4, Termination Test Clauses.�


Footnotes: 
� http://www.lispworks.com/reference/HyperSpec/Body/06_ad.htm

-- 
Steven E. Harris
From: Paul Foley
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <m2u0sf8v5g.fsf@mycroft.actrix.gen.nz>
On Wed, 27 Oct 2004 08:42:58 -0700, Steven E Harris wrote:

> (defun is-prime (n)
>   (loop for i from 2 to (truncate (sqrt n))
>         never (zerop (mod n i))))

(= (truncate (sqrt n)) (isqrt n))

-- 
Being really good at C++ is like being really good at using rocks to
sharpen sticks.
                                                         -- Thant Tessman
(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Steven E. Harris
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <83r7njpm3f.fsf@torus.sehlabs.com>
Paul Foley <···@below.invalid> writes:

> (= (truncate (sqrt n)) (isqrt n))

Thanks, I had never noticed isqrt.
The more CL I learn, the more amazing it becomes.

-- 
Steven E. Harris
From: Alan Shutko
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <877jpbike7.fsf@wesley.springies.com>
Paul Foley <···@below.invalid> writes:

> (= (truncate (sqrt n)) (isqrt n))

Huh?

(cmucl 19a)
CL-USER> (= (truncate (sqrt 10))
	    (isqrt 10))
T
CL-USER> (= (truncate (sqrt 9))
	    (isqrt 9))
T



-- 
Alan Shutko <···@acm.org> - I am the rocks.
Just moving fast is not the same as getting somewhere.
From: FormerPerlHacker
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <slrnco1m6h.8kk.spambait@phoenix.clouddancer.com>
On Wed, 27 Oct 2004 22:36:32 -0500, <···@acm.org> wrote:
> Paul Foley <···@below.invalid> writes:
>
>> (= (truncate (sqrt n)) (isqrt n))
>
> Huh?
>
> (cmucl 19a)
> CL-USER> (= (truncate (sqrt 10))
> 	    (isqrt 10))
> T
> CL-USER> (= (truncate (sqrt 9))
> 	    (isqrt 9))
> T


19a seems to have a number of math errors, there was a discussion
about complex cosine on IRC the other day which showed another math
error.  I think I better drop back a version....


-- 
Brownian motion is correctly colored.
From: Frank Buss
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <clqnds$19f$1@newsreader2.netcologne.de>
FormerPerlHacker <········@CloudDancer.com> wrote:

> On Wed, 27 Oct 2004 22:36:32 -0500, <···@acm.org> wrote:
>> Paul Foley <···@below.invalid> writes:
>>
>>> (= (truncate (sqrt n)) (isqrt n))
>>
>> Huh?
>>
>> (cmucl 19a)
>> CL-USER> (= (truncate (sqrt 10))
>>          (isqrt 10))
>> T
>> CL-USER> (= (truncate (sqrt 9))
>>          (isqrt 9))
>> T
> 
> 
> 19a seems to have a number of math errors, there was a discussion
> about complex cosine on IRC the other day which showed another math
> error.  I think I better drop back a version....

this is not a math error. Paul means to use "(isqrt n)" instead of 
"(truncate (sqrt n))" within the is-prime function.

-- 
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: FormerPerlHacker
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <1099011152.N5HtdrUqkWVXsxDg+tpeJw@teranews>
On Thu, 28 Oct 2004 12:07:24 +0000 (UTC), <··@frank-buss.de> wrote:
> FormerPerlHacker <········@CloudDancer.com> wrote:
>> On Wed, 27 Oct 2004 22:36:32 -0500, <···@acm.org> wrote:
>>> Paul Foley <···@below.invalid> writes:
>>>
>>>> (= (truncate (sqrt n)) (isqrt n))
>>>
>>> Huh?
>>>
>> 
>> 19a seems to have a number of math errors, there was a discussion
>> about complex cosine on IRC the other day which showed another math
>> error.  I think I better drop back a version....
>
> this is not a math error. Paul means to use "(isqrt n)" instead of 
> "(truncate (sqrt n))" within the is-prime function.


Yes, I realized later that I had misread the code snippet.  But
acos(2) bothered me enough to drop back to 18e.


-- 
Brownian motion is correctly colored.
From: Bernd Beuster
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <clohrm$aob$1@online.de>
Frank Buss wrote:
> your calc-e function is inexact in the last digits and system:primep is 
> not a Common Lisp function.

Now, `primep' is fixed according to Steven E. Harris' code.

-- 
Bernd
From: FormerPerlHacker
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <slrnco1m01.8kk.spambait@phoenix.clouddancer.com>
On Wed, 27 Oct 2004 01:08:36 +0000 (UTC), <··@frank-buss.de> wrote:
>
> My version:
>
> (defun compute-e (n)
>   (let* ((len (truncate (/ (* 10 n) 4)))
>          (a (make-array len :initial-element 1 :element-type 'integer))
>          (digits (make-string n)))
>     (loop for j from 0 below n do
>           (let ((q 0))
>             (loop for i from (1- len) downto 1 do
>                   (let ((x (+ (* 10 (aref a i)) q)))
>                     (multiple-value-bind (div mod) (floor x (1+ i))
>                       (setf (aref a i) mod)
>                       (setf q div))))
>             (setf (elt digits j) (digit-char q))))
>     (concatenate 'string "2" digits)))
>
>
> (defun is-prime (n)
>   (let ((root (truncate (sqrt n))))
>     (loop for i from 2 to root do
>           (when (= (mod n i) 0) (return-from is-prime nil))))
>   t)
>
>
> (defun find-prime-10 (max-digits)
>   (let ((e (compute-e max-digits)))
>     (loop for i from 0 to (- max-digits 10) 
>           for check = (parse-integer (subseq e i (+ i 10)))
>           when (is-prime check) collect check)))
>
>
> And it is fast in LispWorks:
>
>> (time (find-prime-10 200))
> Timing the evaluation of (FIND-PRIME-10 200)
>
> user time    =      0.340
> system time  =      0.000
> Elapsed time =   0:00:00
> Allocation   = 182304 bytes standard / 3850 bytes conses
> 0 Page faults
> Calls to %EVAL    34
> (7427466391 7413596629 6059563073 3490763233 2988075319)
>


I've been reading c.l.l to learn Lisp in my spare time.  It's actually
working rather well, as I read a lot of interesting threads that lead
to useful reading and experiments.  In this case, I'm puzzled by the
execution differences in CMUCL 19a on a dual Pentium4 XeonHT running
Gentoo Linux.  I get:

(time (find-prime-10 200))
; Compiling LAMBDA NIL: 
; Compiling Top-Level Form: 

; Evaluation took:
;   3.58 seconds of real time
;   3.418481 seconds of user run time
;   0.118982 seconds of system run time
;   9,553,346,168 CPU cycles
;   [Run times include 0.14 seconds GC run time]
;   0 page faults and
;   64,797,928 bytes consed.


Why the big difference?


-- 
Brownian motion is correctly colored.
From: Edi Weitz
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <uekjjm5h2.fsf@agharta.de>
On Thu, 28 Oct 2004 11:29:05 GMT, FormerPerlHacker <········@CloudDancer.com> wrote:

> I've been reading c.l.l to learn Lisp in my spare time.  It's
> actually working rather well, as I read a lot of interesting threads
> that lead to useful reading and experiments.  In this case, I'm
> puzzled by the execution differences in CMUCL 19a on a dual Pentium4
> XeonHT running Gentoo Linux.  I get:
>
> (time (find-prime-10 200))
> ; Compiling LAMBDA NIL: 
> ; Compiling Top-Level Form: 
>
> ; Evaluation took:
> ;   3.58 seconds of real time
> ;   3.418481 seconds of user run time
> ;   0.118982 seconds of system run time
> ;   9,553,346,168 CPU cycles
> ;   [Run times include 0.14 seconds GC run time]
> ;   0 page faults and
> ;   64,797,928 bytes consed.
>
>
> Why the big difference?

A common newbie mistake is to forget to compile the functions... :)

Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Gareth McCaughan
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <87fz412c24.fsf@g.mccaughan.ntlworld.com>
Eric Smith wrote:

> I saw a news story this morning with the headline "Google Working to
> Recruit Brainy Elite."
> 
> The story mentioned anonymous billboards that read "(first 10-digit
> prime found in consecutive digits of e).com"
...
> What I'm wondering is whether Google actually hired people based on
> such puzzles.  Or was it just a recruiting stunt whose only purpose
> was to increase the number of resumes they received, and then filter
> those exactly the same way as all the rest?

I've been assuming that these advertisements (and likewise
the more recent "Google Labs Aptitude Test") are not aimed
primarily at potential recruits, but at potential users and
investors; they send the message "Google employs really
clever people, so they must be a hotbed of productivity
and innovation".

> It seems to me that if this kind of puzzle solving actually gets
> anyone hired, and turns out to be a successful way to get good
> employees, other companies might do the same thing, and it might
> become much more common.  In that case, those who use Lisp would have
> a big advantage, because of how good it is for solving such puzzles.
> So even if we can't get Lisp jobs, we might get good jobs because of
> Lisp.
> 
> Getting a good job normally requires a lot of incidental skills.  You
> need good interview skills, etc.  Technical ability usually takes a
> back seat to such things.  But if some companies actually start hiring
> on the basis of puzzle solving ability, it could change that.  I bet
> there are huge numbers of Lisp users who aren't very good at getting
> jobs, who might end up getting much better jobs than in the past if
> this becomes a trend.  But will it?

There is at least one other company that is -- at least ostensibly --
hiring on the basis of problem-solving skills. It's called ITA,
and they do a lot of Lisp. :-)

-- 
Gareth McCaughan
.sig under construc
From: Dan Pierson
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <2b5834f8.0410270617.7cceb729@posting.google.com>
Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...

> There is at least one other company that is -- at least ostensibly --
> hiring on the basis of problem-solving skills. It's called ITA,
> and they do a lot of Lisp. :-)

Yes, a good solution will get you to the phone screen stage.  We don't
care if you do it with Lisp or not :-)

Dan Pierson, ITA Software
From: Jon Boone
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <m3fz40ndce.fsf@spiritus.delamancha.org>
Gareth McCaughan <················@pobox.com> writes:

> There is at least one other company that is -- at least ostensibly --
> hiring on the basis of problem-solving skills. It's called ITA,
> and they do a lot of Lisp. :-)

    ISTR that back in the late 1980s/early 1990s [when a lot of my
  friends started working at Microsoft] that one component of the
  interview process was being asked to solve a problem in a relatively
  short time frame.  The point wasn't to see if you got a right answer
  or not [though those were most welcome], but rather to see what
  thinking process you used to solve the problem.

  --jon
From: Gareth McCaughan
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <87fz3z23lk.fsf@g.mccaughan.ntlworld.com>
Jon Boone <········@delamancha.org> writes:

> Gareth McCaughan <················@pobox.com> writes:
> 
> > There is at least one other company that is -- at least ostensibly --
> > hiring on the basis of problem-solving skills. It's called ITA,
> > and they do a lot of Lisp. :-)
> 
>     ISTR that back in the late 1980s/early 1990s [when a lot of my
>   friends started working at Microsoft] that one component of the
>   interview process was being asked to solve a problem in a relatively
>   short time frame.  The point wasn't to see if you got a right answer
>   or not [though those were most welcome], but rather to see what
>   thinking process you used to solve the problem.

Oh yes, that's very common in interviews. (I like to do something
of the sort to people who interview at the company where I work.)
But usually those are rather easier problems than the ones that
Google and ITA are using, and you have an order of magnitude (or
two) less time to attack them.

-- 
Gareth McCaughan
.sig under construc
From: Peter Santoro
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <3DNfd.33575$OD2.1131@bgtnsc05-news.ops.worldnet.att.net>
Eric Smith wrote:
> What I'm wondering is whether Google actually hired people based on
> such puzzles.  Or was it just a recruiting stunt whose only purpose
> was to increase the number of resumes they received, and then filter
> those exactly the same way as all the rest?

I used scheme to solve the google puzzle in the August 2004 issue of 
Linux Journal and submitted my result with no resume.  I was informed 
that the answer was correct and I was asked to submit my transcripts or 
resume.  After submitting my resume, I was sent a standard rejection 
notice.  It is interesting to note that they were more than willing to 
consider me as a potential hire, even if I was a still a student. 
Apparently, having multiple M.S. degrees AND years of varied real world 
experience is not good enough to get you a google interview.  I can 
accept that.

I did ask for feedback, so that I could improve my presentation to other 
firms in the future, but was blown off by two google recruiters.  I 
found the google recruiters to be rude and unprofessional.  Based on my 
experience and the reports of other experienced (older?) people, it 
appears that google has a preference for hiring younger mathematics PhD 
candidates/holders.  In addition, google recently announced that they 
were opening a new development center in India.

I think that moving to India will probably improve your employment 
opportunities with google more than using lisp to solve one of their 
puzzles.


Peter
From: Emre Sevinc
Subject: Re: Employment puzzles and Lisp
Date: 
Message-ID: <87bren4fzc.fsf@bilgi.edu.tr>
Peter Santoro <········@att.net> writes:

> Eric Smith wrote:
>> What I'm wondering is whether Google actually hired people based on
>> such puzzles.  Or was it just a recruiting stunt whose only purpose
>> was to increase the number of resumes they received, and then filter
>> those exactly the same way as all the rest?
>
> I used scheme to solve the google puzzle in the August 2004 issue of
> Linux Journal and submitted my result with no resume.  I was informed
> that the answer was correct and I was asked to submit my transcripts
> or resume.  After submitting my resume, I was sent a standard
> rejection notice.  It is interesting to note that they were more than
> willing to consider me as a potential hire, even if I was a still a
> student. Apparently, having multiple M.S. degrees AND years of varied
> real world experience is not good enough to get you a google
> interview.  I can accept that.
>
> I did ask for feedback, so that I could improve my presentation to
> other firms in the future, but was blown off by two google recruiters.
> I found the google recruiters to be rude and unprofessional.  Based on
> my experience and the reports of other experienced (older?) people, it
> appears that google has a preference for hiring younger mathematics
> PhD candidates/holders.  In addition, google recently announced that
> they were opening a new development center in India.

I've seen some Google puzzles published in recent issues of 
Dr. Dobb's Journal (one of them being quite puzzling, a kind of question
that I think has got nothing to do with a programmatic solution
but rather finding the relationship among a few numbers, well, I don't
know if the big yellow columns of the covered car parking lot which
those numbers were printed on had anything to do with the solution! ;-). 

As far as I know those solve-this-puzzle-and-send-with-your-CV
ads were for Google Labs, not Google Inc. Because the same company
had another ad in the same DDJ issue, it was much smaller, did not
draw much attention and no fancy graphics. The sign under the ad
was Google Inc. (not Google Labs) and it targeted people with 
at least a Ph.D. in computer science (and solid research experience,
having written articles that were published in journals, etc. were
required).

So I assume that, like Microsoft R&D, Bell Labs, etc. Google Labs
and Google Inc. have very different strategies and working conditions,
of course that's just an assumption and I'd like to be enlightened
by people who have first hand information about the issue.


-- 
Emre Sevinc

eMBA Software Developer
Istanbul Bilgi University
http://www.bilgi.edu.tr
http://www.bilgiemba.net

Cognitive Science Student
http://www.cogsci.boun.edu.tr

Actively engaged in:
http://ileriseviye.org -- Advanced level technical articles
http://fazlamesai.net  -- /. style geek & nerd site in Turkish (better than /.)
http://cazci.com       -- All about jazz