Recruiting and training Ember.js Developers

Hey Ember.js Community!

our company is facing the problem that we do not find any experienced Ember.js devs here in germany or south africa to work on our app.

Unfortunately this becomes a problem when trying to scale up our dev team, so much so that we are considering moving away from Ember.js :frowning:

An alternative would be to train experienced javascript developers to adopt Ember.js. I’m wondering if other have this problem and can share ideas and experience how to overcome the problem.

best, Kalle

IMO this attitude – regardless of tech stack – is a mistake companies make.

Any solid Javascript developer should be able to become productive in your app in a matter of hours. If that isn’t true, figure out what about your process is broken.

Talking specifically about Ember: the learning curve for modern Ember is very modest. Anybody who has worked on front-end JS apps will be productive very quickly, and they’ll know how to ask the right questions when they hit rarer edge cases.

2 Likes

I agree. Basing your technology choices on hiring pool doesn’t seem like a good idea for any company (although it is far too common). Unless your codebase is very old (which would present the same issues in any framework) there’s a ton of overlap in concepts and tools.

Our team is evaluating onboarding right now and operating under the assumption that we won’t get people already experienced in Ember. Our general approach is something like the following:

  • identify what is “Ember knowledge” and what is “our team convention” and keep the two clearly separated
  • try to automate enforcement of team decisions and convention as much as possible (lint rules, automated tests, developer tooling for pushing devs down the “happy path”)
  • surface a “cheat sheet” comparing major framework concepts and syntax so it’s easy to find the Ember analog even if someone is “thinking in Vue” for example (e.g. Routing comparison, contrasting the reactivity models, modifiers vs useLayoutEffect, etc) and some of the concepts in Ember (like Services, Ember Data) that don’t have direct counterparts in Vue/React
  • strong pointers to the official docs and community precedent
  • emphasis on good design patterns (which in broad strokes are completely framework agnostic) like good core single purpose atomic components, one-way data flow, responsible encapsulation of side-effects, etc
  • spending time 1:1 mentoring on anything that isn’t sticking, or a few of the things in Ember that are unique and/or complex (e.g. Ember Data if you use it)

Our codebase is very large and has been around for a long time (started Ember 1.6 I think) so by far the hardest parts of onboarding someone are all related to bits of outdated code, tech debt that hasn’t been addressed yet, or weird/old styles and patterns that haven’t been refactored yet. And of course these sorts of things will happen in a long lived app regardless of framework choice.

Because Ember focuses on convention over configuration (in contrast to React/Vue) I think it’s easier to pick up in a lot of ways because it saves you from having to make so many decisions upfront. Apps that use React across various companies could look very different because React itself is just a tiny library. So all that to say: just because someone has experience in React doesn’t mean they have experience in your React, which in my experience can be almost as big a jump as a different framework entirely.

thanks @dknutsen & @dknutsen ,

“Basing your technology choices on hiring pool doesn’t seem like a good idea”.

Well, popularity changes over time, so you are never “safe” choosing one or the other. Specifically with long living complex projects. Choosing the “right tools for the job” is a big topic to discuss. The fact remains that emberjs developers are hard to find. I’m convinced it makes more sense to build up new emberjs devs than changing the tech stack.

@dknutsen, good to know you guys see similarities here. we have run some recruitment campaigns to find talent motivated to learn emberjs, most applicants dropped out specifically because they had no interest in learning emberjs. I’m working on improving our campaigns, any interest in sharing the learnings?

I totally second the previous replies here, so I will just share my experience with recruiting in our tech team.

Basically we just search Javascript developers with the only “condition” being that they are wanting to learn and are not the “everything-beside-[INSERT FRAMEWORK]-is-sh*t” type :sweat_smile: From there, the process is:

  • a quick call to talk about tech and know a bit more about them and why they like what they are using at the moment (usually React or Angular)
  • we send them a small test and insist that they do it in whatever framework they feel productive with. We know that this makes us work a bit more when we review it because the we don’t necessarily know the chosen framework and will go and check the docs. It’s more to see how they approach the problem even if it’s a small one (implementation and testing)
  • we review it with them a couple days later but it’s still a discussion to know if they would’ve done something differently if they had more time and ask a couple questions about some implementation details.

Once that’s done and they joined us, we don’t drop them on a project directly and let them play with Ember’s SuperRental tutorial and we are in case of questions.As @ef4 said, the learning curve for modern Ember is very modest. The only “problem” we tend to have is that they learn modern Ember, but land in a codebase with older code, which is a bit confusing.

Today, we are 3 devs on the frontend and I’m the only one w/ 7 years of Ember, and my teammates come from Angular and React (and even teammates from backend take some frontend features from time to time). At some point in the onboarding, I also ask them how they would’ve implemented some parts of the SuperRental app in their “usual” framework and show them the “Ember way”.

1 Like