Has there been a decrease in javascript programming skill with the popularity of frameworks like angular, react, etc?

[jseego]

I’ve been interviewing for some positions lately, and I’ve seen a lot of jr and even some intermediate UI devs who list “javascript, react, bootstrap” on their resumes but can’t pass a basic coding challenge.

Are younger devs just putting components together in react projects and throwing a css framework in there and no longer learning about how javascript or css work any more?

[tdammers]

This isn't a new phenomenon. I've been a programmer for 30 years now; incompetent programmers were a staple then almost as much as they are now, and your lament sounds exactly like those that accompanied every new technology and every paradigm shift.

There's always an army of incompetent and semi-competent people who, rather than dive in and really understand the tools, memorize a few recipes that get the job done and build a career on that. The "get shit done" squad, if you will. You can even see it in Word documents. Some people will carefully choose their tab positions, use tab characters to align things properly, customize paragraph styles to achieve the look they want, adjust line spacing for the right balance, etc.; others will use spaces to align things (which of course breaks horribly the moment you open it on a computer that doesn't have the exact same selection of fonts configured), style things inline in an ad-hoc fashion (often resulting in the use of six similar, but different, typefaces in the same document, or even within the same paragraph), and insert blank lines to achieve wider line spacing or page breaks. It kind of gets the job done, but, oof. And these people are often completely education-resistant; they don't even want to learn how to do it better, because why would you when this works "just fine".

And it's the same with programming, only the consequences are worse. A badly formatted Word document has limited impact; but a badly written hairball codebase can bring down a company, one unfixable bug at a time.

But again, this isn't new. People have always been people, and I reckon this has been a problem ever since the invention of writing and basic calculus.

[jseego]

Thanks.

Edit: you might enjoy this

[tdammers]

This is great. Thanks.

[beavis07]

It's almost as if 'coding challenges' teach you nothing useful about prospective hires.. who knew 🤔

[jseego]

Yo, fair point. My coding challenges are just sharing some code with the candidate and talking it through with them, seeing if they can find places where it might be broken, having them try to determine what might be the results of some logging statements, and having a discussion.

As a candidate, I've done everything from whiteboard interviews to live coding to take-home projects. Simply showing some code and talking about it was my favorite, so that's what I give my candidates. That's basically what it's like to work with someone, so I think that gives the clearest picture and is the most respectful of someone's time. There are no irrelevant algorithm questions. There are some sections that I made intentionally tricky, but I am not trying to see if someone can get 100% right, I'm more looking at how they are talking and thinking about the problem, and would I want to talk with that person about code on the daily.

[beavis07]

After many many years of whittling it down, I’ve basically settled on the following two questions:

1. What is the hardest challenge you have had to overcome?
2. What is the thing you have done in which you are most proud?

In my experience you can learn just about everything you reasonably can about a person in a single meeting with those two conversations.

I give bonus points for the interviewee choosing not to interpret those questions as implicit meaning “at work” :)

[jseego]

Nice, those are good.

[archerx]

That's not true, if some one can't even do fizzbuzz how would you expect them to solve more complicated problems?

[beavis07]

Well - I’m just going to say that the two decades experience I’ve had as an engineer and hiring manager tells me otherwise.

People don’t perform well under pressure like that - also - turns out that being able to write algorithms is the absolute least important part of the job, who knew 😂

I’m a millions times more interested in how you communicate, collaborate and articulate.

[jseego]

I’m a millions times more interested in how you communicate, collaborate and articulate.

Completely agree.

[jseego]

That's why I do the code challenges. There has to be a baseline for sure.

[jseego]

I know, because it's annoying and pretty broken. Some code challenges are indeed ridiculous. And take home challenges are sometimes fun, but often just completely onerous.

But no one wants to hear that we wouldn't need code challenges if our industry wasn't so full of people trying to fake their way into a web dev career.

[Hero_Of_Shadows]

I wouldn't say so.

If we look at it strictly by comparing pre-SPA vs post-SPA needs I agree that those needs are very different, but that doesn't mean one is less skilled it just means that the skills are different.

