Jordan WanThis is the first installment of CloserIQ’s Founder Spotlight Series. We sat down with Sung Ho Choi, Cofounder of FuboTV, to ask him some quickfire questions on the challenges of building a fast-growing engineering team.
FuboTV is a live TV streaming platform targeting families who want to cut the cord from traditional TV viewing. FuboTV started as Netflix for soccer but since then has expanded to all sports plus news, popular shows and movies to provide an holistic TV streaming platform. Unlike other similar services, FuboTV builds its tech stack in-house, and is focused on building a premium viewing experience with differentiated product features like 4k streaming.
Launched to consumers in 2015, fuboTV now has over 250+ employees and raised a total of over $250M prior to their recent merger w/ FaceBank Group (a publicly traded OTC company). At the end of 2019, fuboTV had over 300K+ paid subscribers and revenue around $150M a year.
You recently handed over the reins to the CTO, tell us about what motivated that?
Even back when we started the company, I always thought I would not be the most technical person to scale the company. We thought of hiring someone into the CTO role from the beginning.
But in 2014, it was hard to get someone super excited that we felt comfortable bringing in to take over engineering. For the past few years, I carried the duties as the engineering and product leader in the company. I think I’m good at codifying things and finding product market fit but I realized I didn’t have a huge spike in the areas of growing and managing a large engineering team.
Our new CTO, Geir Magnusson Jr. brings decades of experience as the former CTO of AppNexus. My role now is really Chief Product Officer with a focus on innovation. As Geir has come online, I’ve been able to shift more of my focus on aligning our product to our strategic vision and ensuring we’re growing our audience and the products we’re creating have strong margins.
Why did you guys feel like you needed to make this transition?
I had been the engineering manager in the early days. When the engineering team was smaller, there wasn’t a ton of management I had to do because the small team meant everyone knew what was going on. Communication was very fluid. Backend engineers were working on the front end and vice versa so there weren’t a lot of silos we had to break down in collaboration.
But as we grew, we started to see more challenges. One thing I observed is that early engineers at startups have the highest risk to burn out because they know everything and get pulled into every meeting and interview.
A great engineering leader makes sure that not every great engineer goes on a management track. They can carve out career paths that maximize the holistic output of the engineering team by allowing everyone to do what they do best. So when Geir joined, he really audited our org and was able to help us think about the right organizational design.
At a larger engineering organization, the engineering executive is responsible for creating a framework on how to scale the number of engineers and minimize the collaboration overhead while keeping everyone motivated. They build out career paths, compensation frameworks, organization designs and how to best recruit, motivate and retain great people. The lever for growth is much more about people operations and organization strategy vs. getting deep into the codebase.
So do your engineering leaders still have to be great software developers?
Early engineering leaders need to be able to get things done and that means a high amount of coding, technical cleanup, and making tactical decisions on the appropriate coding paradigms and practices.
But even now, I think it’s good for the CTO to be doing some coding and be able to evaluate some of the technical tradeoffs. When we were hiring a CTO, I wanted someone who was better than me who can help resolve challenges with a large codebase and complex tech stack. So they need to be able to design solutions themselves or put together the team to do it. So while Geir still writes some core code that may be used across multiple teams, he spends most of his time building processes that teams need.
How did you hire your early engineers?
Similar to most companies, I recruited former colleagues and also got referrals which were pretty helpful. As we grew, we started to try all the conventional channels like recruiting agencies and platforms.
For the interview process, we were very pragmatic about our evaluation. For example, when we were using AngularJS, we would ask engineers how to build a component based on a directive and view. So these coding challenges were very tactical and not abstract brain teasers.
As the team grew, we started to let hiring managers build their own exercises. For example, data engineering teams would ask more data or theoretical math problems while frontend teams would ask more practical implementation questions.
We tried a lot of great coding platforms and tools but found those didn’t replace reference checks. I strongly believe in reference checks because I care a lot about their work ethic and how they collaborate with other teams/functions. I would ask for a list and call a few but also made sure to do my own backchanneling.
How is your engineering team organized now?
It’s sort of a moving target for most engineering organizations. It’s evolved a lot over the years. We have over 250 employees and over ⅔ of that engineering and product teams. We organized based on the limiting factors of the skillsets we had in the early days and now it’s more of a hybrid.
Initially, we didn’t have a choice because the team was small and had concentrated expertise. So we had only one person who was good at Android or our backend language (Go).
But now we have to support so many client segments and each of the platforms are fairly different so we’re organized more by functional groups. For example, we had a limited number of engineers that could build on Roku so we had to set up a Roku team made up of specialists rather than embedding Roku into other cross-functional teams. Same thing with our SmartTV engineers — there were just not enough engineers to cover pod structure. We use microservices and many are related so we also started to organize teams based on related groupings of microservices as well. These engineers may be shared resources across segments.
How have you built your team and think about remote vs. in-office engineering teams?
We’ve done both. I’ll caveat that back in 2014, there weren’t as many great remote resources and collaboration tools as there are today.
We actually started out remote-only because of cost constraints. We hired a lot of offshore software development resources so we needed to be remote-friendly because we were all working out of our apartments. Our engineering team was spread throughout the US, Europe, and even Asia.
When we were interviewing, we were very tactical and focused on whether the candidate had the skillset to fix problems we had at the time and maybe a few months down the road. We needed developers who could hit the ground running and didn’t have the luxury of giving them a few months to ramp up. So most of our interviews were asking them to write code and demonstrate they can contribute immediately.
As we grew, we had more resources and eventually did hire an engineering manager who wanted people in the office. The argument for in-office is it really helps with culture and synchronized communication, especially in different time zones. When you don’t know what the product or market is going to be, we found it was better for everyone to be in the same office to keep everyone on the same page. But if you’re going through a heads down phase and really need to just crank out code, the benefits of asynchronous communication and working remote is probably better.
Thanks so much Sung! Final question: what are some of your favorite interview questions (technical or non-technical) for interviewing software developers?
- How would you convince a non-technical person in your team (e.g. sales) that you have to spend time doing work that is not a new feature development (refactoring, switching framework, etc.)
- Some technical question about a problem we’re solving at the time. If I’m going to take a time machine 4 years ago it would look something like this — “Imagine you had cloud storage HTTP backend with unreliable performance (inconsistent latency, slow upload speeds on some connections) and you have to figure out a way to upload a 500k-4MB file within 4 seconds reliably every 4 seconds. How would you try to accomplish this?”
- What is the hardest thing to leave behind at your current job? What’s the favorite part of your profession?
If you are looking for job opportunities in tech, click here.
