Ask HN: Why do interviewers hate anti-TypeScript opinions?

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

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.

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.

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

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

+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?"

I've been using javascript since it was invented. I don't like typescript.

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

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,

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.

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?

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?

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.

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.

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.

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.

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