From: Rob Biedenharn Date: 2007-06-05T23:29:34+09:00 Subject: Re: FizzBuzz (#126) On Jun 5, 2007, at 9:04 AM, Robert Dober wrote: > On 6/5/07, Paul Novak wrote: >> On Jun 5, 6:01 am, "spoo...@gmail.com" wrote: >> > I disagree. I challenged several of my coworkers to solve >> FizzBuzz a >> > few weeks ago. All of the solutions were pretty much the same >> except >> > the one from our lead DBA. He solved the problem in a stored >> > procedure without using a cursor. It was exceptionally clever and >> > totally horrific at the same time. We gave him the "Most >> > Inappropriate Use of Set Theory" award. >> > >> > On Jun 1, 10:08 am, Paul Novak wrote: >> > > I do not think there is a lot of room for cleverness in the >> FizzBuzz >> > > problem. (Actually, I hope I am wrong and we see lots more >> > > suggestions for Extra Fun like Peter's.) My understanding is >> that >> > > FizzBuzz was intended to screen out candidates that could >> *not* come >> > > up with working code in a few minutes. >> > >> > > Regards, >> > >> > > Paul. >> >> As the last few days have shown, there *are* clever ways of solving >> FizzBuzz. However, IMHO, there are very few that would be >> appropriate >> for the stated scenario of a job interview. >> >> My tendency would be to create the simplest thing that could possibly >> work in clear and readable and maintainable code. After all, >> employers want someone who is smart, but also want someone who gets >> things done efficiently. Possibly, with just the right >> interviewer, I >> might discus various solutions pros and cons, which might be >> optimized >> for particular scenarios, etc. >> >> Maybe I just haven't interviewed the right sort of employers that >> would appreciate such creativity... >> >> Regards, >> >> Paul. > > Actually I feel that somehow - sorry I have said this before, but I am > not sure it was heard ;) - this is about a job, yes but with R u b y. > And if I were to hire a Ruby programmer and the guy just writes some > Java/C/Perl/OCaml or whatever code, expressed in Ruby, will I take > him? > > So whatever is said about simple and maintainable and psychological > impact for sure is clever stuff coming from experience I am lacking. > But many of you are forgetting the R u b y part nonetheless. > > Cheers > Robert > > -- > You see things; and you say Why? > But I dream things that never were; and I say Why not? > -- George Bernard Shaw Regardless of how simple or clever the code, if it isn't syntactically correct or fails to use common Ruby idioms, it fails as an interview response. i=1; while i <= 100; ...; i += 1; end # BZZZT! Sorry, thanks for playing. 1.upto(100) do |i| ... end # DING! (1..100).each {|i| ... } # DING! Any more than one bug and I'd say the interview was over (and ANY bug if actually using irb or ruby to run the code would be too many). The exact format of the output wasn't rigorously defined so I'd expect a reasonable interpretation (unless the solution offered couldn't be simply and obviously changed to add/remove spacing, newlines, quotes, capitalization, etc.). If I were giving this test, extra credit would be earned for knowing that i%15 == 0 is equivalent to (i%3==0 && i%5==0) because I can't imagine a programmer being very good without a firm grasp of some math as basic as this. If the interviewee immediately starting golfing, that'd lose credit, but noticing simple, incremental improvement would be positive. For example, noticing the use of case..end's value as an expression: case when i%15 == 0 puts "FizzBuzz" when i%3 == 0 puts ... becoming: puts case when i%15 == 0 : "FizzBuzz" when i%3 == 0 : ... Overall, the volume of responses to the quiz is interesting only when it doesn't degrade to golfing. (My own straight-forward solution incrementally shrinks down to 69 bytes, but I have no interest in squeezing it any more -- it wouldn't be readable -- and anyone who used the ?d == 100 trick in an interview should be shown the door!) -Rob Rob Biedenharn http://agileconsultingllc.com Rob@AgileConsultingLLC.com