Skal vi kode 'Bum' til jobsamtalen?

1. februar 2017 kl. 05:1231
FizzBuzz er en simpel test af en programmørs grundlæggende færdigheder, men kan også afsløre rutinerede programmørers skavanker.
person
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.
person

Det skulle efter sigende være svært at finde nok uddannede programmører til at imødekomme efterspørgslen. Derfor er det nærliggende at prøve at rekruttere dem, der ikke har et eksamensbevis, men er selvlærte og har talent.

Men hvordan finder man ud af, om sådan en selvlært programmør kan kode?

Især i USA kan en begynderstilling som juniorudvikler være særdeles velbetalt i forhold til de fleste andre jobs. Derfor er det oplagt, at der vil være folk helt uden færdigheder, som prøver at få foden indenfor.

I 2007 foreslog en britisk softwareudvikler en simpel test. En ansøger skulle demonstrere sine programmeringsfærdigheder ved at skrive et program med inspiration fra børnelegen 'Bum', eller på engelsk 'FizzBuzz'.

Artiklen fortsætter efter annoncen

Bum er en leg i skolen, som bruges til at lære om multiplikation og division. Man vælger eksempelvis 3-tabellen, og man skiftes derefter til at tælle op fra 1, og hver gang man kommer til et tal, som 3 går op i, siger man 'bum' i stedet for tallet. Man kan øge sværhedsgraden ved at have flere tabeller i spil på samme tid.

Den oprindelige formulering af spørgsmålet til jobansøgeren lød:

Write a program that prints the numbers from 1 to 100. But for multiples of three print 'Fizz' instead of the number and for the multiples of five print 'Buzz'. For numbers which are multiples of both three and five print 'FizzBuzz'.

Det er en meget enkel øvelse, der lettest løses med en for-løkke og tre if-statements, og samtidig kan vise, at udvikleren kender til modulus og har sin grundlæggende algebra på plads.

  1. function FizzBuzz() {
  2.     for (i = 1; i <= 100; i++) {
  3.         if (i % 3 == 0 && i % 5 == 0) {
  4.             console.log("FizzBuzz");
  5.         }
  6.         else if (i % 3 == 0 && i % 5 != 0) {
  7.             console.log("Fizz");
  8.         }
  9.         else if (i % 3 != 0 && i % 5 == 0) {
  10.             console.log("Buzz");
  11.         }
  12.         else {
  13.             console.log(i);
  14.         }
  15.     }
  16. }

Men det er også en øvelse, som let kan få øvede programmører til at falde i en fælde, hvor de ganske vist løser opgaven, men gør det på en måde, der ikke er hensigtsmæssig i alle udviklerjob.

Artiklen fortsætter efter annoncen

Jobs

Dine job
Vis alle

På denne side kan man finde forskellige løsninger af FizzBuzz. De er interessante, fordi de viser forskelle mellem programmeringssprog, men de viser også problemer med at skrive brugbar og især læsbar kode.

Eksempelvis er det muligt at lave et enkelt check på modulus 15 i stedet for både at tjekke modulus 3 og modulus 5. Det virker som en god idé at løse opgaven på denne måde, fordi man kan fjerne et check, og man viser matematisk forståelse.

Men det er også en løsning, som øger afstanden mellem den oprindelige kravspecifikation og koden.

Sammenhængen mellem 3, 5 og 15 er ikke umiddelbar uden en kommentar i koden. Den enkle, ligefremme løsning indeholder et ekstra check, men er til gengæld en direkte oversættelse af kravene.

Er Fizz + Buzz det samme som FizzBuzz?

Der er også flere eksempler på, hvordan FizzBuzz kan løses i en enkelt kodelinje, eller ved at tjekke længden af en streng i stedet for at tjekke selve tallet. Det fører igen til kode, der fjerner sig fra beskrivelsen af problemet.

Artiklen fortsætter efter annoncen

To eksempler i Python hentet fra linket oven for:

  1. python -c "print '\n'.join(['Fizz'*(x % 3 == 2) + 'Buzz'*(x % 5 == 4) or str(x + 1) for x in range(100)])"
  2. #
  3. # Eller:
  4. #
  5. for i in xrange(0,101):
  6.     s = ""
  7.     if i % 3 == 0: s += "Fizz"
  8.     if i % 5 == 0: s += "Buzz"
  9.     print s if len(s) else i