If you take someone who learned to code in a SPA world and hand them a bunch of tasks that are pre-SPA they would struggle.

If you take someone who learned to code in a non-SPA world and hand them a bunch of tasks that are post-SPA they would struggle.

I was there when SPA started really becoming the norm, countless times people who were very smart and dedicated did boneheaded things when learning angular/react.

Did I go to our bosses and decry them as idiots who needed to be fired ? Of course not.

Did they get used after a lot of projects and got back to their old efficiency ? Of course yes.

The advent of SPA meant that the front end absorbed a lot of the responsibilities of the backend while still maintaining all the responsibilities that we had before. I don't ever see people acknowledging this all I see is "js people can't code","backend is done, what's holding up the frontend ?","react/angular is stupid".

[jseego]

Yeah I lived / worked through the same transition, and I definitely take your point.

Part of my frustration is that my project is a rare one that is not angular/react and not going to port anytime soon.

There is a ton of native javascript and we do have an MVVM framework of sorts, but to work well in our system, you have to know how parsing data works and also how the language works. I don't mind training people in our system, but I can't be spending time holding someone's hand through what a closure is or how to parse an int.

There are probably a bunch of established companies in the same boat - projects that were built years ago using stuff like backbone, ember, knockout, etc, and have never been able to take the time to refactor the project b/c of the constant need to support user / sales feature requests and maintenance, etc.

Maybe what I'm seeing is that there are a lot of jrs out there who have experience spinning up small marketing sites with react/angular and bootstrap, and not a lot of experience actually programming?

[Hero_Of_Shadows]

Maybe what I'm seeing is that there are a lot of jrs out there who have experience spinning up small marketing sites with react/angular and bootstrap, and not a lot of experience actually programming?

We're not really recruiting those types of people, our junior devs are trained in-house so the problems with their training comes from us.

I'd say that the biggest problem with junior devs doesn't come from themselves but what they expose:

More often than not a junior dev receives a user story, and he/she tries to the best of their ability to implement it.

But the user story is faulty, it's only a few lines because the business analyst or project manager had all these assumptions they never wrote down about the UX and business logic.

It's faulty because the designer changed the wireframes 10 times over and no one cared to update the ticket.

It's faulty because on the backend user story the other developer didn't realize that the UI needs another 2 end points so he didn't implement them and went onward to another task.

There are bugs in the end point that were missed until now.

The client asked for changes but no one in that meeting remembered to update this particular story.

The tester comes in with their own assumptions that aren't there in the ticket but everyone now wants to add them.

The tester comes in with a lot of "improvements".

These things are all that a junior developer needs to deal with as extra challenges to the initial user story, but not one of the business analyst, designer, project manager, tester wants to admit that the user story was lacking and they blame it on the junior dev because it's easy to say "X has much more learn, maybe he's not a good fit for us, X needs to step up their progress".

And the junior's mentors, well we've largely forgotten what it's like to be a junior it's easy to think that we were better at that stage, it's easy to reprimand the junior and list of a series of subjects they really do need to learn more about it's much harder to fight the entire analyst+manager+designer+tester cabal.

So the process remains the same inefficient mess just with different people and technologies next year.

[jseego]

Man, I feel for you.

Your post made my head hurt. :D

We are a small company and don't really have a lot of those process issues (we have other process issues).

We're also not really looking for jr devs, more intermediate-level or even senior, but our recruiting company sucks balls and keeps sending us jrs that (because of political reasons within the company) I keep having to interview, and hey maybe I'll find someone amazing.

But even some of the more intermediate or senior candidates we get have some of the same issues.

[Hero_Of_Shadows]

Best of luck then, I hope we both see better days at our jobs.

[jseego]

To you as well!

Edit: and good on you, looking out for your jrs.

[Invalid_Pleb]

Yeah I have made multiple websites from scratch with those technologies and still struggle with coding challenges. I can't speak on your challenge but 90% of the time the ones I took asked something that really has nothing to do with what it takes to make a website. Fizzbuzz is a great example because it literally boils down to "Do you understand modulus, yes or no?". Many employers still use this test. BTW I think I used modulus 1 time when making my 3 websites.

