6 ms·

I will go against the grain and say I do not consider OPs fizzbuzz solution to score particular well on readability or maintainability. And these were the only

I will go against the grain and say I do not consider OPs fizzbuzz solution to score particular well on readability or maintainability. And these were the only two stated core requirements. The solution is clever and demonstrates solid knowledge of TS. However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers.

Too 2y ago
Agree. While the solution is impressive, the choice of using the type system severely hampers the ways the code can be deployed. Instead of taking dynamic input, the DATA array must now be encoded up-front in an unexpected number-base and run within the tsc compiler. It limits the number of members in the team that can maintain it. Finally, he was lucky there were no further silly requirements like send a PDF report to the CTO if the number is divisible by 201 and it's a Monday. While i also disprove of the interview setup and their bizarre artificial limitations, in the real world shit also happens and you need to react to it, if you decided to prematurely constrain yourself for the sake of scratching your own itch, you could set back progress for weeks, i see this happen all the times with people choosing the wrong tool for the job or reinventing what already exists in the standard library. Long term maintainability and pragmatism is valued higher by the business. In my books this choice alone wouldn't be cause for rejection, a good interviewer would question it though and depending on the reaction, it could be. Whether or not that happened here isn't clear. They could also have other even better candidates to pick.
- remich 2y ago
  I noticed this in the throwaway comment that the OP made at the end about their prior job disfavoring the use of TS. I'm not surprised to see that type of sentiment from someone who is (at least self-described) at a more junior level, but still. Often the choice of what language/framework/tool to use on a given codebase or project is dictated or constrained by considerations other than which one is "best" in a technical sense. Does this suck? Yeah, most of us have strongly held opinions or like to try out new shiny things. But it's a reality of working in this field and coworkers who refuse to learn it can be really hard to work with.
- Dylan16807 2y ago
  There are two things that make it hard to maintain. One is choice of language, which is supposed to not matter because it's just an interview exercise where you can pick any language. The other is the contortions around not using numbers. Anything stemming from those two factors should not be held against the candidate. It definitely shouldn't be labeled as "scratching your own itch".
bhaney 2y ago
> ...readability or maintainability. And these were the only two stated core requirements. Where was that stated? I don't see those being mentioned as core requirements at all
- guccihat 2y ago
  It was the whole point of the exercise if I read the article correct "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."
  - bhaney 2y ago
    Good point. I don't know why that stood out to me so much less than "the interviewer noted that I could even use esoteric programming languages" which to me is code for "go nuts and do stupid fun stuff like writing your whole solution in APL for the extra challenge of it" or other flashy passion-having-shibboleths, which are usually incompatible with readability or maintainability.
spacechild1 2y ago
Keep in mind that they came up with this solution after the interviewers forbid the use of numeric types and math while still keeping a limit of 30 lines. What do you expect? I found the solution impressive given the circumstances. At this point I would have thrown the towel.
- guccihat 2y ago
  I think the interviewers were looking for the key insight that a number is divisible by 3 iff the sum of the individual digits is divisible by 3. That is easy to verify, even constrained to using single digit data types. To be clear, I am not saying this was a great interview question and I agree the solution OP came up with is impressive.
  - deleted 2y ago
    [deleted]
  - cornstalks 2y ago
    > a number is divisible by 3 iff the sum of the individual digits is divisible by 3 And how do easily verify this divisibility when "Numeric types, number literals and their associated methods and operations are forbidden?"
    - guccihat 2y ago
      Since I read the constraint to allow for single digit numeric values*, I guess they are looking for a solution similar to: function isDivisibleByThree(num: string): boolean { let mod3 = "012012012012"; let modulo = "0"; for (const digit of num) { modulo = mod3[Number(digit) + Number(modulo)]; } return modulo === "0"; } If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep everything in string representation. "The programmer can use whatever representation they see fit with the only restriction being that it could only contain letters, numbers and symbols that could be typed with a single stroke"
      - 2y ago
ozim 2y ago
Getting clever with type systems is exactly why everyone hates Java and OOP. Fizz buzz is also much better treated like data stream and applying reactive programming.
- catlifeonmars 2y ago
  Fizz buzz is a toy problem. I think it’s a mistake to read too much into anything but basic programming skills while using it as an interview question. If you want to test code quality and maintainability you are much better off with a more realistic problem.
  - ozim 2y ago
    Making convoluted solution by solving the problem with type system is showing that OP doesn’t have basic programming skills. Basic programming skill is also picking right tool for the job. What he did was worst approach possible.
    - catlifeonmars 2y ago
      On the contrary, it shows that the OP has a very good understanding of the type system. Plus, it’s an understandable approach given the code golf nature in which the original problem was presented. (Line length and character limits screams “code golf” to me) I give lots of interviews and I try very hard to resolve ambiguity in the expectations and requirements. Up front I explain what the purpose of the interview is and what I intend to evaluate. It’s silly to assume everyone is equally able to read between the lines and coding interviews are already a very poor approximation of what a day to day software engineering job looks like, so I try my best to set expectations up front.
      - ozim 2y ago
        But it shows OP is "one trick pony" and interviewer told him it will not be proper approach but then he still went with it. We also had some freelancers like that and one employee who lasted 3 months - and always it was company owners who wanted to "bring help to speed things up". Those guys ignored everything and did code the way they knew how to do it. Results were always bad and 3 months guy instead of speeding anything up trashed all team productivity for those 3 months and I guess even 2 more when we had to do the cleanup of his worst inventions.
