How to hire and train developers when you don’t use React

Sure, there are fewer developers who know Ember, Angular, Vue, etc. but does that have to make it difficult to grow your team? Nope. In this article, you’ll learn strategies for mitigating some of the challenges of using a less-common framework or library.

1. Screen for solid JavaScript, HTML, and CSS

No matter your stack, new hires will have to learn a lot. Luckily, all major frameworks have free, beginner-friendly, step-by-step tutorials that a new hire can go through independently. As long as someone has solid JavaScript, HTML, and CSS skills, a new framework becomes the easy, well-paved part of what they need to learn in their first month on the job. More on this in section 2.

Personally, while framework-specific experience is a plus, I interview candidates with experience in any front-end framework, since they all share many of the same concepts. Here are my tips for Interviewing your future coworkers in a way that is framework-agnostic. For example, the majority of engineers I have hired didn’t know Ember, and things turned out great. If you really do need someone to have framework-specific experience, it helps to be open to remote employees and advertise on framework-specific job boards.

2. Optimize onboarding as a whole

The next step is to address non-framework-specific pain points of onboarding. No framework or skills can magically eliminate the time it takes for:

• understanding the full-stack architecture of your products
• developing strategies and good habits for debugging production servers
• getting comfortable with deployment pipelines and environments
• discovering common failure modes of deployed apps
• uncovering where you hide everything on GitHub/Google Drive
• knowing who to ask for help about which things
• figuring out where to begin with the first few Issues
• learning to work in codebases with insufficient documentation/tests (we all have these areas)

Address these concerns by creating internal guides and fixing problems, and you will shorten the time it takes for someone new to be productive.

Sidenote: “The hiring pipeline is too small!” is a common argument for switching frameworks, but a different framework solves none of these bullet points above. Choose the framework that is right for your product, and strive for a quality implementation. Chances are, your selection of a fully-documented, well-supported framework is really not what is making dev experience difficult or time consuming at your company.

3. Make a video tour of your apps

Even if a new hire already knows the framework you’re using, your apps will still have a learning curve.

So, record a few code walkthroughs for your team’s internal use! They can be messy and informal. Your new hires will appreciate that they can rewind to learn at their own pace, revisit “confusing” topics after they have learned more, and reference them when you’re not available to help.

I suggest doing some “livestream-style” recordings on the following topics:

• How to install and run the app locally
• How to run tests
• project layout (i.e. which files are important to look at)
• example of debugging something in the browser
• how the app connects to APIs

Don’t let perfection be the enemy of good. You can knock out all five of these in one afternoon. Sure, the code will get out of date immediately, but your aim is to help answer the question “how do all the pieces fit together?” and that is not likely to change rapidly.

4. Establish a buddy system

In every framework, there are some questions that are hard to Google but easy to ask another human. Every new hire should have an appointed mentor or peer who should be asked 1000 questions. I used to tell new hires, “if you don’t ask me enough questions, that makes me way more worried than any number of questions you could possibly ask me.”

For example, googling “how to pass data to a component” will get you some really esoteric content, but a coworker could show you a simple, live example in 5 minutes that will help cement the most important framework concepts.

5. Get new hires to network outside the company

For less-popular frameworks, there are fewer books, videos, and Stack Overflows. This can be mitigated by networking.

I encourage new hires to go to meetups and join chat/message boards. I recommend that they try helping out some strangers in order to build both their own skills and some networking connections to people who will help them in return. One of my past companies sent me to a conference in my first week and it really accelerated my learning.

As a bonus, your teammates’ connections in the framework’s community will be useful for future recruiting too!

6. Document like your job depends on it

This advice was given to me by a friend, when I was worried about being the only front-end developer at a company after someone left. He said that my codebase’s documentation would scale better than I would once we hired someone new. There’s no substitute for a good README, a developer FAQ, and some code comments.

Speaking of code comments, when you write them, focus on inputs, outputs, and “why.” For example: “this function takes in a string like some-string and outputs {prefix: [“some”], main: “string”} which is needed because xyz.” Remember that the question “how do the pieces all fit together” is one of the hardest things for a new hire to get a handle on, especially as they are learning a new framework.

7. Ask new hires for feedback constantly

When you’re comfortable with some codebase or framework, it’s easy to forget where the hard parts are, and the pain points shift over time! Ask new hires to help improve the onboarding resources. Once a week for the first 6 weeks, ask them about what was difficult or where they got stuck. At the end of six weeks, ask them what they would tell themselves if they could go back in time, and then build that into your onboarding process.

8. Create an Engineer Handbook

You should keep a checklist of everything a new hire should try to do or learn in the first four weeks on the job. Include links to your favorite framework tutorials, internal docs, things to bookmark, links to official docs, etc. Keep in mind that unless they already have framework-specific experience, your new hire has no idea which learning resources are reliable and up to date. In the handbook, I also cover things like engineering security policies, on-call expectations, and initial dev environment setup. This doc will help take pressure off your “in-house experts” and give new hires some self-directed ways to learn.

I wrote an article called How to Learn Ember in a Hurry, and it would be great to have similar articles for every framework! Feel free to adopt the format for your own.

9. Throw money at the problem

It’s not a huge deal if you have to coast on free materials. But, comprehensive, in-depth courses are often paid. Consider asking for a training budget to get a license for the new hire or the team. If the course saves one hour of an experienced engineer’s time, it’s probably paid for itself.

In my own learning journey, I found paid trainings to be most useful when I was past the “truly beginner” phase and starting to ask myself questions like “how should I structure my D3 code when I’m working in this framework,” “how do I connect this to websockets,” and “how do I do error handling better than this?”

10. Contribute back to open source projects

If your company keeps hitting the same learning pain points, or if you see a problem in a tutorial, fix it at the source. A huge percentage of open source software’s documentation relies on volunteer effort. As a maintainer of hundreds of pages of content I didn’t personally write, I want you to know that little fixes submitted by random people are absolutely critical and super helpful. There’s no way I could track it all myself. Thanks in advance!

Conclusion

Hopefully this gives you some ideas of how to overcome some of the challenges of hiring for any framework. If you have framework-specific tips to share, feel free to write your own version of this article or add them in the comments. Thanks for reading!

Jen Weber is an engineer at Cardstack and a member of the Ember Core Team. Her goal is to help make tech a more welcoming place.