Løsninger, hvor man opbygger en streng ved at tilføje eventuelt tomme strenge for hvert tjek, gør sig desuden skyldige i at antage, at 'Fizz' + 'Buzz' er det samme som 'FizzBuzz'. Det giver et korrekt output i den konkrete opgave, men udvikleren har fortolket opgaven for at kunne lave en bestemt løsning og dermed introduceret en potentiel fejlkilde.

Hvad er kravene - og hvad er optimering?

Kompakt kode kan være en elegant øvelse, men langt det meste kode, en udvikler skal skrive, skal blot opfylde de udstukne specifikationer og være til at teste og vedligeholde. Her kan det være væsentligt at prioritere læsbarhed højt.

Som udvikler bør man derfor være bevidst om opgaven. Hvis opgaven i stedet gik ud på, at man fik udleveret en FizzBuzz-implementering og blev bedt om at gøre den mere effektiv, så ville det være en god løsning at reducere antallet af check.

I min simple implementering ville det eksempelvis være en god optimering at starte med at ændre koden, så det hyppigst forekommende udfald er det, der bliver tjekket for først, hver gang løkken gennemløbes.

  1. function FastFizzBuzz() {
  2.     for (i = 1; i <= 100; i++) {
  3.         if (i % 3 != 0 && i % 5 != 0) {
  4.             console.log(i);
  5.         }
  6.         else if (i % 3 == 0 && i % 5 != 0) {
  7.             console.log("Fizz");
  8.         }
  9.         else if (i % 3 != 0 && i % 5 == 0) {
  10.             console.log("Buzz");
  11.         }
  12.         else {
  13.             console.log("FizzBuzz");
  14.         }
  15.     }
  16. }

En optimering bør ikke måles i antal kodelinjer, men snarere i forhold til hvordan koden gennemløbes, da det er dét, der vil give en reel forbedring.

Hvordan skal outputtet printes?

I den oprindelige formulering af FizzBuzz-spørgsmålet er der så et lille problem, som en dygtig udvikler i det mindste burde påpege. Outputtet er blot defineret som at printe tal og tekst, men det er ikke klart specificeret, hvordan det skal gøres.

Der er således forskellige løsninger, hvor outputtet printes som:

  1. 1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz ...
  2. // Eller:
  3. 12Fizz4BuzzFizz78FizzBuzz ...
  4. // Eller:
  5. 1
  6. 2
  7. Fizz
  8. 4
  9. Buzz
  10. Fizz
  11. 7
  12. 8
  13. Fizz
  14. Buzz
  15. ...

Alle er gyldige løsninger, men de er også forskellige output. En god programmør burde bemærke i sit svar, at formatet for outputtet ikke er nærmere specificeret.

Bum-legen er ganske vist kun beregnet til at sikre sig, at en jobansøger kan finde ud af for-løkker og if-statements, men der ligger også en implicit test af ansøgerens evne til at fokusere på den givne opgave og være bevidst om sin fortolkning af de krav, opgaven definerer.

Softwareudvikling handler nemlig ikke kun om algoritmer. For mange er det en vigtigere del af arbejdet at kunne tage en beskrivelse af en arbejdsproces og omsætte den til funktioner, der korrekt udfører processen i programmet hver gang.

Så spørgsmålet er, om en test som FizzBuzz er egnet til at teste en uøvet programmørs evner, eller om der er andre egenskaber end simpelt algoritmedesign, der faktisk er vigtigere at teste for, inden man sætter en programmør foran tasterne.

31 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
31
Theis Blickfeldt
22. marts 2017 kl. 16:06

