Ask HN: Why do interviewers hate anti-TypeScript opinions?
48 comments
I believe in "Pay your dues". Firmly. In an interview, you shouldn't argue on JSDocs vs Typescript. Your job is to determine if this is a good team/company for you to work with and you are getting the money/benefits that you are ok with. That's it.
Get the job first if the basics check out. Then "pay your dues". Show that you are a good team member who is not just complaining but actually getting things done with the resources given. You may be right in your argument but make that point once you have the trust of the team. Not before that.
Also, there is a reason why things are done in a certain way at a certain company/team. It may not be perfect or ideal but you need to first understand the background/why. Then if you feel that you have a case to make, make it.
But first, Pay your dues.
Get the job first if the basics check out. Then "pay your dues". Show that you are a good team member who is not just complaining but actually getting things done with the resources given. You may be right in your argument but make that point once you have the trust of the team. Not before that.
Also, there is a reason why things are done in a certain way at a certain company/team. It may not be perfect or ideal but you need to first understand the background/why. Then if you feel that you have a case to make, make it.
But first, Pay your dues.
There is a lot of value in being a team player.
A guy on my team is in love with FastAPI, yet a big project we need to integrate with uses Flask. Instead of just using Flask, he ranted on it until the lead architect on the project built a FastAPI implementation just for him... and then he never used it. This was probably for the best, as having random sections in FastAPI for no good reason would just make the code base harder to work with for every other dev who was familiar with Flask, but probably hadn't worked with FastAPI.
If a company is using TS, use TS. Being the lone hold out makes it harder on everyone. Consistency is more important than minor differences of opinion.
A guy on my team is in love with FastAPI, yet a big project we need to integrate with uses Flask. Instead of just using Flask, he ranted on it until the lead architect on the project built a FastAPI implementation just for him... and then he never used it. This was probably for the best, as having random sections in FastAPI for no good reason would just make the code base harder to work with for every other dev who was familiar with Flask, but probably hadn't worked with FastAPI.
If a company is using TS, use TS. Being the lone hold out makes it harder on everyone. Consistency is more important than minor differences of opinion.
Don't speak ill-will of anything or anyone in an interview, it's not going to bode well for you. At a minimum, people don't want to work with people who focus on the negative
I have the same opinion. I don’t see the value in having this discussion in an interview - save it for your blog. That being said, there definitely is value in being capable of discussing type safety as a tradeoff when making architecture decisions, I don’t think anyone competent would argue that there are zero scenarios where type safety is part of constraints/worthy of discussion. And OP has some great opinions about this, given they have actual experience in a project where that had to be addressed, which gives them context about a problem their colleagues might not have (which is why we hire people).
Depends on how hard you need the job and how you tell it.
If you see the interview as on equal footing (they want to learn whether you fit the job and company, you want to learn whether the company and job fit you), you can be a bit critical.
You can do that without being negative, though. Knowing of a rough corner in their startup, you can ask “How did you avoid running into Foo?” or “how did you find time to move to 100% TypeScript?”.
If you see the interview as on equal footing (they want to learn whether you fit the job and company, you want to learn whether the company and job fit you), you can be a bit critical.
You can do that without being negative, though. Knowing of a rough corner in their startup, you can ask “How did you avoid running into Foo?” or “how did you find time to move to 100% TypeScript?”.
> people don't want to work with people who focus on the negative
This is true. And yet, those who focus on the negative are the ones who are responsible for the most significant improvements because of their lack of complacency. But in the context of corporate software engineering, who cares about significant improvements? Not me!
This is true. And yet, those who focus on the negative are the ones who are responsible for the most significant improvements because of their lack of complacency. But in the context of corporate software engineering, who cares about significant improvements? Not me!
I would counter that those that make the most significant improvements can see the gaps, but focus on, and communicate effectively, the opportunity rather than being complainer. I think we will all agree the workplace is as much politics as it is technical prowess
I tell every person that I interview both that I want to hear their true opinions on technologies and tools that have worked favorably for them as well as technologies and tools that they were disappointed by.
Anyone who has ONLY favorably opinions of the tools and technologies they have been exposed to probably has not been working in technology for very long at all -- or they are afraid the interviewer will think poorly of them, which is regrettable in my opinion).
Anyone who has ONLY favorably opinions of the tools and technologies they have been exposed to probably has not been working in technology for very long at all -- or they are afraid the interviewer will think poorly of them, which is regrettable in my opinion).
People also ask "what is your greatest weakness?" - good luck to anyone thoughtful enough to know a real answer and thoughtless enough to tell it honestly. That interview question is fair but there is a decent chance here that it selects for people who are good at answering hard-to-answer questions more than anything else. It pushes for someone who can fabricate inoffensive but plausible answers.
Selecting people with high verbal and social intelligence isn't a bad interview strategy though.
Selecting people with high verbal and social intelligence isn't a bad interview strategy though.
Personally, if I would be interviewing you for a job and you say the above then I get the feeling it might be struggle to work with you due to your strong views about the usefulness of TypeScript.
Especially, when there is a company wide agreement to use TypeScript. No one, wants to keep having discussions with a new colleague about why not to use jsdocs for type annotations. Time better spend on other things.
Especially, when there is a company wide agreement to use TypeScript. No one, wants to keep having discussions with a new colleague about why not to use jsdocs for type annotations. Time better spend on other things.
Obviously I am just guessing since I was not in any of these interviews but this sounds like a case of how you say something mattering more than what you say.
Maybe try to do some practice interviews with someone you know to see how it comes across from their perspective?
Maybe try to do some practice interviews with someone you know to see how it comes across from their perspective?
Right, I'd imagine this comes up when OP mention JSDoc and the interviewer asks "Why didn't you use TypeScript?".
Instead of going into an 10 minute rant about how you are holier-than-thou, just say "Oh the framework was a few years old and we had issues getting it to work with TypeScript, so we used JSDoc instead".
As others say, an interview is not the place to express your contrarian viewpoints. You will just come across as someone who is hard to work with.
Instead of going into an 10 minute rant about how you are holier-than-thou, just say "Oh the framework was a few years old and we had issues getting it to work with TypeScript, so we used JSDoc instead".
As others say, an interview is not the place to express your contrarian viewpoints. You will just come across as someone who is hard to work with.
The issue is this:
For all the developers out there, there are extremely few who understand CS concepts well enough to build things correctly.
For most of them, their knowledge is in a form of map, where they just remember how to do certain things and when they need to do that, they just follow the template that they remember.
As such, to make use of those developers, you basically need to provide handholding for them as much as possible. This is pretty much the reason for things like OOP, frameworks like React, Type safety, e.t.c. All of these basically restrict what the developer can write in order to match the defined "API" as provided by those language features.
And because things need to move forward, the optimal setup from a business perspective is to adopt a strict framework and make use of the developers, rather than focus on hiring the very few talented developers.
For all the developers out there, there are extremely few who understand CS concepts well enough to build things correctly.
For most of them, their knowledge is in a form of map, where they just remember how to do certain things and when they need to do that, they just follow the template that they remember.
As such, to make use of those developers, you basically need to provide handholding for them as much as possible. This is pretty much the reason for things like OOP, frameworks like React, Type safety, e.t.c. All of these basically restrict what the developer can write in order to match the defined "API" as provided by those language features.
And because things need to move forward, the optimal setup from a business perspective is to adopt a strict framework and make use of the developers, rather than focus on hiring the very few talented developers.
> As such, to make use of those developers, you basically need to provide handholding for them as much as possible. This is pretty much the reason for things like OOP, frameworks like React, Type safety, e.t.c.
It’s rare to see the “C is great, it’s the developers who are the problem” opinion in 2024
It’s rare to see the “C is great, it’s the developers who are the problem” opinion in 2024
I cannot imagine every giving a thumbs-up to hire a programmer who "just follow[s] the template they remember" and doesn't understand CS.
Yes, but would you rather get a job at that kind of place? A place that thinks either a) or b) dogmatically enough that it won't hire people on that basis? It won't be just the hiring process - that kind of dogmatic mindset is going to affect working there too.
If you’re basing your preference on hard earned experience, then it could be a valuable thing to talk about. There are plenty of valid and nuanced tradeoffs you can talk about, and even use as demonstrable evidence of your hard-earned experience.
But you’ve got to tread the line carefully, treating it more as an academic discussion than a sermon. If you can’t strike that balance, then don’t bring it up (and if you’re so dogmatic about it anyway, then don’t work there).
It’s perhaps revealing that you consider the interviewers to be dogmatic. Are you sure that you aren’t the one coming off as dogmatic?
But you’ve got to tread the line carefully, treating it more as an academic discussion than a sermon. If you can’t strike that balance, then don’t bring it up (and if you’re so dogmatic about it anyway, then don’t work there).
It’s perhaps revealing that you consider the interviewers to be dogmatic. Are you sure that you aren’t the one coming off as dogmatic?
I'm confused; how is jsdoc an alternative to typescript? They serve totally different functions.
Personally I don't think there's any good argument not to use typescript over javascript
Personally I don't think there's any good argument not to use typescript over javascript
Jsdoc is a way of adding type annotations to JavaScript code, which can then be used by another tool to do type checking.
This is how type checking works in python and ruby, rather than there being a compilation step like typescript.
This is how type checking works in python and ruby, rather than there being a compilation step like typescript.
Well python allows for type annotations as part of the language; javascript does not, so the compilation stage in typescript is just about erasing types for the most part (typescript tries to have minimal impact on the runtime). It just seems like a worse option than typescript's syntax. Bun runs typescript natively without doing any of the type checking
Even though type annotations are part of the language now in Python, they aren’t used by the runtime so it is still essentially the same as jsdoc or sorbet style type checking. More like a really powerful linter than a transpiler like typescript.
Before type annotations were officially added in python 3.5, you could still use mypy for type checking. The only difference being that the type hint format wasn’t standardized across tools.
Before type annotations were officially added in python 3.5, you could still use mypy for type checking. The only difference being that the type hint format wasn’t standardized across tools.
But...TypeScript is the same, types are not used by the runtime.
With types as jsdoc annotations there is no compilation step at all, no matter where the script runs. Have your cake and eat it.
JSDoc is strictly less powerful than TypeScript though. For example, more complex types as well as template literal types are impossible to have in JSDoc. It is simply more ergonomic to use TypeScript instead of JSDoc.
Are you saying there isn't any tool which checks whether you're using your types correctly? If not, then the two aren't comparable at all
There are tools that check whether you are using your types correctly. They work like linters, where you get hints in your IDE and you can run it across the whole project looking for problems when you want to.
The difference between this approach and the typescript approach is that typescript isn’t valid JavaScript, you need a build step that converts it. JavaScript with JSDoc type annotations is valid JavaScript, just with special comments in it, so it doesn’t need to be converted before it is run.
The difference between this approach and the typescript approach is that typescript isn’t valid JavaScript, you need a build step that converts it. JavaScript with JSDoc type annotations is valid JavaScript, just with special comments in it, so it doesn’t need to be converted before it is run.
How would you implement an interface in jsdoc, since interfaces aren't valid javascript
You wouldn't implement an interface per say. You would implement a JSDoc type annotation which you can then attach to a doc string for a function input or return.
Next time you try to use that function the tooling (VS Code) will highlight the Type required by it as both documentation and a dynamic check - this fn input is missing X property.
Imagine it as a TS light version, where tooling and docs helps you write well-documented typed code that isn't checked for validity at compilation.
All the logic that is important is typed: all inputs, outputs. Each function is documented in terms of the program IO and what it should do and why (description).
There's no typed guard rails in place. You could pass an object that doesnt follow a type, but with team agreements, reviews, testing, and diligence you wouldn't. In TS you bypass process because the compiler does those checks for you.
To actually force runtime compliance to types and further get to a statically typed vision I used object validation schema. Each complex fn input would have a schema and we would validate against that.
In such a way you have some typing, documentation, and some static typing.
Since JS was never build with types or static typing as a first class citizen (like other languages are) there's less friction in scenarios where JS is too multifaceted or loose. This is the "have your cake and ear it" reply: you have types, documentation, runtime type checks for what matters, but you stay native to JS and avoid full static typing, remove the need for TS compiler.
Next time you try to use that function the tooling (VS Code) will highlight the Type required by it as both documentation and a dynamic check - this fn input is missing X property.
Imagine it as a TS light version, where tooling and docs helps you write well-documented typed code that isn't checked for validity at compilation.
All the logic that is important is typed: all inputs, outputs. Each function is documented in terms of the program IO and what it should do and why (description).
There's no typed guard rails in place. You could pass an object that doesnt follow a type, but with team agreements, reviews, testing, and diligence you wouldn't. In TS you bypass process because the compiler does those checks for you.
To actually force runtime compliance to types and further get to a statically typed vision I used object validation schema. Each complex fn input would have a schema and we would validate against that.
In such a way you have some typing, documentation, and some static typing.
Since JS was never build with types or static typing as a first class citizen (like other languages are) there's less friction in scenarios where JS is too multifaceted or loose. This is the "have your cake and ear it" reply: you have types, documentation, runtime type checks for what matters, but you stay native to JS and avoid full static typing, remove the need for TS compiler.
It's a perfectly valid view and if the interviewer values dogma more than the ability to look at pros and cons (and the willingness to go along with the "good-enough" solution the team already has momentum towards), then that's on them. Lose-lose for everyone, but that's how it goes sometimes.
Edit: I think this would be much easier to accept if the job market weren't so tough right now. You could shop around for an employer better aligned and who "gets it."
Edit: I think this would be much easier to accept if the job market weren't so tough right now. You could shop around for an employer better aligned and who "gets it."
+1 for not bringing up (even arguably) negative topics or discussing "dislikes" in an interview.
Sort've reminds me of that quote "Do you want to be right, or do you want to be married?"
Sort've reminds me of that quote "Do you want to be right, or do you want to be married?"
I don't totally get this point of view. What if your job involves evaluating things with trade offs?
OP didn't say they disliked TypeScript, just that it might not be the solution for all problems.
OP didn't say they disliked TypeScript, just that it might not be the solution for all problems.
OP has made some questionable statements, that if said on an interview, would be a big red flag for me
> I also can wager that most people don't need type safety enough to ...
I think most of the industry has decided type safety is worth the effort
> For the tin hat owners out there ...
Dawning tinfoil hat ideas is definitely no-go territory in interviews
---
There is a difference between evaluating tradeoffs and coming off as a highly opinionated person that will make such discussions more difficult than they need to be
> I also can wager that most people don't need type safety enough to ...
I think most of the industry has decided type safety is worth the effort
> For the tin hat owners out there ...
Dawning tinfoil hat ideas is definitely no-go territory in interviews
---
There is a difference between evaluating tradeoffs and coming off as a highly opinionated person that will make such discussions more difficult than they need to be
That's fair I guess. JSDoc over TS for a legacy codebase strikes me as a good decision.
Maybe, maybe not, it's context / company dependent decision. A full rewrite is an opportunity to pay down other technical debt at the same time, or open the door to fully new approaches.
It's more about how one engages in such a debate than the merits looking in from the outside. OP wanted to know why they are having issues in interviews, their language / approach is probably the root cause, not the merits.
It's more about how one engages in such a debate than the merits looking in from the outside. OP wanted to know why they are having issues in interviews, their language / approach is probably the root cause, not the merits.
I've been using javascript since it was invented. I don't like typescript.
1. Butthurt ranting in any interview is a no go.
2. The way to present your ideas does matter. You can cheer for the beauty and elegance of something without throwing dirt at another thing
3. Devs who claim themselves to be ts-demigods (also counts for other tech ofc) but are only hunting for the newest hackiest way of creating code that noone besides them understands, can kill ur project in the same way as the java8 dev who hasn't looked at different languages or tools in 10 years and is busy debugging nullpointers for 10h a day.
2. The way to present your ideas does matter. You can cheer for the beauty and elegance of something without throwing dirt at another thing
3. Devs who claim themselves to be ts-demigods (also counts for other tech ofc) but are only hunting for the newest hackiest way of creating code that noone besides them understands, can kill ur project in the same way as the java8 dev who hasn't looked at different languages or tools in 10 years and is busy debugging nullpointers for 10h a day.
There could be many reasons for this – one of which might just be bad luck. However, if you're interviewing for companies that use TS then talking it down is obviously a risky move given the company probably chose it because employees liked it and you might be competing with other candidates that share their favourable view of it. Even if you're right in your criticisms you're basically just outing yourself as someone who could cause conflicts with the existing team. And if not articulating your criticisms well then those criticisms may be perceived as a lack of understanding of knowledge / understanding.
I'm not saying anything new here, but most people in tech gravitate towards the most popular technologies and opinions because it's safer to do so – reiterating the popular opinion tends to be rewarded in corporate environments. Is React really the best technology for most websites? Probably not, but that doesn't stop it being the go to these days. 1, because it's what know; and 2, because no one is going to be criticised for building something in React given its adoption and approval.
But perhaps a better example here might be JSX. I remember how when JSX was first demoed people on HN were highly critical of it, but as it began to be adopted those criticisms faded and were eventually replaced with approval. In general people like what they know. New ideas tend to be received with a high degree of scepticism and popular ideas tend to guarded. JSX didn't change, but adoption changed and this changed opinion.
TS in my opinion is an imperfect solution to type safety in JS, but despite its imperfections it's a pretty damn good solution – and its a solution that's been widely adopted. I suspect even you'd admit that JSDocs isn't perfect either – even if it does have some advantages to TS. However what's indisputable is that JSDocs is much less adopted, and I'd argue adoption is an important consideration when picking technologies because a core part of writing good code is writing code others can understand and can maintain.
That said, if I were interviewing you so long as you could see both sides and expressed a generally positive attitude towards TS I'd appreciate your ability to express a unique and critical opinion, but you should understand that many will be hostile given your providing a view that isn't widely held.
You should also keep in mind that interviewing tends to be a process to screen out bad candidates rather than a process to find the most competent candidates. Interviewers typically want to confirm you have the right experience and that you can work well with the existing team and technologies. While your criticisms may be valid they may not be well received during an interview that wants to simply establish your proficiency with TS.
I always advise people to not taking interviews personally. Interviews are brutal. Interviewers often have several candidates to consider and their decisions can be influenced by when they last ate and how much sleep they got last night. Even if all the candidates are great they still need to make arbitrary decisions about which candidates to reject and which to proceed with, and your slightly more hostile attitude might be all it takes to put you on the rejection list. You need to have several data points before you take anything said in an interview onboard because it's almost all noise.
I've been rejected for some silly reasons before, but to be fair to the interviewers almost all of the time I can understand why they made their decision. Generally it's because I didn't do a good job at clearly communicating why I'd be a good pick for the role. If I can offer you advice, try not to over think things in interviews. Specifically, it's almost always better to give a clear and concise answer than giving a complicated nuanced opinion. Always try to understand what the interview is screening for and seek to reassure that you're the right person for the job. For example:
Interviewer: "We use TS a lot here. What your experience with TS and whats your opinion of it?"
You: "I have a lot of experience with TS and have used it at company a, b and c. Generally I view it very positively and enjoy using it. I think type safety is an important part of writing stable bug free code."
Only if pushed to be critical of TS should you offer a criticism, and even then I would be very careful about how critical you're being. Here I think contrasting it with some of the advantages of JSDocs would be very well received, but to starting talking about how you prefer JSDocs prior to this would only cast doubts about your fit for the role.
I'm not saying anything new here, but most people in tech gravitate towards the most popular technologies and opinions because it's safer to do so – reiterating the popular opinion tends to be rewarded in corporate environments. Is React really the best technology for most websites? Probably not, but that doesn't stop it being the go to these days. 1, because it's what know; and 2, because no one is going to be criticised for building something in React given its adoption and approval.
But perhaps a better example here might be JSX. I remember how when JSX was first demoed people on HN were highly critical of it, but as it began to be adopted those criticisms faded and were eventually replaced with approval. In general people like what they know. New ideas tend to be received with a high degree of scepticism and popular ideas tend to guarded. JSX didn't change, but adoption changed and this changed opinion.
TS in my opinion is an imperfect solution to type safety in JS, but despite its imperfections it's a pretty damn good solution – and its a solution that's been widely adopted. I suspect even you'd admit that JSDocs isn't perfect either – even if it does have some advantages to TS. However what's indisputable is that JSDocs is much less adopted, and I'd argue adoption is an important consideration when picking technologies because a core part of writing good code is writing code others can understand and can maintain.
That said, if I were interviewing you so long as you could see both sides and expressed a generally positive attitude towards TS I'd appreciate your ability to express a unique and critical opinion, but you should understand that many will be hostile given your providing a view that isn't widely held.
You should also keep in mind that interviewing tends to be a process to screen out bad candidates rather than a process to find the most competent candidates. Interviewers typically want to confirm you have the right experience and that you can work well with the existing team and technologies. While your criticisms may be valid they may not be well received during an interview that wants to simply establish your proficiency with TS.
I always advise people to not taking interviews personally. Interviews are brutal. Interviewers often have several candidates to consider and their decisions can be influenced by when they last ate and how much sleep they got last night. Even if all the candidates are great they still need to make arbitrary decisions about which candidates to reject and which to proceed with, and your slightly more hostile attitude might be all it takes to put you on the rejection list. You need to have several data points before you take anything said in an interview onboard because it's almost all noise.
I've been rejected for some silly reasons before, but to be fair to the interviewers almost all of the time I can understand why they made their decision. Generally it's because I didn't do a good job at clearly communicating why I'd be a good pick for the role. If I can offer you advice, try not to over think things in interviews. Specifically, it's almost always better to give a clear and concise answer than giving a complicated nuanced opinion. Always try to understand what the interview is screening for and seek to reassure that you're the right person for the job. For example:
Interviewer: "We use TS a lot here. What your experience with TS and whats your opinion of it?"
You: "I have a lot of experience with TS and have used it at company a, b and c. Generally I view it very positively and enjoy using it. I think type safety is an important part of writing stable bug free code."
Only if pushed to be critical of TS should you offer a criticism, and even then I would be very careful about how critical you're being. Here I think contrasting it with some of the advantages of JSDocs would be very well received, but to starting talking about how you prefer JSDocs prior to this would only cast doubts about your fit for the role.
> However what's indisputable is that JSDocs is much less adopted
That's partially true. Every project not using typescript is using JSDoc if they want to create types for it. There are way more JS projects than TS out there.
That's partially true. Every project not using typescript is using JSDoc if they want to create types for it. There are way more JS projects than TS out there.
Have you worked on any project that had more than you on it?
More than 5?
What about an org of hundreds of people? What about thousands?
I think your sentiment of not wanting to use TS is fine if you are working on hobby code or at a small company that’s fine being in their lane. Where you are the guy, or you and a few others are the “dev team”.
When you cross into organizational efficiency concerns because you have hundreds of people across geographies, where you can’t just go get coffee with them to talk about how something can be refactored to be like the 10x engineer you follow on dev.to (sarcasm btw).
TS works for these kinds of companies. TS is great for enterprises.
JS is a shitty language if you never graduate past the realization that almost all languages and technologies are shitty in many ways. You’re being hired to fuel a business, not your ego. And without this business you’re not earning a living, and probably not one as great as the one you’d have yolo-wrangling horrible code only you understand. Your goal is to build something optimal given a bunch of limitations.
You mentioned Rust and Haskell. I don’t know if you’ve worked with these professionally, but the number of candidates for these roles is far less than TS/JS. I’ve never met a Rust engineer who was making peanuts. I’ve also not met a Rust engineer who was dumb. Nobody is going to use Rust (except hobbyists) to do what they would use something like node for. What problem are you solving? IO bound? CPU bound? Distributed workloads? Come on..
So understand why enterprises choose particular technologies. I can tell from your post you don’t have the level of experience you think you have.
And yes if I sound triggered it’s because I’ve interviewed too many combative people like this who can’t back up anything beyond feels or what someone else said. It’s nothing personal against you, it’s me.
Best,
More than 5?
What about an org of hundreds of people? What about thousands?
I think your sentiment of not wanting to use TS is fine if you are working on hobby code or at a small company that’s fine being in their lane. Where you are the guy, or you and a few others are the “dev team”.
When you cross into organizational efficiency concerns because you have hundreds of people across geographies, where you can’t just go get coffee with them to talk about how something can be refactored to be like the 10x engineer you follow on dev.to (sarcasm btw).
TS works for these kinds of companies. TS is great for enterprises.
JS is a shitty language if you never graduate past the realization that almost all languages and technologies are shitty in many ways. You’re being hired to fuel a business, not your ego. And without this business you’re not earning a living, and probably not one as great as the one you’d have yolo-wrangling horrible code only you understand. Your goal is to build something optimal given a bunch of limitations.
You mentioned Rust and Haskell. I don’t know if you’ve worked with these professionally, but the number of candidates for these roles is far less than TS/JS. I’ve never met a Rust engineer who was making peanuts. I’ve also not met a Rust engineer who was dumb. Nobody is going to use Rust (except hobbyists) to do what they would use something like node for. What problem are you solving? IO bound? CPU bound? Distributed workloads? Come on..
So understand why enterprises choose particular technologies. I can tell from your post you don’t have the level of experience you think you have.
And yes if I sound triggered it’s because I’ve interviewed too many combative people like this who can’t back up anything beyond feels or what someone else said. It’s nothing personal against you, it’s me.
Best,
Exactly my sentiment. The only people I've met who are anti-TS are one of the following:
* Extremely opinionated people that are difficult to work with.
* Engineers who have only worked on smaller projects or codebases, and therefore haven't seen firsthand the real benefits of a typed codebase
* Non-FE engineers who just generally hate all JS-related stuff, and frequently opine that FE engineers aren't real engineers and have to re-learn the "latest fad framework" every year.
If I am interviewing someone and they start (likely unprompted) ragging on Typescript, there's a 95% chance one or more of the above bullet points describes them. Safer to move on to another candidate rather than take the chance that they're the other 5%.
* Extremely opinionated people that are difficult to work with.
* Engineers who have only worked on smaller projects or codebases, and therefore haven't seen firsthand the real benefits of a typed codebase
* Non-FE engineers who just generally hate all JS-related stuff, and frequently opine that FE engineers aren't real engineers and have to re-learn the "latest fad framework" every year.
If I am interviewing someone and they start (likely unprompted) ragging on Typescript, there's a 95% chance one or more of the above bullet points describes them. Safer to move on to another candidate rather than take the chance that they're the other 5%.
I'm a senior dev who works on an app you've almost certainly used. Some of us just think the overhead of typescript is silly when you have react propTypes and whatnot.
In general, I'm an alpinist. Bring only what you need.
In general, I'm an alpinist. Bring only what you need.
Indeed. If I were interviewing a candidate like OP who starts ragging on TypeScript, I'd move them immediately into the "do not hire" pile. What you do in your own time programming-wise is vastly different to what you need to do working in an enterprise with many others.
The above experience is production experience where the decision to use JSDocs allowed us to focus on features over a TS rewrite, maintaining two codebases for multiple years with that strategy whilst vastly improving the type safety and documentation - from no types to full coverage and validation on the backend.
And prior to my current role I've used TS in production too.
Your response is exactly the sort of snap decision that I might have experienced.
And it's one that I find confusing in light of passion for type safety and type checking.
And prior to my current role I've used TS in production too.
Your response is exactly the sort of snap decision that I might have experienced.
And it's one that I find confusing in light of passion for type safety and type checking.
TypeScript is also incrementally adoptable, not sure how you were able to add JSDoc comments for types to a function for example while also being unable to convert that same function to TypeScript. JSDoc is strictly less powerful than TypeScript in general. For example, more complex types as well as template literal types are impossible to have in JSDoc. It is simply more ergonomic to use TypeScript instead of JSDoc, and therefore, I stand by my snap decision.
Agree on all points.
employers are looking to hire people with the same opinions as them to execute harmoniously on a playbook strategy that has already been established. So yes, if you want that job, tell em what they want to hear
I think the term is Mirrortocracy
https://carlos.bueno.org/2014/06/mirrortocracy.html
https://carlos.bueno.org/2014/06/mirrortocracy.html
They're likely using TS and not really interested in talking about why you feel it's not "needed".
In an interview setting, it probably would make more sense to discuss its sharp edges or ways in which it can be clumsy. That is, issues that arise with using it every day, not discussing the concept of whether or not it should be used, since that ship has probably already sailed. In that case, stuff like "it requires a build step and you have to type more" is not going to be super convincing and could give an impression you didn't intend to give.
In an interview setting, it probably would make more sense to discuss its sharp edges or ways in which it can be clumsy. That is, issues that arise with using it every day, not discussing the concept of whether or not it should be used, since that ship has probably already sailed. In that case, stuff like "it requires a build step and you have to type more" is not going to be super convincing and could give an impression you didn't intend to give.
I'm an experienced web dev and I've recently been interviewing for new fullstack role.
# background
Previous role I used TS everyday for all types of developement: api development and frontend via React.
In my current role I inherited an non-typed codebase and I decided to use JSDocs vs Typescript.
I made that decision because I knew that our older monolith framework and setup would cause compilation issues with TS and I wanted my future self and new developers to focus their skills on other problems with higher ROI: building features, refactoring code.
JSDocs didn't mean we were cowboys: we implemented tests, we implemented JSDoc docs and type annotations, we implemented object schema validation.
We cared about the same things that TS cares about. We only said no to the compulation step and all the problems that may arrise from that sub-system.
# views
I don't believe that TS should be tech that is blindly implented for all types of apps.
I also can wager that most people don't need type safety enough to face some of the random issues caused by the compilation step of TS.
The reality is that TS adds type safety into a language ecosystem that is not built for it. We've made serious serious strides towards full support, but not enough to make it clean sailing.
Type-safety in Haskell or Rust is an entirely different story.
Weirdly I'm not alone in this view with big profile pundits like Rich Harris (SvelteJS) prefering JSDocs over TS because there's less friction when using a non-standard language.
For the tin hat owners out there there's also problem of TS being largely driven by a corporate sponsor, and like React, this setup produces a roadmap that can be at odds with the needs of smaller companies that use the project (breaking changes, fast major version api changes, deprecation of features, adding of new features that increase compilation, hurt performance etc)
# recent job hunting experience
Each time I've mentioned these views in recent interviews I've been labeled as not technical enough to work on TS projects.
It seems to me like there might be some dogmatic views at play here: - a) if you dont use/support TS you hate type safety - b) if you dont favour TS you dont understand TS enough to work with it
I'm very confused by how these events have played out and I wanted to share that with others.
I welcome any and all pro/cons comments on this.
As for me going forward? I'm going to keep my TS views to myself because I'd rather get a job than be right.