For sure, as long as that's not how they/I write code normally! :D It demonstrates very in-depth understanding of the structure of the language, just as any good writing demonstrates expert-level understanding of natural language.

Two caveats:

- A lot of this knowledge might be kind of useless (for example, how to create unreachable code which nevertheless compiles), but I expect it would be difficult to demonstrate equally thorough understanding of the syntax of a language using exercises or looking at previous work (which ideally uses the minimum of sophistication to achieve the necessary functionality).

- It proves mastery of the syntax, but not of idioms, security, maintainability, speed, or any other metric relevant for production code. These might be correlated, but I'd rather see/present some examples of these as well to be sure.

As an IOCCC winner I've had my winning entry verbatim on my resume for years. It's small enough to look like a decorative footer and it always garners comments.

Your question has another angle: why would I care to work for an employer who looked down on my IOCCC win? It acts as a filter both ways.

Has anyone ever tried to compile it? It doesn't work for me:

  gcc -w 1990/tbr.c
  1990/tbr.c: In function ‘main’:
  1990/tbr.c:7:50: error: void value not ignored as it ought to be
      7 |   e(-8)     ,gets      (1+(    c=q)     )||      exit      (0);     r(0,0)
        |                                                  ^~~~~~~~~~~~~
  1990/tbr.c: In function ‘e’:
  1990/tbr.c:22:43: error: void value not ignored as it ought to be
     22 |  3 ;}e(x){x<0?write(2,"?\n$ "-x/4,2),x+1||exit(1):
        |                                           ^~~~~~~

Similar for clang. I'm sure there is an easy fix, but I don't know what it is.

The program in question, if anyone is wondering, was the 1990 winner of IOCCC "Best Utility" award. Source is here:

  https://www.ioccc.org/1990/tbr.c

The authors explain in rot13: "Guvf cebtenz vf n ehqvzragnel furyy."

Works for me with

    clang -std=c89 -Wno-implicit-function-declaration -fno-builtin tbr.c

Compilers are fussier (with good reason!) than they used to be.

Those flags work with gcc too. A deleted commented suggested adding `int exit();`, which also worked.

exit is a function returning void, which was traditionally coerced to 0 but anymore. Yusuke Endoh's patch [1] is available.

[1] https://mame.github.io/ioccc-ja-spoilers/patches/1990-tbr.pa...

No coercion needed. Pre-ANSI C does not have a void type, so unless otherwise specified the return type of a function defaults to int.

I've almost never had to write or read C in a professional capacity, but if I saw that the candidate was such a geek, it would certainly be a huge plus. There's a huge gap in professionalism and knowledge between people who choose software engineering as a trade because it pays well, and people who love it for the sake of it.

But there's a catch. Second kind of engineer is not only better, but also much more desirable and highly paid, so may be it's an indicator that you should check whether your salary range is high enough and your tasks are challenging enough for someone like that. For some (if not most) roles, 9-to-5, grunt work engineer that just closes tickets and doesn't write new languages in his spare time is really the best fit.

I've been hired at half of the FANG companies and I'm convinced I was hired not because of my direct performance in the interview questions, but I threw in bizarre minutiae about the problems that I've picked up over the years merely because I enjoy trivia.

I also failed an interview (or rather was not offered a job) at one of the FANGs, and I thought I did good enough on the interview portion, but it was the only interview where I didn't have the opportunity to drop some obscure trivia.

I think I did pass an interview once by pointing out to a compiler guy that an array is just a hash table with the identity hash function. Which I'd read in the Haskell manual the day before.

I hope that’s not how you’re implementing your arrays, though!

Having won the IOCCC definitely helps to boost visibility, since it is one extra place where prospective employers can look you up, and it's a fairly exclusive one.

I ended up doing some readability related work at my current job because of (in spite of) my IOCCC experience.

People who win or enter IOCCC are unlikely to be "one-trick ponies", but those who already have very deep knowledge of the language and possess significant creative/problem-solving skills. Fabrice Bellard is a notable winner, for example.

I would rank it with puzzle solving ability, which may or may not correlate with doing a good job.

> And turned around: if you've won (or even submitted an entry) to IOCCC, would you mention it when applying for work?

Yes, but typically as a passing mention. In that way it causes no harm for those who don't know IOCCC and gives me a plus for who know it.

Of course, but I'd be more likely to give the job to the person who could decipher such madness and explain it clearly any day over the author.

Code should be written to be understood by humans first and foremost. The person who can understand such deliberate garbage clearly and explain it well to those who don't understand, well, those people are the perfect human debuggers, in my opinion.