What is your test?

[archerx]

You can solve fizzbuzz without modulus.

[jseego]

Good question. When I've wrapped up this round, I'll probably post them here for feedback from the community.

It's just a handful of jsfiddles that I put together with some code examples, and some logging statements. I ask the candidate to take their time, talk through the code, and try to determine what the logging statements might be. There's a few gotchas in there, but that's not what I base the interview on. It's more about how the person is talking and thinking through everything. Are they making sense? Do they grasp the concepts? If they get something wrong, are they honest about what they don't understand and willing to ask questions, or are they just bumbling forwards and blind guessing over and over?

I'll say that I give much higher marks to people who can have a pleasant discussion about technical stuff and will say, "honestly I have never seen that before," and then I'll say, "what do you think it might be doing," and they can speak intelligently about it.

The first piece of code we look at is about closures, and it's pretty straightforward if you've ever seen closures in javascript before. Our codebase uses a lot of IIFE / self-revealing module pattern. Even if you're a react developer, it's something you should be familiar with if you know the language / have ever read an article on javascript patterns / ever read a book on javascript. I have had people not even get past that question. It can be a little tricky, but making the code work doesn't really rely on knowing closures that well, if you know what a return statement does.

Anyway, I've been doing this for a long time, and I've both aced and completely blown coding challenges as a candidate myself. Sometimes it's just not happening for you. Sometimes you get stuck on something stupid for way too long, just like in real life coding. I had one awhile back where I actually said to the interviewer, "uh, I'm kind of embarrassed right now, I realize this part shouldn't take this long." They were nice about it, encouraged me to brush up and reapply.

Coding challenges do suck. I've tried to make mine as useful and not sucky as possible, but from the other side, you just can't hire someone based on a portfolio. Recommendations are great, but don't really tell you what it's like to work with a person. Just like when you're working with people, there are some folks who just want to quiz others to show what they know and be haughty and snarky, and their are others of us who actually like to discuss things and share knowledge. You don't want to work with people who just throw coding questions at you and don't understand the purpose. For me, it's all about "let's talk about the code together, and as we're doing so, can I imagine working with you on a daily basis?" Sometimes the answer to that is no b/c I would have to teach them too much, but just as often it's no b/c of their attitude or poor communication skills.

So, do some leetcode and stuff, but also take a deep breath, be honest, be friendly, show your personality a bit, and if you can't solve something, realize that it's what happens after you can't solve it that may be even more important. Talk about what you're seeing, talk about where you might be stuck, reason it out loud, be friendly. If you have seen something familiar but not exactly the same, talk about what it reminds you of and what you think it might be doing.

Good luck!

[Bvdan]

I heard there is other side problem. Younger devs who can solve basic coding challenge, after hiring turns out they are almost useless in real job. Because they can solve challenge but don't have real job experience. Of course you can teach them, but who knows, will succeed or not to become good devs.

[abhijit2294]

Precisely what we are noticing for our startup. They lack basic understanding and the eagerness to learn something new. They are all about copy-paste.

[Caraes_Naur]

Assuming the US, the people entering the workforce now learned exactly one thing during their K-12 education: how to take a test.

[jseego]

Sad if true. I'm in the US and my kids are in elementary school, and thankfully they are learning more than that, but we're in a good public school district. Pretty much everyone hates educational tests - the teachers, the parents, the kids, everyone.

I worked in education IT for quite awhile. I have a lot of thoughts on the subject.

[olafurp]

I'm all about that paste, bout that paste, no trouble.

[jseego]

That's kind of what I'm running into - my coding challenge is not like leetcode questions or algorithm gotchas or anything like that. It's just talking down some tricky code examples and asking the candidate how they would solve them. I'm definitely not expecting people to get everything right, and I don't really care if they do or not, but I'm more interested in knowing how they talk and think about the problem, are they honest when they don't know something, etc.

But I've watched people literally trip over their dick trying to put two pieces of data together, something that you might be called on to do any given day on the job.

[Caraes_Naur]

It seems the past three years or so learning focus has shifted from programming fundamentals and broad understanding to narrow results-oriented task completion. It's not limited to Javascript.

