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.
And how do easily verify this divisibility when "Numeric types, number literals and their associated methods and operations are forbidden?"
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";
}
"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"
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.
function isDivisibleByThree(num) {
let modulo, mod3 = "012012012012";
for (const digit of num) {
[modulo] = mod3.slice(modulo).slice(digit);
}
return modulo === "0";
}But my real point is they did have the digit sum insight. Their code was already doing your previous suggestion, and if there's a compact way to slice in typescript types it could be adapted to this new method by replacing SUM_TABLE and changing one other line.
The only difference is that they're doing a sum modulo 9 instead of modulo 3, but both of those work fine.
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.
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.
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 :)
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.
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".
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.
(see for example Scott Wlaschin)
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.
Yes, but only on the weekends :)
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
Where was that stated? I don't see those being mentioned as core requirements at all
"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."
Fizz buzz is also much better treated like data stream and applying reactive programming.
Basic programming skill is also picking right tool for the job.
What he did was worst approach possible.
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.
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.
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.
Pff.
Oh, you did a trick in the limited time of a single interview? You must only know that one trick, rejected.
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.