Comment by umvi | Hacker News Reader

Comment by umvi | Hacker News Reader

Am I the only one that thinks TypeScript types are a terrible choice?

His solution is clever, but if that's indicative of how he's going to do engineering work at my company, I guess that means I can expect clever solutions for everything, which usually leads to esoteric, architect astronaut code bases that will be difficult for his non-clever colleagues to grok/maintain.

"Now the easy part! I just have to encode the numbers in base 15 and I could apply the 2 and 5 rule to 3 and 5!" Encoding things in base 15 is too clever for me.

Back to the original statement I made: TS types are a terrible choice because TS types are not debuggable. If you get too fancy with them, you need a god in TypeScript to debug because you cannot set breakpoints inside of types and step through to see how generics and constraints propagate (as would be required by a mere mortal in order to debug).

"Hey, there's a bug in Joe's fizzbuzz function, but he's out on PTO, can you fix?"

"Sure, I'll step through with a debugger real quick... Oh wait, it's 100% typescript types, I can't step through with a debugger. I took a look but it looks like it's encoding numbers into base 15 for some reason... I don't want to break anything further, let's just wait for Joe to get back"

"Actually, can you just re-write it using normal conditional flow logic? We want more than just Joe to be able to touch the code."

> His solution is clever, but if that's indicative of how he's going to do engineering work at my company, I guess that means I can expect clever solutions for everything

I think this is uncharitable. The interviewer's demands to not use numeric types or any mathematical operations is inherently preposterous, and at that point the author can't be judged negatively for whatever contortions they needed to perform in order to comply with them.

That's fair, the interviewers did put unreasonable restrictions on the challenge that forced the overly clever solution. It was my kneejerk response from personal experience seeing candidates come up with overly clever solutions even to simple job challenges.

But even still, let's assume there is a problem out there with unreasonable requirements. And let's say an engineer architects a solution to that problem in 100% TS. How's that going to solve anything? When the inputs and outputs are types... how do you interface with such a solution? You can't because types only exist at compile time so there's no way to dynamically send in inputs and retrieve outputs (at least not without even more hacks/cleverness).

I can't ask the candidate not to jump, and then complain that he didn't.

> When the inputs and outputs are types... how do you interface with such a solution?

That wasn’t part of the criteria. If that’s something they wanted to assess, they should have told him “no” when he asked if it would be alright to encode the rules in the types.

Maybe you have an issue with the interview, rather than the interviewee?

His solution was clever because the problem was artificial, constrained, and required him to be creative.

He went to a solution he knew well, and the interviewer didn't ask to change.

If you solve this problem and use strings to do fizzbuzz instead of modulo, would you accept me saying that you're a doofus that doesn't know coding simply because you didn't do it the normal way?

Reply on news.ycombinator.com