Live data from Hacker News

TypeScripting the technical interview

richard-towers.com

21–30 of 180 posts

Re: TypeScripting the technical interview

#21

In case folks miss the link at the top of the article, this is translated from an old 2017 post by Aphyr. That post was in Haskell, where it's not too surprising that you can do serious computation inside the type system. This new post translates the ideas to TypeScript, which is more widely known, and which I once heard described as having "accidentally Turing-complete" types: https://github.com/microsoft/TypeScript…

Here[0] is the open issue about TypeScript being Turing complete. The current most recent comment[1] is showing the type system parsing its own type syntax. Of course there have been many parsers written in the type system since template literal types landed, but I found this one particularly amusing.

0: https://github.com/microsoft/TypeScript/issues/14833

1: https://github.com/microsoft/TypeScript/issues/14833#issueco...

Re: TypeScripting the technical interview

#22
post #17
post #9

Richard has a whole series of these. I was going to try to pick out one of my favourites from this series, but I really can't. Every last one is a treasure. EDIT: Oops! This is based on Aphyr's work. My bad!

Can you link them? I couldn’t find them on his blog.

The series is actually by Aphyr: https://aphyr.com/tags/interviews

This post is a pastiche of https://aphyr.com/posts/342-typing-the-technical-interview

Re: TypeScripting the technical interview

#24
post #16

TypeScript has the most complicated type system ever. Don't know why Anders&Co needed to go that far.

It aims to be able to express the typing used in a bunch of pre-existing javascript libraries. Many/most of these were written in a "how would I solve this if the type system just let me do whatever I wanted" style (since that's what runtime dynamic typing actually does).

Re: TypeScripting the technical interview

#25

Earlier quoted context omitted.

I’d say generally the opposite is true. Most commercial software I’ve worked on typically contained only simple typing—discriminated unions are about as complex as it gets—and it’s more of a problem that people get lazy and start using “any” too much than they go overboard. Where complex types can be a problem is when working with open source libraries, especially when the types are community-developed, separate to t…

I tell my fellow developers at work: "Any is banned. If you want any, use JavaScript, and we don't use JavaScript here. Perhaps you haven't heard about unknown?" In my experience, 90% of the time when a developer uses any, they just don't know about unknown. 9% it's because they are lazy. 1% is because you are implementing something from an imported library, and they fell into the other 99%.

Use "unknown" and TS complains that you're treating something as an object.

Use Object.defineProperties and TS complains because that stuff is invisible to it after how many years?

I think you're right, of course, but TS is hardly perfect and treating its ways as gospel is not an improvement over JS. The "right ways" change over time and beliefs are not shared among everyone.

Re: TypeScripting the technical interview

#26

In case folks miss the link at the top of the article, this is translated from an old 2017 post by Aphyr. That post was in Haskell, where it's not too surprising that you can do serious computation inside the type system. This new post translates the ideas to TypeScript, which is more widely known, and which I once heard described as having "accidentally Turing-complete" types: https://github.com/microsoft/TypeScript…

I'd say it's "inspired" rather than "translated".

The part about using the typescript language server to compute the solution, and the protagonist claiming the code is "concise" because only 4 lines of javascript were generated, was absolutely brilliant. Cracked me up at least.

Glancing at the actual code, I admit I'm with Criss in my ability to follow the logic, but it doesn't look like a direct translation from Haskel types to Typescript types either.

At any rate, very well done.

Re: TypeScripting the technical interview

#27
post #8

This is a delightful read, which reminds me of two other articles. The first is also a caricature of the technical interview, solving FizzBuz with Tensorflow: https://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/ The second is a explanatory story, or "discovery fiction" as the article classifies itself: https://paulbutler.org/2022/what-does-it-mean-to-listen-on-a... I love these humorous yet pedagogic technical wr…

Fizz-buzz in Tensorflow is a delight.

The ending is perfect.

Re: TypeScripting the technical interview

#28

Well written and super funny. Reminded me a bit of Scott’s writing, particularly the descriptions of the horrified interviewer. I’ve never worked in a Typescript shop, is there any truth to the satire here? The sea of confusing types to solve any problem?

> is there any truth to the satire here?

As long as you're satisfied with the answer being shown on a tooltip when you hover over a variable... sure.

Notice how the whole type structure ending up as 4 lines of inconsequential javascript after going through the typescript compiler at the very end.

Re: TypeScripting the technical interview

#30

Well written and super funny. Reminded me a bit of Scott’s writing, particularly the descriptions of the horrified interviewer. I’ve never worked in a Typescript shop, is there any truth to the satire here? The sea of confusing types to solve any problem?

I’ve worked for TypeScript companies for a while now. Most devs I’ve met are fairly pragmatic and wouldn’t try something like this for production code, but I’ve definitely met a couple who have an exceedingly deep grasp of the type system and would appreciate the whimsy of it.
Post reply on HN