arp242 2y ago
This is also one of those things that can be quite tricky to modify down the line when you need to add a new feature or whatnot. This problem is of course very artificial and it doesn't sound like the interview was particularly well done, but I can kind of see what they were trying to do with "keep code maintainable as it evolves". And even if you are a TS-wizard with a Ph.D. in typing: is it really worth all the cognitive overhead?
- whstl 2y ago
  Honestly? It REALLY is. This kind of typing in TS is used mostly for getting dynamically typed Javascript codebases under control. I did this once for a state management library that was considered "impossible to add types to" by the authors themselves, and thanks to this I found several bugs in the library itself, and in our own codebase, due to subtle incorrect usage. Just the fact that we got autocompletion across the whole app was worth the effort. Even the engineer that was against it ended up praising it. I'm not the kind of person to say this but: maybe some things are not for everyone. Some people just have different interests and skills. Complicated things aren't less worth just because someone in the team can't understand them.
  - deleted 2y ago
    [deleted]
- kiviuq 2y ago
  I thought domain modelling through types is considered standard in functional programming? (see for example Scott Wlaschin)
- wrs 2y ago
  The FizzBuzz story did go down a rabbit hole, but this sort of TS type extravagance in small doses can help with maintainability. E.g., I wanted to enforce that the keys in a config object couldn’t have consecutive uppercase letters, because they would be automatically translated to camel case when looked up as environment variables (so awsAPIKey would become AWS_A_P_I_KEY, ugh). No need for a lint rule or whatever, you can do that with TS types in a few lines!
hnthrow90348765 2y ago
>However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers. If that's their code base, they shouldn't be asking these kinds of questions. They'd be better served by asking to debug a non-functioning component that looks like a real component you'd find in their code base. Plus readability and maintainability are subjective
ornornor 2y ago
The interviewers came up with a lot of brain dead rules that they (hopefully) don’t use on their code base. I could ask you to show me how well and fast you can run while making up a rule that you can’t use your legs and then tell you that you can’t run fast enough to join my sprint team… but that would be idiotic on my part.

Too 2y ago

Agree. While the solution is impressive, the choice of using the type system severely hampers the ways the code can be deployed. Instead of taking dynamic input, the DATA array must now be encoded up-front in an unexpected number-base and run within the tsc compiler. It limits the number of members in the team that can maintain it. Finally, he was lucky there were no further silly requirements like send a PDF report to the CTO if the number is divisible by 201 and it's a Monday. While i also disprove of the interview setup and their bizarre artificial limitations, in the real world shit also happens and you need to react to it, if you decided to prematurely constrain yourself for the sake of scratching your own itch, you could set back progress for weeks, i see this happen all the times with people choosing the wrong tool for the job or reinventing what already exists in the standard library. Long term maintainability and pragmatism is valued higher by the business. In my books this choice alone wouldn't be cause for rejection, a good interviewer would question it though and depending on the reaction, it could be. Whether or not that happened here isn't clear. They could also have other even better candidates to pick.

remich 2y ago
I noticed this in the throwaway comment that the OP made at the end about their prior job disfavoring the use of TS. I'm not surprised to see that type of sentiment from someone who is (at least self-described) at a more junior level, but still. Often the choice of what language/framework/tool to use on a given codebase or project is dictated or constrained by considerations other than which one is "best" in a technical sense. Does this suck? Yeah, most of us have strongly held opinions or like to try out new shiny things. But it's a reality of working in this field and coworkers who refuse to learn it can be really hard to work with.
Dylan16807 2y ago
There are two things that make it hard to maintain. One is choice of language, which is supposed to not matter because it's just an interview exercise where you can pick any language. The other is the contortions around not using numbers. Anything stemming from those two factors should not be held against the candidate. It definitely shouldn't be labeled as "scratching your own itch".

bhaney 2y ago

> ...readability or maintainability. And these were the only two stated core requirements. Where was that stated? I don't see those being mentioned as core requirements at all

guccihat 2y ago
It was the whole point of the exercise if I read the article correct "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."
- bhaney 2y ago
  Good point. I don't know why that stood out to me so much less than "the interviewer noted that I could even use esoteric programming languages" which to me is code for "go nuts and do stupid fun stuff like writing your whole solution in APL for the extra challenge of it" or other flashy passion-having-shibboleths, which are usually incompatible with readability or maintainability.

spacechild1 2y ago