Man skal også huske, at man skal skille sig ud fra mængden, hvis man vil gøre sig forhåbninger om at få jobbet :D

  1. # Calculate CrossSum of a number:
  2. def cross_sum(number):
  3. 	number_string = str(number);
  4. 	number_length = len(number_string);
  5. 	crosssum = 0;
  6. 	for digits in range(0, number_length):
  7. 		crosssum += int((number_string[digits]));
  8. 	# Make recursive function-call if calculated crosssum still consists of multiple digits.
  9. 	if(len(str(crosssum)) > 1):
  10. 		crosssum = cross_sum(crosssum);
  11. 	return crosssum;
  12.  
  13. # Executeable Script:
  14. #---------------------------------
  15. def main(argv):
  16. 	for i in range(1, 100 + 1):
  17. 		number_string = str(i);
  18. 		print_string = number_string;
  19. 		FizzBuzz_Control_Cntr = 0;
  20.  
  21. 		# Check if number is divisible by 3:
  22. 		number_crosssum = cross_sum(i);
  23. 		if((number_crosssum == 3) or (number_crosssum == 6) or (number_crosssum == 9)):
  24. 			print_string = "Fizz";
  25. 			FizzBuzz_Control_Cntr += 1;
  26.  
  27. 		# Check if number is divisible by 5:
  28. 		last_digit = int((number_string[len(number_string) - 1]));
  29. 		if((last_digit == 0) or (last_digit == 5)):
  30. 			print_string = "Buzz";
  31. 			FizzBuzz_Control_Cntr += 1;
  32.  
  33. 		# Yield correct response to number:
  34. 		if(FizzBuzz_Control_Cntr == 2):
  35. 			print("FizzBuzz");
  36. 		else:
  37. 			print(print_string);
  38. 	# Goodbye...
  39. 	exit();

  • more_vert
    • insert_linkKopier link
30
Mads T. Jensen
6. marts 2017 kl. 12:31

Se mor, uden hænder:

  1. function FastFizzBuzz() {
  2.     for (i = 1, i3=1, i5=1; i <= 100; i++, i3++, i5++) 
  3.     {
  4.         if (i3==3)i3=0;
  5.         if (i5==5)i5=0;
  6.  
  7.         if (i3)
  8.         {
  9.             if (i5)
  10.                 console.log(i);
  11.             else
  12.                 console.log("Buzz");
  13.         }
  14.         else{
  15.             if (i5)
  16.                 console.log("Fizz");
  17.             else
  18.                 console.log("FizzBuzz");
  19.         }
  20.     }
  21. }

  • more_vert
    • insert_linkKopier link
29
Mads T. Jensen
6. marts 2017 kl. 12:25

Det der tager tid er modulus. Det er ikke hvor mange ifsætninger eller sammenligner der skal fyres af. Søren B Simonsens svar er 100% korrekt, ligesom det jeg har kogt op her;

  1. function FastFizzBuzz() {
  2.     for (i = 1; i <= 100; i++) {
  3.         if (i % 3) 
  4.         {
  5.             if (i % 5) 
  6.                 console.log(i);
  7.             else
  8.                 console.log("Buzz");
  9.         }
  10.         else
  11.         {
  12.             if (i % 5) 
  13.                 console.log("Fizz");
  14.             else
  15.                 console.log("FizzBuzz");
  16.         }
  17.     }
  18. }

og hvis man vil fjerne de 1-2 modulus pr. iteration, så lav to ekstra counters, der tæller op og en if-sætning der sætter dem til 0 ved henholdsvis 3 og 5. Det er ikke svære end det.

  • more_vert
    • insert_linkKopier link
28
Søren B. Simonsen
5. februar 2017 kl. 20:14

Eller bare med if og stadig med to kun modulus per tal, de fleste andre løsninger har mindst to modulus og er dermed langsommere

function FasterFizzBuzz() { for (i = 1; i <= 100; i++) { if (i % 3 == 0 ) { if (i % 5 == 0 ) { console.log("FizzBuzz"); } else { console.log("Fizz"); } } else { if (i % 5 == 0 ) { console.log("Buzz"); } else { console.log(i); } } } }

  • more_vert
    • insert_linkKopier link
27
Peter Riise
3. februar 2017 kl. 12:26

Jeg benytter også altid en kode opgave under interviews. Vi har også benyttet FizzBizz. Men det kan sagtens være at den grundlæggende opgave kan være den samme, hvor man så beder kandidaten om at vise sine kundskaber på specifikke områder, f.eks. TDD/DI/IoC m.v.

Jeg er også enig i at det har meget stor værdi at se kandidaten arbejde, da det også kan give værdifulde informationer om arbejdsmetoder og tempo.

  • more_vert
    • insert_linkKopier link
26
Slettet bruger
2. februar 2017 kl. 15:04

Jeg synes den her Swift-løsning er ret elegant:

  1.     for value in 0...100 {
  2.           switch (value % 3, value % 5) {
  3.                case (0,0): print ("FizzBuzz")
  4.                case (0,<em>): print ("Fizz")
  5.                case (</em>,0): print ("Buzz")
  6.                default: print String(value)
  7.         }
  8.     }

  • more_vert
    • insert_linkKopier link
25
Troels Tolstrup
2. februar 2017 kl. 14:11

