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.
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.
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
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.
10. Stop it with the coding challenges
Stop it with the algorithm challenges and the library-focused interviews.
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 email@example.com 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.