Why is that your takeaway? The test isn't just "write a fizzbuzz", it's "write a fizzbuzz better than all the other candidates". Suppose one candidate produces straightforward readable code within those restrictions and the other doesn't, which would you hire? This guy chose deliberately to write an unreadable solution that is highly impractical against the advice of the interviewer.
This is supposedly a NodeJS / NestJS / backend position. If they seem like a good team fit then I would hire someone this good with TS types in a heartbeat.
Especially that this is a small company, so if I'm some kind of mid-level decision maker there then having someone versatile is a big advantage for this company.
If this would be a huge boring enterprise recruiting for the maintenance of their legacy COBOL.TS backend? Then probably the orthodox candidate.
I don't think you'd really like to see any code like that in production. The point of an interview is to demonstrate your talents as they relate to the job. While fiddling with types is fun, it is not really relevant and is the exact opposite of what you should be doing in a real codebase. The person in this interview chose to do something silly to show off. They could have demonstrated their actual TS knowledge but instead they chose to write something totally unreadable after the interviewer asked them not to once, then made a specific rule which is basically telling them to drop the silly type stuff and just write normal code. If you really wanted the job, would you behave like that in the interview?
The libraries your "production code" depends on have types just as complex as the one in TFA if not even more. Based on this judgement, I'm willing to bet the author has more "actual knowledge" of TypeScript than you.
Try reading the types in popular libraries like zod, openapi-ts, tanstack router, etc.