Hvem har så trivielle opgaver at det giver nogen form for mening og se om de kan løse så simpel en "udfordring"? Problemstillingen og løsningen er så basal, at jeg ikke engang kan se hvordan den giver mulighed for videre teknisk diskussion. (Med mindre løsningen skulle ende i en kaliber som den linket til af Peter Makholm, det ville være awesome) Hvis vi snakker helt grønne kandidater uden nogen form for relevant uddannelse så kan jeg måske se ideen.

Jeg vil meget hellere finde relevante tekniske emner at diskutere baseret på den pågældende kandidats erfaring, men det kan man selvfølgelig ikke sætte en tilfældig HR konsulent til.

  • more_vert
    • insert_linkKopier link
23
Baldur Norddahl
1. februar 2017 kl. 23:05

Jeg er ikke meget bekendt med Scala, men ud fra din kode går jeg ud fra at dit array bliver gennemløbet tre gange

God pointe, der skal indføres et .view således:

  1. (1 to 100).view.  
  2.     map(n => if (n % 15 == 0) Left("FizzBuzz") else Right(n)).  
  3.     map(<em>.right.flatMap(n => if (n % 3 == 0) Left("Fizz") else Right(n))).  
  4.     map(</em>.right.flatMap(n => if (n % 5 == 0) Left("Buzz") else Right(n))).  
  5.     foreach(n => println(n.fold(identity,_.toString)))

Forskellen er at et view er lazy så beregningen bliver først gennemført ved kaldet til foreach. På intet tidspunkt vil der eksistere et array eller liste med mellemresultater.

hvad er fordelen der ift. et enkelt map med en lambda med en conditional? Er det bare en personlig præference/læsbarhed, ift. følgende?

Der er ikke nogen fordele ved at skrive kode som jeg gjorde. Det var bare for at lave noget andet end det mest åbenlyse:

  1. for(n <- 1 to 100)
  2.   println(if (n%15==0) "FizzBuzz" else if (n%3==0) "Fizz" else if (n%5==0) "Buzz" else n)

Pattern matching versionen ser således ud i Scala:

  1. for(n <- 1 to 100) println(n match {
  2.     case n if n%15==0 => "FizzBuzz"
  3.     case n if n%3==0 => "Fizz"
  4.     case n if n%5==0 => "Buzz"
  5.     case n => n
  6.   })

Eller hvad med:

  1. def fizz(n: Int) = if (n%3==0) "Fizz" else ""
  2. def buzz(n: Int) = if (n%5==0) "Buzz" else ""
  3. def number(n: Int, str: String) = if (str=="") n else str
  4. for(n <- 1 to 100) println(number(n,fizz(n)+buzz(n)))

  • more_vert
    • insert_linkKopier link
21
Rune Juhl Jacobsen
1. februar 2017 kl. 20:24

Pattern matching med guards i Erlang er nok noget af det pæneste det kan blive til:

  1. -module(fizzbuzz).
  2. -compile(export_all).
  3.  
  4. fizzbuzz(X) when X rem 15 =:= 0 ->
  5.     "FizzBuzz";
  6. fizzbuzz(X) when X rem 3 =:= 0 ->
  7.     "Fizz";
  8. fizzbuzz(X) when X rem 5 =:= 0 ->
  9.     "Buzz";
  10. fizzbuzz(X) -> X.
  11.  
  12. run() ->
  13.     L = lists:seq(1, 100),
  14.     io:fwrite("~p~n", [lists:map(fun fizzbuzz:fizzbuzz/1, L)]).

(kør den som erlc fizzbuzz.erl && erl -pa . -run fizzbuzz run -run init stop -noshell)

...men min løsning i Clojure er ganske læsbar:

