4 ms·
If the requirements of the exercise had been "write FizzBuzz" then I would agree: doing weird tricks like this rather than writing straightforward code is a red
by mcherm 2y ago
If the requirements of the exercise had been "write FizzBuzz" then I would agree: doing weird tricks like this rather than writing straightforward code is a red flag.
But the requirements were "write FizzBuzz in ANY language. Then change it so it doesn't use use numbers (!!!). Stick to strict and unreasonable code length constraints."
The only POSSIBLE interpretation is that the interviewers don't WANT straightforward readable code, but want weird tricks instead. Which is exactly what the author gave them.
- wakawaka28 2y agoThe interviewers clearly expected the candidate to give up on his weird solution early. They should have just said, "Do it another way, we don't like this." But they let him dig his own grave instead. This solution is impractical in many cases, and fundamentally difficult to debug. They said many things that suggested that they wanted "easy to extend" and that implies "easy to debug." I don't really have much sympathy for the candidate. The whole story could also be fake, and certainly sounds like the kind of thing someone would make up to post a clever solution to HN that in truth took days or weeks to come up with.
- sgarland 2y agoIt seemed like it was actually trivially easy to extend. I’m not saying it’s an optimal solution in general, but given the absurd requirements, I think it was well done.
- TheOtherHobbes 2y agoOf course. The "I can't see how this works so FAIL" comments are missing the point. This person aced some ridiculous requirements. The odds are good they're capable of writing simple, clear, non-clever code when asked to. If the job requires simple, clear, non-clever code don't ask for FizzBuzz that can't use numerics.
- James_K 2y agoWhy 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.
- pas 2y agoThis 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.
- James_K 2y agoI 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?
- koito17 2y agoThe 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.
- 2y ago