Learn what specific WebRTC skills are recruiters looking for in their candidates for companies developing WebRTC applications.
If we dumb it down, I consult companies developing communication services and offer training courses for employees to upskill them in WebRTC. A recent post on reddit caught my eyes, and prodding me to write this article:
Table of contents
Why become a WebRTC expert
Glad you asked…
For me the answer is simple. I love the domain of communications technology. And WebRTC is right at the cutting edge these days. It is also a VERY creative domain to work at.
Some 15 years ago or so I was at a crossroads. The dilemma was should I become a CTO in the business unit at the company I worked at, or go and become the CTO of a new startup. The startup had a nice idea around the disruption of television and internet. The go to market was focusing on Africa and developing countries.
I didn’t know what to do exactly.
So I went to consult my professor at the university. I did my thesis under him, and he came from the industry, after starting a company and selling it. So he knew a thing or two. He was enthusiastic about this for me not because of the idea – but because of Africa. In his mind, going to developing countries meant having less competition in untapped markets.
Today, when everyone wants to be an AI engineer, which boils down to writing LLMs, being a data scientist or writing prompts; doing something else might make more sense: The AI domain is full of demand and supply. It is overhyped with millions poured at the top engineers.
Most of us aren’t top engineers. We might be better off in a market where there’s a bit less hype, high demand and a lot less supply. Which is WebRTC or communication technologies in general.
Being an expert in the domain of WebRTC practically guarantees you’ll be able to pick and choose your employers, or at the very least won’t be left without a job for long.
If tinkering with AI all day long isn’t your thing (using it is something you’ll need to do no matter which role you are going to pick, but tinkering with the AI box is more than that in my mind) AND if you are interested in communications and realtime, then WebRTC might be a better angle for you.
What recruiters want wrt WebRTC
For the most part? They don’t know. Not really.
In most companies, you don’t need 10s of WebRTC experts in a company. A core team of 2-4 is usually enough. The rest around them should understand WebRTC, but aren’t required to be experts. This also means that understanding what exactly entails WebRTC experts to place in a core team isn’t that simple to understand.
Another thing to remember is that WebRTC is many things. It does voice communications really well. Then there’s video. And live broadcast which is different from group conferencing. You can also do cloud gaming with it. Or just data transfer. And in many cases, the expertise you seek in one of these market niches isn’t necessarily transferrable or needed in another.
When it comes to recruiters, most will be fine with seeing WebRTC in the CV somewhere and validating that the basics are in place.
Getting from there to understanding who would fit in a core team? That’s a totally different ballgame.
Let’s look at a simple problem – just defining what a WebRTC expert is…
4 domains of WebRTC expertise
There are 4 different domains of WebRTC expertise you can find. Being an expert in one would make you a WebRTC expert, but won’t mean you’re any good at the other areas.
This immediately means for recruiters that they need to decide which areas are important and critical to their company – to which you are recruiting someone. It also means for developers who want to become WebRTC experts that they need to pick their area of expertise within WebRTC itself.
Lets break this into the 4 domains and see how they differ from one another.
1️⃣ WebRTC signaling (and APIs)
Dealing with WebRTC signaling is no easy feat. Especially not when you have to scale a service to millions of users and to handle all the tricky edge cases.
Someone who understands signaling well will know what transport protocols are available in web browsers (and elsewhere), understand and be knowledgeable at one or more signaling protocols, have the analytic abilities to discuss and select between tradeoffs of these protocols (both transport and signaling).
Oh, and he needs to know and understand WebRTC’s API surface. Know it really well.
Here in many cases, I’d also wrap things like NAT traversal (STUN and TURN), though some of the relevant work here is better handled by a good DevOps guy who knows his way around networking and WebRTC.
Being able to handle WebRTC signaling well means you know your way with communications AND with WebRTC’s APIs and state machines.
If you are planning on using a CPaaS or Video API vendor, then you may skip excelling at WebRTC signaling. That’s because the one handling it for you would be the vendor. If you are using an open source framework – I suggest still having someone who knows WebRTC signaling well around.
2️⃣ Client side UX
Some would say that Client side UX is similar enough to WebRTC signaling or even that it should be the part of it. I view this as separate.
Client side UX is the person who takes care of the frontend. This person understands things like video tags, accessibility, how to handle paging of video elements in large group meetings, etc.
There is also a need here to know and understand the WebRTC APIs really well. Especially the ones that directly affect the UI.
Is this person more of a good UX person or more of a WebRTC person? That’s hard to say.
As with WebRTC signaling, using CPaaS or Video API vendors means you need less of this here. I’d still recommend knowing more in this area – at least if you aren’t planning on using a Prebuilt solution.
3️⃣ Media processing, at scale
Do you think audio and video are interesting? Then maybe media processing is for you.
Here, you will need to do things like understand to some extent how media compression works – for both audio and video. The difference between the various codecs used in WebRTC.
There’s a need to know and understand RTP and RTCP, along with all the relevant extensions they have that are used by WebRTC.
And that’s just for starters…
The real headache is going to be understanding how media behaves over the network for real time communications and all the different mechanisms WebRTC has to deal with issues – things like packet loss concealment, retransmissions and forward error correction.
You will need to understand how bandwidth estimation works and how to optimize and polish it in media servers. You’ll need to know the various architectures (MCU and SFU) as well as how and when to use each.
Then there are things like cascading, geolocation and a lot of other topics that need to be addressed as services scale up.
Here, there’s a lot of effort you’ll need to put into debugging, troubleshooting and monitoring skills. They are likely to be needed often.
4️⃣ Native, mobile and low-level
Embedded and native development of WebRTC is often overlooked. Assuming you plan on running your application solely inside browsers, you are likely to not need such skills in your company.
When taking this route, assume there will be less companies who may need your skillset, but those that do – will not have a large pool of candidates to draw from.
Usually, I’d suggest choosing where you want the majority of your skills to be:
- Focusing on Android devices. This can also lend itself to things like set top boxes, room systems and other embedded devices. I’ve written about the role of Android as an interoperability enabler recently
- If you fancy iOS, then you should be fine as well. That’s because most companies will go for iOS first before tackling Android devices
- Then there’s general embedded work, usually done using libWebRTC, Pion or other library implementations of WebRTC. These come in handy in any low level work – it is also the hardest skillset to learn and excel at
For me, native and mobile is more about understanding which libraries to use on which devices. How to handle libWebRTC’s build environment, and figuring out OS-specific issues with the ported libraries.
The low-level part is more nuanced. It is the ability to go through the libWebRTC codebase, assess algorithms and work on optimizations and porting. This is a very rewarding capability – both intellectually and monetary. The hardest skills to find in the market.
You need to pick 1-2 out of the 4 domains
Finding someone who is proficient in all of these 4 areas is like winning the jackpot or bumping into a unicorn in the middle of the desert. Both are rather unlikely. Being someone that has that kind of skills across all areas? Unlikely. Might happen, but not in the coming year if you’re reading this to decide what to learn.
My suggestion? Focus on 1-2 of these areas. Figure out what you like best and then put your heart and mind in it.
WebRTC isn’t simple, but that’s its beauty. It is satisfying as hell to build something and see it working when it comes to WebRTC. Especially when there aren’t many others around who can do what you can.
The other roles
We’re done looking at engineering – the developers who build applications and services.
There are other roles that can benefit greatly from WebRTC skills. Here, there is no need for the same technical level and experience, but it still makes a lot of sense to know your way with WebRTC conceptually, understand the jargon as well as the limits and quirks of the technology.
The roles?
- Support related – being able to assist end users and do some rudimentary troubleshooting and support for issues. You will need to know how to read logs and how to talk to both developers and end users (two different languages)
- DevOps people – here, things like how to configure media servers and other WebRTC components to play nice on K8s environments can be a real boon
- Product management – that’s where I “roam” most of the time. Understanding the limits and capabilities of the technology, being able to talk and negotiate with developers – this is what I’d look for
- QA – knowing what to test and how to test it in WebRTC applications. You need to be someone who skilled in torturing such apps with a vengeance
If you’re not a developer but want a career with WebRTC – you can still have one. And knowing WebRTC better than the next candidate can get you there faster.
What I look for in a WebRTC developer
When I help companies who are on the lookout for WebRTC talent, the above are the things I have in mind.
Recently, I was asked to join interviews with potential candidates and lead the technical WebRTC part of the interview. Towards that goal, I had a piece of code prepared with a potential bug or two. I also had a nice webrtc-internals dump file. Part of the interview was around seeing how the candidate looks at the code of WebRTC APIs and how he goes about troubleshooting a potential issue.
The other part I look at is what that person did with WebRTC. What WebRTC technology stacks he used and how intimate is his knowledge with these stacks. This is to understand his current experience and skillset as well as trying to figure out his level of curiosity and passion for the use of real time communication technologies.
At the end of the day, hiring for WebRTC talent isn’t an easy task for recruiters. There are ways that you can shine as a candidate in these interviews. Make sure you are well prepared for them.