5 ms·
Interestingly, unlike many in this thread I would've avoided hiring this person based only on the code example. This code is almost unreadable to me, certainly
by rokkamokka 2y ago
Interestingly, unlike many in this thread I would've avoided hiring this person based only on the code example.
This code is almost unreadable to me, certainly to most on my team. I would request changes it if it was a PR going into production (ignoring that the problem itself is made up). The code I would've liked to see would be easy to read, easy to follow, and would make me understand the underlying rules that made the code look like it is. This, I feel, achieves none of that.
But of course, everyone is different, and certainly many in this thread feel different. I just wanted to add my perspective :)
- lou1306 2y agoThe code being hard to read may be partly a consequence of having to bend over backwards to fulfill the absurd requirements. No numerical operations on a fizzbuzz problem? Give me a damn break.
- Ukv 2y agoI feel the no-numbers requirement essentially just boils down to replacing `num % 5 == 0` with `num.endswith(('0', '5', 'A'))` - or at least that's what I went with while playing along. Most of the complication (after the author realized they should use base-15) seems self-inflicted from the choice to write it within the type system, which the interviewer advised against. Fully granted that I'm not familiar with TypeScript, but I find it hard to believe that code like the below is more readable to anyone than the equivalent `for num in nums` loop. type FizzBuzz<T> = T extends `${_}${_|""}${_|""}` ? `${Fizzer<T>}${Bazzer<T>}${Buzzer<T>}` : ""; type Folded<T> = T extends [infer Head, ...infer Tail] ? `${FizzBuzz<Head>}${Folded<Tail>}` : "";
- mcherm 2y agoIf 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.
- spuz 2y agoI admit, I don't understand how it works. But there are ways of making code understandable that doesn't require rewriting it. Let's assume that creating custom types is the perfect solution to the given problem, you can help your fellow devs to understand it with comments, tests, documentation or even presentations. If I wrote code that was this obscure in an interview I'd be sure to mention that in a real scenario I'd provide links to this supporting documentation along with the code.
- deleted 2y ago[deleted]
- whstl 2y agoThe requirement says "Numeric types, number literals and their associated methods and operations are forbidden". There is almost zero chance that a passable FizzBuzz would be produced in those interviews.
- jajko 2y agoI have to agree. When I was junior decades ago, I saw all those cool one liners as some sort of holy grail and had huge respect for the authors, like we had 10KM HDDs so every char counts. Then I realized how hard they are to debug once codebase looks like this, and any serious production code will get debugged to hell, no doubt there. Also implementing changes require same mindset, which is rare in teams generally, so its basically a technical debt right in creation. KISS, the most important principle in any form of engineering is exact opposite of this. I've seen and experienced great success with it. I haven't seen that much success when ignored, apart from one man / tiny homogeneous team show.
- lproven 2y agoI admire terse code too. I can relate. I'm also old. But: > we had 10KM HDDs so every char counts. Ten kilometre hard disk drives? It can't be 10kB. Hard disks were never that small. Floppy disks were never that small. Maybe it's not hard disk drives. It can't be length of tape, or of mercury delay lines. I am mystified.