12 things about JavaScript business owners and recruiters MUST know

Original article here: https://oprea.rocks/blog/12-things-about-javascript-business-owners-and-recruiters-must-know

Don’t you just hate it when you’re totally outside the loop when you need to hire a JavaScript developer?! Here’s a short list of concepts and keywords and the simplest explanation I could muster for each. Know these things and you will be able to make far more informed decisions (and you won’t piss your candidates off, in the process).

It’s JavaScript, not Java Script

TL;DR Java is to JavaScript what car is to carpet.

Before you even get a CV in the door, let alone an actual call with a candidate, you must know that JavaScript has nothing in common with Java and it is not a scripting language spun out of Java. To my knowledge, the name is rather an unfortunate choice made by the people at Netscape when the language adoption was poor. Before that, it used to be called LiveScript. They thought the association with Java would make the language more popular.

2. React, Angular, Vue, and jQuery

React is a view library

React.js is only a library that allows your developers to write the view part of an application. This means that it only takes care of the structure and representation of your data in the browser. Developers have to manage the state, pull data and other behind-the-scenes tasks on their own.

Angular is a framework

Angular is far more than a view library. It’s a framework because it comes with a lot of built-in tools and imposes its own way of developing applications. It comes with its own data fetching mechanisms, state management and a host of other functionalities to make development easier and at times complicate it beyond measure.

Vue is a view library

Similar to React.js, Vue is just a library. It helps you build UIs, in a slightly different way than React does. Developers still have to manage the state and do a lot of things by themselves without the aid of the library.

jQuery is a utility library

Think of jQuery as a Swiss army knife you carry in your pocket and you pull out from time to time, to take care of some task. jQuery helps developers deal with the DOM — a programmatic representation of whatever you see on your browser’s screen when you look at a webpage.

Right now, jQuery kinda’ lost its purpose, but a couple of years ago, what jQuery could do in one line of code, it would take 8 lines of vanilla JavaScript code.

3. jQuery is not a programming language or a framework

It is a library for manipulating the DOM (the page’s HTML structure and attributes) — as I said above.

jQuery is built in JavaScript — the programming language behind every webpage out there.

4. JavaScript is a highly versatile language

There’s a common understanding that people use JavaScript to animate things on a webpage. We’re way past that. JavaScript can be used to code full-blown backend applications, with real-time communication and all the bells and whistles that more established programming languages bring to the table. Hell, it can actually be used to operate robots. So keep this in mind when you’re figuring out which types of developers you need to hire and the type of experience required.

5. There’s no such thing as a full-stack developer

It’s hard to define what a stack is.

Is it MERN — MongoDB, Express, React, Node?

Is it MEAN — MongoDB, Express, Angular, Node?

What about SailsJS or Koa which could easily replace Express? Then there’s Vue.js that can replace Angular or React. And Postgres as a database, instead of MongoDB?!

See? It’s crazy!

Also, it’s very hard to find people who are equally competent in both frontend and backend. They will have a predilection for one or the other. Some may be more inclined towards frontend while others prefer to work on the backend more. Make sure you hire the ones with the right predilection for your specific needs.

Think of them as cross-trained or cross-competency developers.

6. Using APIs is different from writing them

People tend to consider themselves full-stack just because they’ve used some SaaS APIs, in the past, or they wrote an endpoint in an Express app for a specific feature they had to implement on the front-end.

That’s false and way different from understanding REST! Designing and securing APIs, choosing between database solutions, looking through caching systems, integrating a message bus, these are competencies that API developers have.

7. Frontend devs are not designers

There’s no hard and fast rule that frontend devs should be designers. Frontend development has evolved into a complex discipline with many ramifications. If you need a designer, hire one. It’s great to have frontend devs with design experience, some of them actually learn design after implementing so many designs themselves, but this should be the exception, not the rule.

8. Backend devs worth their salt also know a bit of DevOps

Not saying they should be experts, but they should know their way around the command line, write a couple of scripts, start up a container or code some simple infrastructure around their services.

9. Node.js is not a framework it’s a platform

Node.js is a platform that allows you to use JavaScript as your server-side language.

Think of it like this: in the past, we used to develop our backends using languages like PHP or Java. These languages would use special “environments” that would evaluate the code and perform some functionality.

Node.js is exactly that — an environment that is able to interpret JavaScript code. It uses the same engine that’s inside your Chrome browser(V8) to do it.

10. Stop it with the coding challenges

Stop it with the algorithm challenges and the library-focused interviews.

If you’re hiring developers to build web applications and websites, evaluate your candidates based on their ability to understand the basics of the programming language they will be using — JavaScript — and not the frameworks you think you will be using.

Make sure your technical team or the people who are doing the technical interviews don’t screen candidates by putting them through algorithm challenges as that doesn’t give you any insight into the value the hire will bring you.

For example, in such a challenge I could easily get my ass kicked by a student fresh out of university since the last time they used QuickSort is probably far more recent than the last time I used it. That doesn’t say anything about my ability to work within a team, to steer technical decisions, make technology choices and organise work.

11. Don’t focus the interview on frameworks and libraries too much

If the interview is too focused on a specific framework or library, and you don’t evaluate the candidate’s understanding of the programming language, you’re in for a big surprise if you decide to change the tech stack.

It’s very easy to trick framework-focused interviews since most questions and their answers are available online. Candidates can learn them by-heart and parrot them out during the interview.

On the other hand, you will figure out if they’re actually worth their salt by the fluency of the discussion, even if they learn language interview questions by heart. You’ll be able to spot the gaps in their knowledge because many topics are interlinked, or build upon one another.

12. See how they work, not just what they know

The best thing you can do is have them go through the implementation of a feature in your current application. You should pay them if it’s like a week-long project, but this allows you to not only evaluate their knowledge but also how they use that knowledge and how they collaborate with your team.

Please don’t give them “Hello World” type projects. It throws people off badly since there’s no actual value in working on a throwaway project. Many able candidates never finish such projects because there’s no motivation for them to do work that’s going to be thrown away. And this is true especially when you’re talking about experienced developers. They don’t have time to waste on pulling tweets from the web and listing them on a webpage.

Before you go

I hope the information in this article is useful to you, the reader. If you’d like to dig deeper just send me an email at adrian@oprea.rocks and I’d be happy to talk to you and figure out what you need.

While you’re here, you must know that I’m reviving my newsletter, so subscribe to the newsletter using the form in the site’s banner. Don’t worry, I won’t spam you with useless stuff. I will send you occasional emails, that are highly personal, not the usual inbox-filling spam you’re used to getting from other sources.

Happy hiring!