Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScripting the technical interview

richard-towers.com

Post reply on HN
Print view View original

11–20 of 180 posts

Re: TypeScripting the technical interview

#12

Post by cjbprime »

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/issues/14833

Re: TypeScripting the technical interview

#13

Post by nayroclade »

joenot443 wrote: post #6

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’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 the library itself. The library API may not be particularly amenable to easy typing, and the community types can end up being rather confusing, especially to people who developed neither the types nor the original library.

Re: TypeScripting the technical interview

#14

Post by ycitm »

dec0dedab0de wrote: post #3

So he wrote all that for the typescript lsp to respond with the answer, but when it compiles down it's nothing? And we're using runes as variables just because? That is pretty neat, and silly. I also think it highlights my natural aversion to static type checking in dynamic languages. I know that I could get sucked into writing a bunch of code for the checker, instead of using my energy for making the application wor…

The runes are mostly "just because", but there is a reason.

Ideally, I would have written:

  type Nil = unique symbol
Which would ensure the Nil type wouldn't match with anything but itself. Unfortunately, the compiler doesn't allow unique symbol other than on const variables initialised with Symbol(). So I needed some meaningless symbols.

I could also have done

  type Nil = "nil"
But then it would have looked like the string meant something.

Re: TypeScripting the technical interview

#15

Post by higeorge13 »

magnio wrote: 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…

The fizzbuzz tensorflow must be one of the funnier posts ever.

Re: TypeScripting the technical interview

#17

Post by orf »

implicit wrote: 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.

Re: TypeScripting the technical interview

#18

Post by TheCleric »

nayroclade wrote: post #13
joenot443 wrote: post #6

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’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%.

Re: TypeScripting the technical interview

#19

Post by MatthiasPortzel »

cjbprime wrote: post #12

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…

Aphyr has a series of posts in this style, all of which are excellent.

Re: TypeScripting the technical interview

#20

Post by MatthiasPortzel »

orf wrote: post #17
implicit wrote: 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, and the first one is here. https://aphyr.com/posts/340-reversing-the-technical-intervie...

This post translates one of them from Haskell to typescript (very well IMO).

Post reply on HN