A way to torture an interviewer (C++, FizzBuzz)

If a candidate were suggesting this as their serious FizzBuzz implementation fit for production, I'd have a hard talk with them about readability.

Yay, let's talk about FizzBuzz!

This is the fastest PHP version I could come up with so far:

    <?php
    
    ob_start(null, 32000);
    
    $a = [0, 1, 'fizz', 3, 'buzz', 'fizz',
          6, 7, 'fizz', 'buzz', 10, 'fizz',
          12, 13, 'fizzbuzz', ''];
    
    for ($i = 1; $i < PHP_INT_MAX-15; $i+=15) {
        $a[0] = $i;
        $a[1] = $i+1;
        $a[3] = $i+3;
        $a[6] = $i+6;
        $a[7] = $i+7;
        $a[10] = $i+10;
        $a[12] = $i+12;
        $a[13] = $i+13;
        echo join("\n", $a);
    }

I'm sure there still are ways to make it faster. But I fail to think of them. Except for unrolling multiple loops into one. But that is so ugly. Any ideas of elegant ways to make it faster?

Testing the performance like this:

    php fizzbuzz.php | pv > /dev/null

215MiB/s on my slowish laptop.

The "yes" command gives me about 10x the throughoutput:

    yes fizz | pv > /dev/null

3.04GiB/s

Shows how much wiggle room there still is!

I also wrote a python version of it, but it performs 10x slower:

    a = [0, 1, 'fizz', 3, 'buzz', 'fizz',
         6, 7, 'fizz', 'buzz', 10, 'fizz',
         12, 13, 'fizzbuzz'];

    for i in range(1,1000000000,15):
        a[0] = i;
        a[1] = i+1;
        a[3] = i+3;
        a[6] = i+6;
        a[7] = i+7;
        a[10] = i+10;
        a[12] = i+12;
        a[13] = i+13;
        print("\n".join([str(x) for x in a]));

Maybe the bottleneck is the loop that converts the integers to strings? Maybe someone with Python knowledge can comment on how to approach this in Python!

Then there's 50GiB/s fizzbuzz

https://codegolf.stackexchange.com/a/236630

As someone who avoids C++ these days ...

Is this a compile time FizzBuzz?

`(char*)&1[""]` is the empty string here returning its data segment address as the offset? Not sure about the purpose of `1`.

Is the iteration achieved by the constructor basically re-invoking itself?

    #include <stdio.h>
    #include <string.h>
    
    struct a_struct {
      char a[1];
      char b[2];
    
      a_struct() {
         strcpy(a, "");
         strcpy(b, "b");
      }
    } x;
    
    int main() {
       printf("before:\n");
       printf("a : '%s'\n", x.a);
       printf("b : '%s'\n", x.b);
    
       char *c = &1[x.a];
       *c = 'c';
    
       printf("after:\n");
       printf("a : '%s'\n", x.a);
       printf("b : '%s'\n", x.b);   //b is now corrupt
    }

    C:\temp>g++ test.cpp
    C:\temp>a.exe
    before:
    a : ''
    b : 'b'
    after:
    a : ''
    b : 'c'

Good effort but too straight-forward. Using an explicit, readable ternary operator is cheating in obfuscation.

I rather like this too - https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/

You wouldn't torture him. You would just zero the probability of getting an offer. There's no SW house or colleague in his right mind that would want a developer that writes obfuscated and needlessly complex to understand code.

  > How much structure would you like?

  top = 100

  data = { 
      3: "fizz",
      5: "buzz"
  } 


  for i in range(1, top+1):
      output_num = True
      for j in data:
          if i%j == 0:
              print(data[j], end="")
              output_num = False

      if output_num:
          print(i)
      else:
          print("")

The very point of FizzBuzz is that it is a test whether a candidate can write it straightforward enough, even redundantly, but readable — or they have to resort to some ugly cleverness :)

Talking about actually genial FizzBuzz interview answers, I have yet to see someone even going close to this: https://aphyr.com/posts/353-rewriting-the-technical-intervie...

I get how this works, but this has undefined behaviour at multiple places.

I’d walk out. Never, ever take a job given to you for solving a riddle. Everyone else there will have gotten theirs the same way and it won’t be great.

We no longer ask candidates to write code. Instead we give them code to review and plenty of time. After that we do a meeting to discuss the changes. Works quite well for us.

This is undefined behavior. According to the C++ standard, there is no way to reason about what this does. Anything can happen with this code.

Once you have undefined behavior, you lose the ability to reason about your entire program.

Thus, this program does not solve the problem.

It demonstrates a lack of knowledge about undefined behavior in C++.

Rating: Absolutely would never hire this candidate.

I would probably post the idiomatic version in my programming language. Hopefully it will spark a discussion around language design. If not, perhaps it's a sign that the company is pretty rigid, and might not be a nice place to work.

    io:println¨ {⍵ (⊂"fizz") (⊂"buzz") (⊂"fizzbuzz") %⍨ 2 (⊥⍤1) ⍉ 0 = 5 3 |⌺ ⍵} ⍳20

If you do this on the interviewer's computer, their compiler can deal with undefined behaviour using physical violence. It's in the standard.

> } *x = new X[100]();

This C++ coder seems to have a habit of writing unecessary constructor argument lists. The example works if we change it to:

  *x = new X[100];

There are situations in C++ in which an extra constructor parameter list will do something different, so I'd be wary of this candidate.