[scheme] (clojure.string/join " " (take 100 (map #(cond (zero? (+ (mod % 3) (mod % 5))) "FizzBuzz" (zero? (mod % 3)) "Fizz" (zero? (mod % 5)) "Buzz" :else %) (iterate inc 1)))) [/scheme]

Jeg er ikke meget bekendt med Scala, men ud fra din kode går jeg ud fra at dit array bliver gennemløbet tre gange; hvad er fordelen der ift. et enkelt map med en lambda med en conditional? Er det bare en personlig præference/læsbarhed, ift. følgende?

  1. (1 to 100).
  2.   map(n =>
  3.     if (n % 15 == 0)
  4.       Left("FizzBuzz")
  5.     else if (n % 3 == 0) Left("Fizz")
  6.     else if (n % 5 == 0) Left("Buzz")
  7.     else Right(n)).
  8.   foreach(n => println(n.fold(identity,_.toString)))

  • more_vert
    • insert_linkKopier link
20
Kim Madsen
1. februar 2017 kl. 16:16

som kun laver bit manipulation:

  1. const s:array[0..3] of string = ('','Fizz','Buzz','FizzBuzz');
  2. var
  3.   a,c,i:integer;
  4. begin
  5.    a:=$30490610;
  6.    c:=0;
  7.    for i:=1 to 100 do
  8.    begin
  9.         c:=a AND $3;
  10.         a:=(a SHR 2) OR (c SHL 28);
  11.  
  12.         if c=0 then
  13.            writeln IntToStr(i)
  14.         else
  15.            writeln s[c];
  16.    end;
  17. end;

mvh Kim Bo

  • more_vert
    • insert_linkKopier link
19
Brian Vraamark
1. februar 2017 kl. 16:05

Min kode kan i øvrigt reduceres lidt mere, da der ikke nogen er grund til !=5 og != 3, når der kun er to tal vi tester på (desværre tester man på 3 to gange hvor den ikke er det):

  1. int three=1,five=1;  
  2.     for (int i = 1; i <= 100; i++) {  
  3.         if (three==3 && five==5) {  
  4.              cout << "FizzBuzz";  
  5.              three=0;  
  6.              five=0;  
  7.         }  
  8.         else if (three==3) {  
  9.              cout << "Fizz";  
  10.              three=0;  
  11.         }  
  12.         else if (five==5) {  
  13.              cout << "Buzz";  
  14.              five=0;  
  15.         }  
  16.         else {  
  17.              cout << i;  
  18.         }  
  19.         three++;  
  20.         five++;          
  21.     }

  • more_vert
    • insert_linkKopier link
18
Brian Vraamark
1. februar 2017 kl. 15:40

Det kan også være at ansøgeren slet ikke vil bruge modulus og optimere performance lidt mere. Modsat Kims er den ikke afhængig af lookup og fungerer derfor med et hvilket som helst interval. ;)

Følgende benytter ikke modulus (division for at få resten, da det er den måde modulus ofte er implementeret). Alle tal øges kun med 1, derfor benyttes der ikke ADD, men INC (hvis compileren optimere korrekt) som er hurtigere.

Har det betydning på en i7 - næ, men måske på en langsom RFID læser.

  1.     int three=1,five=1;
  2.     for (int i = 1; i <= 100; i++) {
  3.         if (three==3 && five==5) {
  4.              cout << "FizzBuzz";
  5.              three=0;
  6.              five=0;
  7.         }
  8.         else if (three==3 && five!=5) {
  9.              cout << "Fizz";
  10.              three=0;
  11.         }
  12.         else if (three!=3 && five==5) {
  13.              cout << "Buzz";
  14.              five=0;
  15.         }
  16.         else {
  17.              cout << i;
  18.         }
  19.         three++;
  20.         five++;        
  21.     }

  • more_vert
    • insert_linkKopier link
17
Kim Madsen
1. februar 2017 kl. 15:11

Og med de ubehagelige fejl der af og til optræder i CPU'er mener jeg at man helt bør undgå modulus (og dermed division), og holde sig til simple lookup som selv den mest tåbelige CPU næsten ikke kan fejle på ;)

  1. const a:array[1..100] of integer = (
  2.       0,0,1,0,2,1,0,0,1,2,0,1,0,0,3,0,0,1,0,2,
  3.       1,0,0,1,2,0,1,0,0,3,0,0,1,0,2,1,0,0,1,2,
  4.       0,1,0,0,3,0,0,1,0,2,1,0,0,1,2,0,1,0,0,3,
  5.       0,0,1,0,2,1,0,0,1,2,0,1,0,0,3,0,0,1,0,2,
  6.       1,0,0,1,2,0,1,0,0,3,0,0,1,0,2,1,0,0,1,2
  7.       );
  8. const s:array[0..3] of string = (
  9.       '','Fizz','Buzz','FizzBuzz'
  10.       );
  11.  
  12. for i:=low(a) to high(a) do
  13. begin
  14.      if s[a[i]]='' then
  15.         writeln(i)
  16.      else
  17.          writeln(s[a[i]]);
  18. end;

mvh Kim Bo

  • more_vert
    • insert_linkKopier link
16
Esben Thorving Bjerregaard
1. februar 2017 kl. 14:59

Vi får ALLE kandidater til at lave en simpel opgave.

Nogle gange FizzBuzz nogle gange noget andet.

Pointen er at se hvordan kandidaten løser opgaven. Opgaven skal være så simpel at alle kan løse den og løse den hurtigt. Det handler ikke så meget om, om syntaksen er 100% spot on. Det handler meget mere om hvordan kandidaten går til opgaven. Og det er bestemt ikke spild af tid - hvis en kandidat ikke brænder for at vise egne codeskills er kandidaten og vores virksomhed ikke et godt match anyway

Joel har mange gode pointer om job interviews her https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/B.la. "Most of the time in the interview, though, should be spent letting the candidate prove that they can write code."

  • more_vert
    • insert_linkKopier link
15
Baldur Norddahl
1. februar 2017 kl. 14:57

  1. (1 to 100).
  2.   map(n => if (n % 15 == 0) Left("FizzBuzz") else Right(n)).
  3.   map(<em>.right.flatMap(n => if (n % 3 == 0) Left("Fizz") else Right(n))).
  4.   map(</em>.right.flatMap(n => if (n % 5 == 0) Left("Buzz") else Right(n))).
  5.   foreach(n => println(n.fold(identity,_.toString)))

hvorfor gøre det sværere end det behøver være? :-)

  • more_vert
    • insert_linkKopier link
14
Peter Bryde
1. februar 2017 kl. 14:40

Lidt fesen opgave at stille til en jobsamtale efter min mening. Bedre ville det være at have gennemgået ansøgers github på forhånd, inden han blev udtaget til interview og på den baggrund komme med afklarende kompetence spørgsmål.

  • more_vert
    • insert_linkKopier link
13
Kim Madsen
1. februar 2017 kl. 14:37

Argh... jeg har overperformet i mit løsningsforslag....

Jeg burde jo kun have lavet en løsning fra 1 til 100... og lavede en fra 1 til 1000... binært... så den rigtige og langt nemmeste løsning at forstå, hvor det er meget svært at lave kode fejl, og som kan afvikles på selv den mest ydmyge lommeregner eller for den sags skyld... regnestok er:

print 1,2,"Fizz",4

Det er jo en ren snyde opgave da hverken "Buzz" eller "FizzBuzz" nogensinde kommer i brug... ;)

