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.
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.
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.
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?”.
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!
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).
Selecting people with high verbal and social intelligence isn't a bad interview strategy though.
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.
Maybe try to do some practice interviews with someone you know to see how it comes across from their perspective?
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.
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.
It’s rare to see the “C is great, it’s the developers who are the problem” opinion in 2024
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?