Ask HN: How can a JavaScript developer convince you they can work in TypeScript?

[danroc]

How would you evaluate a strong JS developer for a TypeScript position? What would convince you they can succeed in the role?

I'm a senior JavaScript developer looking for new opportunities, but many interesting positions require TypeScript experience.

While I'm confident in my ability to learn quickly, I understand the hesitation to hire someone without direct TS experience for a senior role.

For context, I see this as different from React <> Vue transitions, where skills are more clearly transferable.

[erellsworth]

I think you're imagining this will be a bigger deal that it really is. If you're a senior JS developer you should be able to pickup TypeScript in a weekend. Spend a few days, maybe a week building a small project using TypeScript. Boom, you've got TypeScript experience.

[drpossum]

You're writing this like they're subversively different languages. If you think React <> Vue transitions are transferable but then somehow think it's a bigger leap between Javascript and Typescript, you might want to reevaluate your own ability to assess developers. I treat the experience between JS and TS as more or less equally weighted and experience in whatever framework I'm looking to fill as slightly more important.

The most important thing that will overrule all of that is a good experience developer who has some demonstrable body of work.

[danroc]

I agree with you completely. I am confident on my ability to work in both JS and TS (or PHP, or Ruby, or [insert language here]), in the end they are tools, and what defines the quality of a candidate is much more broad and sometimes nuanced.

I'd love to get the perspective of someone hiring for roles where TS-experience is a strong requirement, especially if they ever had experience hiring devs with JS-only experience for senior roles.

[dtagames]

In my experience, very few projects are really TS "all the way down." Since all valid JS is also Typescript, what really happens is that you're writing JS with a sprinkling of TS where it is helpful and nowhere else.

A good place to start is by adding type declarations to a function, to specify the type of parameters it takes and the type of values it returns. This introduces the idea of type checking at compile time so you can spot errors in your calls to those functions or your use of their results when they don't match the type you specified. This is the only purpose of Typescript. It has no programming functions of any kind. That's all JS.

Once you've built and called a function with types on it (and VS Code is excellent for these experiments), the next thing to try is building an interface, that is a data shape of your own design. This is where the rocket takes off because instead of just saying your function needs "an object" parameter, you can specify the exact form of that object and the compiler will help you enforce that.

If you've mastered types in function calls and interfaces (and custom types, which are basically the same), congratulations because you know 90% of how TS is really used in the wild.

[solardev]

It's probably different at bigger companies, but at the small-medium businesses I've worked with, Typescript was just something everyone struggled with and everyone collaborated on, and it wasn't used as any sort of gate-keeping. Sometimes the juniors would get lucky and figure out a typing that the staff dev couldn't, and sometimes we'd all shrug and go "eh, just // @ts-ignore and TODO it... not worth wasting any more time on". It's meant to be a tool to help developers and teammates, not restrict them, and most of the time it's not very different than using JSDoc comments.

Typescript is very much an 80/20 tool, as in 80% of it is very easy to learn (literally just telling the IDE "this var must be a string" or "this object must have these keys and these value types"). For your average codebase, those are generally the more useful parts of it, and that part only takes a few hours to learn. Yes, there's that 20% of it that's harder to wrap your head around, but that constitutes very little of day-to-day work in my experience.

Where it gets complicated is if you end up needing to write library code for re-use, especially external re-use. Then generics etc come into play and the syntax becomes less readable, e.g. https://github.com/googol/DefinitelyTyped/blob/6836f798cb186...

But you can totally get by with a weekend of self-teaching, maybe a demo project or two – find your favorite old single-purpose NPM package and rewrite it in Typescript – and then learn on the job. Go through a few tutorials and produce some workable sample repos and then just be honest that it's something you picked up later in your career while you were focused on more bigger-picture things, but this repo demonstrates the basics, and you spent extra time focusing on _____ and _____ (whatever you found complex or struggled with).

IMHO only, but if a senior is wasting their time creating super-detailed typedefs for everything, something is wrong with the team/project organization. There are much bigger fish to fry, like architecture, async, state sharing, UX, readability, code review & QA processes, etc. And even among the nitty-gritty, there's much more complicated nuances to tackle, like how Next.js caching works in different routing and async models, when/how to best use SVG/Canvas/WebGL/WebGPU/Web Workers/WASM. Nobody is going to sweat an unfinished typedef here or there, and sometimes a simple but well-written comment can be a lot more useful than just a technically "correct" typedef that the juniors can't even read.

All the roles say Typescript because that's just what everyone uses now, just like destructuring or other ES6 features are taken for granted. But Typescript doesn't make a break a senior (or any dev), IMO, it's just something to learn and use as appropriate, to the extent appropriate for any given team or project. ChatGPT is also increasingly good at it and can save hours of manual definitions (but always double-check its output, as usual).

Sorry, not a direct answer to your question since I'm not a hiring manager, but just echoing what others have said... it's really not that big a deal. I've never been quizzed on Typescript specifically, and the teams I've been on would routinely simplify (dumb down) types when we refactor code, just to save time. It's not meant to be an exercise in code prowess, just another documentation & write-time testing tool.