mvh Kim Bo

  • more_vert
    • insert_linkKopier link
12
Kim Madsen
1. februar 2017 kl. 14:20

Fra 1 til 100 binært... det er jo fra 1 til 8. Så den simpleste og bedst performante løsning er:

print 1,2,"Fizz",4,"Buzz","Fizz",7,8

  • more_vert
    • insert_linkKopier link
11
Anders Clausen
1. februar 2017 kl. 13:50

@Morten: Deraf min kommentar om, at løsningen rent funktionelt er elegant :)

@Povl: Funktionelt er din løsning meget elegant - som nævnt. Men din sidste regel, "Deles med 3 og 5, så begge ovenstående.", ligger implicit i koden. Det kan potentielt give problemer, uanfægtet af, at det gør din kode mere effektiv. Eksempelvis kunne en programmør fejlagtigt antage mutual exclusion. Det er et klassisk trade-off mellem performance (og subjektivt, funktionel elegance) og maintainability.

  • more_vert
    • insert_linkKopier link
10
Jens Melgaard
1. februar 2017 kl. 13:47

""Den enkle, ligefremme løsning indeholder et ekstra check, men er til gengæld en direkte oversættelse af kravene.""

Hvis man rent faktisk er så god til at formulere krav i realiteten, så var det nok langt billigere at sende opgaven til Indien (eller tilsvarende sted).

Jeg har hørt de er gode til at følge krav specifikationer til punkt og prikke, hvad end de resultere i et fungerende system er mindre relevant.

Det er naturligvis sat lidt på spidsen overfor denne opgave, men da vi alle ved at krav sjældent er så præcise ville jeg nok velkomme noget der indikere at ansøgeren tænkte lidt over tingene frem for bare slavisk at implementere hvad der stod på papiret.

Dermed sagt at jeg ville se positivt på en der brugte %15 istedet.

  • more_vert
    • insert_linkKopier link
