[guccihat]

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.

[spacechild1]

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]

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.

[cornstalks]

> 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]

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"

[Dylan16807]

> If adding two single digit numbers is also prohibited it can be implemented with a lookup and keep everything in string representation.

Yeah uh I guess you missed the SUM_TABLE part of the article? That's what they're doing. And that's why the rule against matrices was added.

That version of the code is 80% checking if "the sum of the individual digits is divisible by 3", 20% the rest of the fizzbuzz.

[guccihat]

The constraint only states not to use hard coded matrices as I read it. Here is a version with number addition removed, this works fully on strings.

  function isDivisibleByThree(num) {
    let modulo, mod3 = "012012012012";
    for (const digit of num) {
        [modulo] = mod3.slice(modulo).slice(digit);
    }
    return modulo === "0";
  }

[zaruvi]

I would have failed this question badly. I'm curious, how would you check that without access to any number or math operations? I think I would try something similar to what he did with his sum_table, but that too was disallowed. They're constraints I've never had to deal with, nor seen before.

[joshribakoff]

Math operators like division aren’t native to your (traditional) cpu, they are implemented in code, for example using similar algorithms as the ones taught to us in grade school to multiply big numbers one digit at a time on paper and “long division”.

All math operations can be implemented with bitwise operators, too, i am pretty sure

Likely the interviewer specifically needed the candidate to do that, implement the math, and tried to steer them that way numerous times (no sum table, dont use the type system, no math operators). Thats likely also why they suggest allowing limited use of Google, because they realize many people will need a refresher on bitwise operations. But they don’t want to outright tell you what to search for, they needed to see some resourcefulness. When they suggested OP was cheating they likely didn’t mean it personally and actually wanted to help steer OP towards an acceptable solution. Rather than saying it’s cheating they could have said it avoids the main thing we need to see, or outright say “please implement the low level math from first principles”

In my opinion the candidate showed resourcefulness in their own way indeed, but sometimes its not even up to the person administering an interview for example if they have been given a rubric.

[Dylan16807]

Bitwise operators work on numbers. That's against the rules.

And while division can be implemented as repeated subtraction, you are not going to find any CPUs 4 bits and up that don't have an adder. It would be ridiculous to try to handle addition/subtraction in software.

[spacechild1]

> Math operators like division aren’t native to your (traditional) cpu, they are implemented in code

If you are talking about tiny microprocessors or old ARM chips, sure. But so are programming languages! They should have really asked him to code his solution in machine code then. After all, that's what you typically do in a NodeJS job :)

[drewhk]

You clearly did not read the article...

[Too]

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.

[Dylan16807]

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".

[remich]

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.

[arp242]

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?

[kiviuq]

I thought domain modelling through types is considered standard in functional programming?

(see for example Scott Wlaschin)

[whstl]

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.

[wrs]

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!

[catlifeonmars]

> And even if you are a TS-wizard with a Ph.D. in typing: is it really worth all the cognitive overhead?

Yes, but only on the weekends :)

[hnthrow90348765]

>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

[bhaney]

> ...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]

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]

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.

[ozim]

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]

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]

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]

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]

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.

[catlifeonmars]

Two tricks. OP switched from programming to meta programming halfway through.

Also the reason given (not the right tool for the problem) was demonstrably false if we take the OP at face value. They solved it and their solution was robust to changing requirements.

We only know the OPs side of the story, but if we take it at face value it reads a lot like the interviewer wanted to jump them through hoops and they made the best of it. I would have politely declined the interview pretty early on if I was in their shoes.

[Dylan16807]

> But it shows OP is "one trick pony"

Pff.

Oh, you did a trick in the limited time of a single interview? You must only know that one trick, rejected.

[ornornor]

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.