Live data from Hacker News

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

news.ycombinator.com

21–30 of 84 posts

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

#22

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.

What if the SW house is competing in the ioccc?

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

#24

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.

QA engineer for a C++ compiler?

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

#25

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.

Unless they had, and i know this is hard to imagine in a c++ dev, a sense of humour

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

#27
post #3

Yay, let's talk about FizzBuzz! This is the fastest PHP version I could come up with so far: 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…

https://tech.marksblogg.com/fastest-fizz-buzz.html Not sure I'd call writing Assembly "elegant" but hey!

Yeah, I know all the different language versions from the FizzBuzz shootout on Stackoverflow.

I'm particularly interested in comparing PHP, Python and Javascript.

So I would like to write an "optimal" PHP version first. Afaik that has not been done yet.

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

#28
post #3

Yay, let's talk about FizzBuzz! This is the fastest PHP version I could come up with so far: 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…

Probably your implementation is limited by the speed PHP/echo can output things to stdout, rather than your implementation per-se.

Better, use a benchmarking framework/library to see how many OP/sec you can do, within the PHP runtime, so you remove stdout from the benchmark.

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

#29
post #10

Earlier quoted context omitted.

It's a static initialization time FizzBuzz. In this case, I think it's executed before main() is called, and not at compile time. Unless, of course, you have a very clever compiler that determines memory allocation is not actually allocating anything and that the output is a static string, and there are no side effects. Such a clever compiler could optimize it all into just one "puts" call.

Neither GCC nor Clang bake the final string into the data segment. If I had to guess, printf is the one preventing the more fancy optimizations to take place.

I think so too. Also, depending on stdlib output buffering, the external I/O behavior of 100 puts calls is potentially different from just one call.

In other words, there might be a different number of stdout write-calls.

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

#30
post #2

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

If an interviewer had a "hard talk" about anything during an interview, i'd have an immediate hard walk.

Curious, why? If I'm interviewing, I like to receive feedback if I'm not good enough for the role. I also return the courtesy
Post reply on HN