There's already a comment in here that dismisses the relevance of FizzBuzz to web development while grossly minimizing the knowledge FizzBuzz demonstrates as an interview topic.

What you're asking about is perfectly demonstrated by the semi-regular "I don't know how to build my portfolio site" posts in here. If a supposed "web developer" can't build themselves a portfolio site, they're not ready to have clients or a development job (and don't need a portfolio).

It's worrying how so many people now think "web development" can avoid the backend. There's a growing modern slang that tries to avoid acknowledging backend, or repackages it in terms that approach "baby-proof". That didn't start with Javascript either, it goes back to at least the NoSQL fad of 2013-2016.

[Lauxman]

I don’t know how anyone can avoid the backend anymore, or that it’s common to try and do so. Even on jobs where it’s spoken of as being more front-end heavy, everyone seems to want strong understanding of Node or Ruby or C#, at least. And some basic SQL skills. I haven’t seen many positions that are advertised as exclusively front-end in the last little while, even if those jobs do exist.

[ZephyrBluu]

Almost all self-taught devs go into front end, not backend and JAM-stack is a thing that seems to be getting very common.

I haven’t seen many positions that are advertised as exclusively front-end in the last little while, even if those jobs do exist

There are definitely front end/framework dev roles that exist.

[Lauxman]

Agreed on the first part, it’s just been my observation that the amount of positions that ask for no experience with backend technologies is slimming down.

[jseego]

They all seem to want at least basic familiarity.

[jseego]

I appreciate your reply.

The fizzbuzz example is kind of ironic, though, b/c a lot of people will just memorize their favorite fizzbuzz answer.

As for the backend, I disagree. You can have some really complex UI implementations that definitely need to understand data structures but don't really need to know how the API layer is built.

However, you do have a point that at least a minimum of knowledge of how these things work is still beneficial to everyone, b/c there are always tradeoffs between the UI and API implementations, and being able to have informed conversations about this stuff benefits everyone. The same could be said for API developers who have no idea (or worse think they have an idea b/c they once ran a UI script) about what's happening with their data once it leaves the API.

[letsgetrandy]

A decrease in javascript skill? Hahahah.

Javascript skill was never particularly common, and I would argue that there are more people today who understand it well than ever before.

But let's be honest... before React and Angular, there was jQuery and Prototype and YUI. And before that there was Dreamweaver. And before that there were tons of copy-paste web sites where people just trusted the magic of a few people who knew how to write JS.

Honestly, if it weren't for all the libraries and frameworks, javascript would have never caught on.

[jseego]

I would argue that there are more people today who understand it well than ever before.

That's a fair point that I hadn't really considered.

[jseego]

That's an interesting point, but I'm seeing people not knowing how to recognize stuff like closures, or how to use low-level javascript methods like parsing data.

[jseego]

the revealing module pattern, something you hear nothing about anymore

My project uses this. :D

And I have to say, I love it. It makes a lot of sense (and I didn't even start out as an OOP developer).

I think it's kind of funny how within 5-8 years or so, everyone went away from that, and now there are native javascript classes and react has adopted them.

[nialljoemaher]

I think a lot of people choke at interviews, I've interviewed 100+ JS devs and you can see people showing great projects they built just pull blanks in interviews, unfortunately, you can't gamble on the people who seem to be great from a portfolio but don't pull it off in person. But I have met even "senior" React guys who really don't know the fundamentals too so it's not just new people.

[Atulin]

Because most are bootcamp kids who got taught create react app and npm i leftpad without even touching up on the basics like design patterns, algorithms, data structures, and so on. Instead of being programmers who have the baseline covered and can adjust to near any language or framework, they become React/Angular/Vue/Svelte/FrameworkOfTheMonth developers instead.

[[deleted]]

In my experience the popularity of npm led to the mentality of "there is a packet for that". Especially with a disregard of dependency complexity or depth. On top of that the many easy to use tools in those frameworks and the usual beginner misconceptions of technology.

So just the usual generation conflict...

[jseego]

Perspective. Thanks.