4 ms·
They know exactly what they're doing. The code, while clever, is bad for understandability, extensibility, and debuggability. They tried throughout the intervie
by wakawaka28 2y ago
They know exactly what they're doing. The code, while clever, is bad for understandability, extensibility, and debuggability. They tried throughout the interview to get the candidate to do something else, and he ignored all advice and hints. If this even happened at all. It sounds like a "just so" work of fiction.
- joshuaissac 2y agoThe rules that they added, like the ban on mathematical operations, made it clear that they were not looking for understandable code. His code could handle new rules without a problem, so extensibility was not a problem either.
- wakawaka28 2y agoNear the top of the article: >While the base algorithm is very simple, the point of the exercise is that the interviewer will add new rules to test how you update the code while keeping it readable and maintainable. As for this: >His code could handle new rules without a problem, so extensibility was not a problem either. Ok, now I want you to query a database at runtime and write the output to a file instead if the number is in the database. Good luck with adapting this type-theory solution, and good luck with debugging this crap. It's a PhD-level solution to a freshman-level problem, that is very atypical and uses niche features of the language that might fail unexpectedly due to language limitations. On top of all of that, the story sounds like fiction as well. But who knows.
- deleted 2y ago[deleted]
- grajaganDev 2y agoI am not sure that clean, extensible and debuggable code could be written for such a bizarre set of requirements.