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

31–40 of 180 posts

Re: TypeScripting the technical interview

#31

Post by eyelidlessness »

TheCleric wrote: post #18
nayroclade wrote: post #13

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

I make an exception for using any in type params which extend type params, eg

  const foo = >(dict: T) => …
This is a good signal that foo maps over dict in some generic way that cares more about its dictionary-ness than its values. Sure, unknown works in that position too, but at least IMO the “doesn’t care” bit is more informative than “doesn’t know”. The latter might imply more type narrowing will happen than is the case.

Re: TypeScripting the technical interview

#32

Post by eyelidlessness »

borissk wrote: post #16

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

As much as people complain about the TS type system’s complexity, it is just modeling real world JS. The vast majority of its complexity is hardly used in TS that doesn’t interop with existing JS, because you generally won’t write such highly dynamic code when you have to define its types. But it does allow for safer interop.

Even so, JS itself being so dynamic, TS still can’t claim full type safety.

And as much as people complain about the type system’s verbosity, many newer features are designed specifically to allow you to be much more terse while improving expressivity and safety. A great example: the satisfies operator lets you narrow a value’s type to conform to whatever it satisfies, and simultaneously widen it to whatever it adds (including anything optional in the narrower type). This is great for composition, only takes two words to accomplish. And its meaning should be immediately obvious at a glance once you know about the operator.

Re: TypeScripting the technical interview

#33

Post by sebazzz »

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?

> The sea of confusing types to solve any problem?

Mostly in typings either provided by the library itself or via the 3rd party DefinitelyTyped project. Some typings have been made so complex, that it is hard to follow what kind of concrete type is exactly expected or allowed.

[1]: https://github.com/DefinitelyTyped/DefinitelyTyped

Re: TypeScripting the technical interview

#34

Post by rorymalcolm »

borissk wrote: post #16

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

Having the type system this complicated is mostly for library builders, makes the developer experience of tools like tRPC, Zod and Prisma possible. An engineer writing business logic in TypeScript will probably never have to learn how to write (or even read tbh) complex TypeScript signatures, but benefit significantly from the solutions the type system complexity is a necessary precursor for.

Re: TypeScripting the technical interview

#37

Post by alexgrover »

eyelidlessness wrote: post #31
TheCleric wrote: post #18

Earlier quoted context omitted.

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

I make an exception for using any in type params which extend type params, eg const foo = >(dict: T) => … This is a good signal that foo maps over dict in some generic way that cares more about its dictionary-ness than its values. Sure, unknown works in that position too, but at least IMO the “doesn’t care” bit is more informative than “doesn’t know”. The latter might imply more type narrowing will happen than is the…

The problem with that is that when consuming of the dictionary, “doesn’t know” is actually more appropriate. If you then access Object.values(foo) in your method you are given an iterable of anys which is unsafe.

Re: TypeScripting the technical interview

#38

Post by faitswulff »

MatthiasPortzel wrote: post #19
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.

This post also mentions "Vidrun," which features heavily in Aphyr's posts. And the interviewer in this post recognizing the situation they were in had me literally laughing out loud!

Re: TypeScripting the technical interview

#39

Post by tengbretson »

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?

In my experience, even the more wild/exotic patterns in typescript tend to flatten into something rather readable at their usage site. 95% of the time when I use a library that does anything close to what is done in this article I write my code, hover over it, intellisense tells me its type and I say "wow, how was it able to do that? Cool!" And I carry on.

Re: TypeScripting the technical interview

#40

Post by stevekemp »

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…

I think you would enjoy this too

https://aphyr.com/posts/353-rewriting-the-technical-intervie...

Post reply on HN