How to hire WebRTC developers for your job

Hiring WebRTC developers? Here are some things you need to know and consider, since finding WebRTC experts for a job is challenging.

You’re growing. Obviously. And you have this huge, important, strategic, one of a kind, critical project. And it requires WebRTC. Only thing missing is developers. Or should I say skilled WebRTC developers.

How do you go about finding, hiring and retaining WebRTC developers?

I wrote a short post on LinkedIn the other day about this:

Typical conversation on #WebRTC recruitment

You: “Do you know any developer who can help us with WebRTC?”

Me: “No. Those I know either have a day job they love are are freelancers not looking for work (and almost always fully booked)”

You: “If you learn of a developer available let me know“

Me [Thinking 💭]: “Join the club at the end of that waiting list…”

Finding developers that know WebRTC is really hard. Seriously.

There’s a lot more demand than supply in this one, and the market is tiny compared to other technologies you need to deal with.

If you’re looking for WebRTC developers you can either:

💰 poach someone from another vendor who does WebRTC. Tricky and expensive

👩‍🏫 find someone with the inclination and train them on WebRTC

If you’re on that second track of training, I can help you.

This brought with it a request to write this in longform so Philipp Hancke will have a place to refer recruiters to…

https://twitter.com/HCornflower/status/1423196557948633089

Philipp - this one’s for you 😉

Oh - and if you are interested in history, this isn’t a new topic here. I wrote about finding WebRTC developers years ago...

WebRTC developers: A supply problem

The chart above shows a crude comparison between WebRTC usage and LinkedIn profiles. While the pandemic has shown a huge increase in WebRTC usage (=demand) the change in LinkedIn profiles has been relatively moderate (=supply).

Here’s the two separate charts showing each data point independently:

LinkedIn profiles showing “WebRTC” in them grew steadily from ~17,000 to 25,000 profiles (47% growth in total) whereas growth in WebRTC usage (calculated as calls to GetUserMedia in page loads) grew 0.05 to 0.22 (340% growth in total), peaking at almost 0.6 with the pandemic (that’s %1,100 growth).

We’ve got a supply problem with WebRTC. There’s a shortage of developers, architects, product managers, testers and support who are savvy enough with WebRTC. They are all hard to come by, and it is harder still to know what they really know about WebRTC - installing your own Jitsi server and playing with it is different than running it at scale or developing your own SFU media server from scratch.

With this in mind, you can safely assume that one of the most popular topics raised when people talk to me about WebRTC is hiring WebRTC developers - or more accurately, if I can recommend anyone specific.

The challenging skillsets of WebRTC

Why is it that it is hard to find WebRTC developers?

I think it starts from the diagram below:

WebRTC is multidisciplinary by its nature. It is located right between web and VoIP technologies:

• Web developers would find WebRTC challenging
• VoIP developers would think they know everything (but they don’t)

This means a developer who needs to handle WebRTC needs to have a good grasp of more than a single field of software development. And this isn’t easy to come by.

There’s one more reason though, and that’s the fact that WebRTC means different things to different people, and isn’t really focused on a single set of skills. Look at the short set of questions I’ve asked years ago about how much WebRTC  developers are worth. The answers are mostly around “it depends”, where it depends on what tasks or job description that developer is filling up.

Here are the main areas today that you may need to find different profiles of WebRTC developers:

• Frontend
• Backend
• Mobile
• Telephony

In each domain, the skillset is slightly different and you will be hard pressed to find a superhero developer that meets all your requirements in all areas.

Hiring WebRTC talent

WebRTC hiring is challenging. If you are looking for talented engineers who know a thing or two about WebRTC, then you are in for a world of pain. Finding them isn’t easy and hiring them is even harder.

Here are the different techniques I’ve seen vendors take when trying to find and hire WebRTC engineers.

WebRTC head-hunting and poaching

You can go head hunting for WebRTC talent. Bear in mind 3 things though:

1. There aren’t a lot of WebRTC developers out there
2. Most of them are in cushy jobs not looking to change places
3. Many of them don’t even go on the open market when they need to look for their next gig. They go through “friends and family”, and since the market has so much pent up demand, this is usually where they will land