Keep in mind that they came up with this solution after the interviewers forbid the use of numeric types and math while still keeping a limit of 30 lines. What do you expect? I found the solution impressive given the circumstances. At this point I would have thrown the towel.

guccihat 2y ago
I think the interviewers were looking for the key insight that a number is divisible by 3 iff the sum of the individual digits is divisible by 3. That is easy to verify, even constrained to using single digit data types. To be clear, I am not saying this was a great interview question and I agree the solution OP came up with is impressive.
- deleted 2y ago
  [deleted]
- cornstalks 2y ago
  > a number is divisible by 3 iff the sum of the individual digits is divisible by 3 And how do easily verify this divisibility when "Numeric types, number literals and their associated methods and operations are forbidden?"
  - guccihat 2y ago
    Since I read the constraint to allow for single digit numeric values*, I guess they are looking for a solution similar to: function isDivisibleByThree(num: string): boolean { let mod3 = "012012012012"; let modulo = "0"; for (const digit of num) { modulo = mod3[Number(digit) + Number(modulo)]; } return modulo === "0"; } If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep everything in string representation. "The programmer can use whatever representation they see fit with the only restriction being that it could only contain letters, numbers and symbols that could be typed with a single stroke"
    - 2y ago

ozim 2y ago

Getting clever with type systems is exactly why everyone hates Java and OOP. Fizz buzz is also much better treated like data stream and applying reactive programming.

catlifeonmars 2y ago
Fizz buzz is a toy problem. I think it’s a mistake to read too much into anything but basic programming skills while using it as an interview question. If you want to test code quality and maintainability you are much better off with a more realistic problem.
- ozim 2y ago
  Making convoluted solution by solving the problem with type system is showing that OP doesn’t have basic programming skills. Basic programming skill is also picking right tool for the job. What he did was worst approach possible.
  - catlifeonmars 2y ago
    On the contrary, it shows that the OP has a very good understanding of the type system. Plus, it’s an understandable approach given the code golf nature in which the original problem was presented. (Line length and character limits screams “code golf” to me) I give lots of interviews and I try very hard to resolve ambiguity in the expectations and requirements. Up front I explain what the purpose of the interview is and what I intend to evaluate. It’s silly to assume everyone is equally able to read between the lines and coding interviews are already a very poor approximation of what a day to day software engineering job looks like, so I try my best to set expectations up front.
    - ozim 2y ago
      But it shows OP is "one trick pony" and interviewer told him it will not be proper approach but then he still went with it. We also had some freelancers like that and one employee who lasted 3 months - and always it was company owners who wanted to "bring help to speed things up". Those guys ignored everything and did code the way they knew how to do it. Results were always bad and 3 months guy instead of speeding anything up trashed all team productivity for those 3 months and I guess even 2 more when we had to do the cleanup of his worst inventions.

arp242 2y ago

This is also one of those things that can be quite tricky to modify down the line when you need to add a new feature or whatnot. This problem is of course very artificial and it doesn't sound like the interview was particularly well done, but I can kind of see what they were trying to do with "keep code maintainable as it evolves". And even if you are a TS-wizard with a Ph.D. in typing: is it really worth all the cognitive overhead?

whstl 2y ago
Honestly? It REALLY is. This kind of typing in TS is used mostly for getting dynamically typed Javascript codebases under control. I did this once for a state management library that was considered "impossible to add types to" by the authors themselves, and thanks to this I found several bugs in the library itself, and in our own codebase, due to subtle incorrect usage. Just the fact that we got autocompletion across the whole app was worth the effort. Even the engineer that was against it ended up praising it. I'm not the kind of person to say this but: maybe some things are not for everyone. Some people just have different interests and skills. Complicated things aren't less worth just because someone in the team can't understand them.
- deleted 2y ago
  [deleted]
kiviuq 2y ago
I thought domain modelling through types is considered standard in functional programming? (see for example Scott Wlaschin)
wrs 2y ago
The FizzBuzz story did go down a rabbit hole, but this sort of TS type extravagance in small doses can help with maintainability. E.g., I wanted to enforce that the keys in a config object couldn’t have consecutive uppercase letters, because they would be automatically translated to camel case when looked up as environment variables (so awsAPIKey would become AWS_A_P_I_KEY, ugh). No need for a lint rule or whatever, you can do that with TS types in a few lines!

hnthrow90348765 2y ago

>However, in my experience getting too clever with the type system is not always a good idea for ordinary application code maintained by a team of average TS developers. If that's their code base, they shouldn't be asking these kinds of questions. They'd be better served by asking to debug a non-functioning component that looks like a real component you'd find in their code base. Plus readability and maintainability are subjective

ornornor 2y ago

The interviewers came up with a lot of brain dead rules that they (hopefully) don’t use on their code base. I could ask you to show me how well and fast you can run while making up a rule that you can’t use your legs and then tell you that you can’t run fast enough to join my sprint team… but that would be idiotic on my part.