9
Christian Nobel
1. februar 2017 kl. 12:10

  1. var
  2.   b:integer;
  3. begin
  4.   for b:=1 to 100 do
  5.   begin
  6.     if (b mod 15)=0 then writeln('fizzbuzz')
  7.     else if (b mod 5)=0 then writeln('buzz')
  8.     else if (b mod 3)=0 then writeln('fizz')
  9.     else writeln(b);
  10.   end;
  11. end;
Super overskuelig.

Man kunne selvfølgelig også bruge en case sætning, men resultatet ville vel være det samme by the end of the day.

  • more_vert
    • insert_linkKopier link
8
Morten Olsen
1. februar 2017 kl. 11:20

80'erne ringede. De ville gerne have deres 6502 relevante optimeringer tilbage !

(Sagt med et glimt i øjet, og en opfordring til at læse lidt op på moderne CPU arkitekturer...)

  • more_vert
    • insert_linkKopier link
6
Povl H. Pedersen
1. februar 2017 kl. 11:01

Jeg synes ikke min kode er sværere at forstå, tværtimod er den lettere. Reglerne er: Deles med 3 sig fizz Deles med 5 sig buzz Deles med 3 og 5, så begge ovenstående.

Og som sagt er der færre modulo operationer som er tunge. Dog bruges en register variabel som der ofte vil kunne laves til en jump if not zero på (sidste if) - Så billig CPU i den ene if.

Jeg synes min version er letter at læse,og svarer til den metode de fleste personer vil bruge i virkeligheden. Først checke med 3 tabellen, så sige fizz og samtidig check 5 tabellen, og sige buzz hvis match. Og meget lettere at udvide med eksempelvis en ekstra tabel.

  • more_vert
    • insert_linkKopier link
5
Morten Hansen
1. februar 2017 kl. 10:22

Til gengæld udfører den højst 2 modulus beregninger hvor Jespers løsning laver mindst 2 :) Regnekraftmæssigt er det ganske fornuftigt hvis man går op i den slags detaljer.

  • more_vert
    • insert_linkKopier link
4
Anders Clausen
1. februar 2017 kl. 10:04

Din løsning har det problem, at du evaluerer alle dine conditions hver gang, samtidigt med, at du har implicitte conditions som kun bliver anskueliggjort for andre programmører, når de har forstået din kode i sin helhed. Bare for at give lidt konstruktivt kritik :) Løsningen er såmænd elegant nok rent funktionelt.

  • more_vert
    • insert_linkKopier link
3
Povl H. Pedersen
1. februar 2017 kl. 09:44

Man kan sætte ansøger til at løse den på 5, 10 eller 15 minutter før interview. Så er det kun ansøgers tid man spilder.

Der er mange måde at ændre den på, jeg ville nok lave:

  1. for ($i=1;$ i<=100;$ i++) {
  2.   $done=0;
  3.    if ($i % 3 == 0 ) {
  4.       print "fizz";
  5.      $done=1;
  6.    }
  7.    if ($i % 5 == 0) {
  8.       print "buzz";
  9.       $done=1;
  10.    }
  11.    if (!$done) {
  12.       print $i;
  13.    }
  14.    print "\n";
  15. }

Lettere at læse, men selvfølgelig et ekstra funktionskald per iteration. print "\n".

Synes at den foreslåede i artiklen er overkompleks, og ligner noget lavet af en matematiker eller datalog, der har overtænkt problemet. 15, eller rettere 3 og 5 er ikke et specialtilfælde. Det er 3 = fizz og 5 = buzz der begge trigges uafhængigt. Artiklens løsning vil hurtigt vokse i kompleksitet hvis vi laver fizzbuzzbum hvor vi tilføjer 7-tabellen. Min løsning vil kræve en lille if-sætning mere.

Nu skal det siges at jeg ikke lever af at kode. Så jeg belønnes ikke med jobsikkerhed ved at lave unødig kompleks kode.

  • more_vert
    • insert_linkKopier link
1
Peter Makholm
1. februar 2017 kl. 08:57

Jeg har set flere kandidater fejle på simple kodeopgaver, men at sidde til et interview og kode FizzBuzz er spild af min uanset hvilken side af bordet jeg sidder på.

Hvis man har 1000 ansøgere og en forventning om at højst 10% har bare de minimale programeringskundskaber der skal til før man gider at læse ansøgningen, så kan en opgave af et tilsvarende niveau måske indgå i en screening, men ellers?!?

Det eneste fornuftige svar på FizzBuzz er Joel Grus': http://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/

  • more_vert
    • insert_linkKopier link