There are two approaches here. Let's call them bottom up and top down.

Bottom up - you find the individual developers that fit the profile you are looking for, and then you reach out to them to see if they are bored enough to consider moving elsewhere

Top down - target a vendor in this space who you think peaked or someone who got acquired or just someone you think a bit vulnerable and attractive as an employer, and then figure out who are the developers there worth approaching to poach

Neither approach is easy. They are time consuming, frustrating and long.

Job boards and job listings

You could use traditional job boards and job listing sites, place the job opening on your website, etc. What you’ll most probably get is going to be generalists with little domain knowledge and expertise in WebRTC. This means most applicants won’t have the WebRTC experience you seek.

The only other option here is to do an ad placement on WebRTC Weekly and/or webrtcHacks - many of the sponsors there use it for job listings, and you can try as well. The main advantage here is that the readership is quite relevant - developers working with WebRTC.

* Note that I operate WebRTC Weekly and affiliated with webrtcHacks

Hire from an adjacency

This is something I suggest to many of my clients. Hire from an adjacency:

• Video streaming industry
• VoIP or traditional video conferencing
• Telephony
• Software networking

My favorite is probably finding companies that vanished, for example Polycom Israel. They had a large engineering team in Israel experienced in video conferencing. You can try to find developers who worked there 5-10 years ago and… moved on - often to other domains. And try to get them back. They won’t be experts in WebRTC, but they’ll know a lot about how to handle real time video. And that’s better than nothing.

The same is applicable elsewhere in the world and in other adjacencies.

When hiring from an adjacency though, you will need to be certain the candidate in question isn’t “in love” in how things are done today and have the willingness and the openness to learn and grow. WebRTC brings with it new paradigms and challenges and developers who have partial experience and knowledge from an adjacency need to be open to learn new concepts.

Nurture and grow in-house WebRTC expertise

When all else fails, you’ll need to grow someone in-house or train a new hire that is clueless about WebRTC to become that expert. Not an easy task, but certainly achievable.

WebRTC requires a certain inclination. There’s a need to wrap your head around asynchronous events and programming (lots of await and callbacks). There’s a need to understand codecs and lossy compression mechanisms (at least at the conceptual level). There’s perpetual optimization and fine tuning work that goes with it. Not everyone likes to work in such environments (I thrive in them).

Once you find that person, you will need to train them. Something that again can happen in one of 3 ways:

1. Throw them into the water. They probably know how to Google and find their way on the Internet. They will either sink or swim. I believe this involves too much time, risk and wasted effort
2. Have someone train them. If you have WebRTC developers already, then adding a new one and training them can be done in-house. But that will take time from your developers in creation of materials, training and frustration - they might not even be good at training while being great developers
3. Put them on a WebRTC training course. There are a few of these out there, so might as well have them enroll in one (or a few of them). I know for a fact that there is a good WebRTC training for developers out there 😉 probably because I author and maintain it...

More than just WebRTC developers

I have only discussed developers so far, but the product life-cycle of WebRTC products involves more than just the engineers who need to understand WebRTC. There are a few more roles to think about:

• System Architects - they need to understand how different design decisions affect the end results, where the limits are, what architecture alternatives they have, etc.
• Product Managers - need to speak the language. Especially should be aware of what is or isn’t feasible with WebRTC. They need to understand the time and cost implications of the decisions they make
• Testers - if you’re going to test something that makes use of WebRTC, you better know what WebRTC is and what it is capable of...
• Support and Sales - people are going to ask technical questions. Be it because they got into a pickle and can’t connect or have bad quality. Or because they are buying and want to understand what’s in there

All of these roles need a solid understanding of WebRTC if it is part of the things you are offering in your company.

Can I help?

Yap.

There are several things that I actively do here:

• Online training courses for developers (and other roles)
• Assistance in writing job listings
• Publish your job listings on WebRTC Weekly and/or webrtcHacks
• Screen candidates based on CVs
• Conduct technical job interviews to your potential candidates
• Offer coaching to the WebRTC experts you’re grooming

If you’re interested in learning more, feel free to contact me.

Oh - and don’t ask me if I know someone suitable. You’re likely not the first to ask me that this week.