Mentor Guest Speaker: Founder of Tinder and Director of Software Engineers @ Disney Streaming, Joe Munoz
Sabio is thrilled to have Joe Munoz as one of our guest speakers. For those who don’t know him, his resume is pretty extensive, including…
- Designer & Co-Founder of Tinder
- Director of Software Engineers @ Disney Streaming
- Development Lead @ Hulu
- Chief Data Officer @ Welcome Technologies
- Senior Android Engineer @ Cornerstone on Demand
- Team Lead & Software Engineer @ Snapchat
- And more
Suffice to say, Joe has been there, done that with pretty much all things ‘software engineer,’ and had some great advice to give to our Sabio fellows, check out some of his story:
S: Thanks so much for taking the time Joe, I know our students are thrilled to hear what you have to say, can you tell us a little bit about how you got into the world of tech?
J: I like to joke that if you’re a parent and you give your kids legos, that’s the gateway to software engineering. If they enjoy it and have a natural curiosity about how things work, that’s a sign they’ll most likely love it.
I started taking things apart when I was pretty young. I actually got in a lot of trouble with my Grandfather because I took apart his old 8-track player and couldn’t get it back together, but I just really wanted to understand how it worked on the inside. We moved around a lot when I was a kid but eventually settled in Diamond Bar, CA. And, when I moved there, it was a huge change because a lot of my peers in Diamond Bar had been going to private schools and had all the trimmings that came with that. We had been relatively poor, and suddenly I was surrounded by people who not only shared my interests, but had the time and money to pursue them. I feel in line with some kids who were super smart and definitely geeky types. They were all into computers and started taking programming after school, so I of course wanted to take programming after school.
This led to me taking AP computer science in high school, but really it was because I just didn’t know what I wanted to do. I barely even knew what computer science was, just that I liked computers and liked programming, so maybe that was where I was going to find my niche. My high school itself was pretty diverse, but I never really noticed that I was the only brown kid in my AP classes, it just didn’t dawn on me, so even though I didn’t see anyone who looked like me, I just kept going down this path.
S: That’s really inspiring to hear, so after high school, what was your next step?
J: Well, I got into UCLA where I was automatically enrolled into something called the Minority Engineering Program or MEP. It actually still exists today but they cant use those terms so it’s called the Center for Excellence and Engineering Diversity. But, when I joined, I noticed that I was there with fellow Latinos, African-Americans, Native Americans, they were really trying to create a diverse community. At first, I didn’t really understand why the emphasis on building a community was super important, but then as time went on I recognized how vital that community was as a way to find people like you to connect with that ended up turning into lifelong friendships. Over the years, I’ve also joined SOLES, UCLA’s Society for Hispanic Professional Engineers, and NSBE the National Society of Black Engineers, both of which have been super rewarding and we’ve done a lot of great outreach. We’ve had opportunities to mentor kids and get their feet wet in this world, something that most of my peers when I initially started at UCLA hadn’t had.
You also have to understand that computer science was very different then. A lot of my peers didn’t actually have experience doing anything on a computer and were expected to know a lot of things that UCLA wasn’t going to teach you, which was very different from what the students expected. For me, because I had been coding for a while and working with my geeky friends, I had a sort of leg up that I used to help mentor any of my peers that I could. It was just unfortunately that MEP did not have a good curriculum for computer science but was focused more on traditional engineering. They do now of course, but everything was so new.
One thing that was challenging for me was seeing everyone drop out of the program. When I started there were about 12 people in the MEP computer science program, by the 2nd semester that had dropped to 3 and by the time I graduated, there were only 2 from the original class. A lot of those folks were like, ‘Hey, I’d rather do mechanical, electrical or civil engineering, but there’s a good chunk of them that just got out of engineering all together and went to liberal arts, or history or English. But, whenever everybody joined, they all had a passion for engineering. That’s also something that’s changed now, but back then it was really difficult for people to get the experience they needed from high school to prepare them for the college level.
S: Wow, it’s very interesting to think about how much things have changed. So once you finished college, how did you land your first tech job?
J: I actually was part of a summer internship program during college at IBM called Project Breakthrough, where IBM was making an effort to bring in more diversity hires. So after two summer internships in a row with the same team, the project lead Randy sort of became my mentor. When I graduated, I reached out to him to say, hey is there a position for me at IBM and he said, yeah, of course. So, I joined IBM as a Project Breakthrough candidate and my career began.
S: As you know, most Sabio graduates have just entered the world of tech. What would you tell them they can expect in their journey through this new career path?
J: I’d say one thing you have to be as a software engineer is being comfortable with failure, it’s going to happen a lot. Developers who like video games probably love Dark Souls, because it’s the same loop, ‘I’m gonna fail, I’m gonna fail.’ Then you make a little bit of progress and you get to a point where it’s like, ‘Okay, this is working out.’ I think the journey as a software engineer is that you start out learning and then eventually you get more expertise and experience so that you can start to own a few components. Then, at some point you start to take on a bit of mentorship, become a domain expert in a particular area while also helping the other developers who are at different levels.
From there, now that you’re a domain expert, you start interacting with other teams and systems, other principals or lead engineers. Then, from there, you can decide if you want to go into management or stay as an individual contributor. If you want to stay an individual contributor, the next level is architect. The difference between a senior engineer and architect is architects are expected to have a broad understanding of development best practices of system engineering, tools and technologies that are being used, they go to a person to vet design at a very high level or how. They also work on how to modify architecture at scale, or influence the design team to really design at scale, or coordinating between folks across different parts of the company. The key difference is the scope. A principal engineer might have scope over a team or system, architects are expected to operate at a much higher level, more cross team and cross collaboration. You’re solving problems for the business, figuring out, say, why someone abandons their cart in real time. The architect would work with the rest of the team and figure out how to solve the more difficult problems and help to drive best practices throughout your different organizations. They’re aware of all those higher level concerns that maybe you don’t necessarily think about when you’re just building part of a component.
The other route you can go is becoming a software manager. I’ve done both and I think earlier in my career I was most excited about the technical part, but as I got older I started to feel more connected to developing engineers and careers. I like to joke that I’ve done every job in tech because I’ve been a software engineer, architect, manager, CTO, CEO, and now director. There’s a running joke in my family about it. My Grandmother, every time I went to a new company I would give her a sweatshirt with the company name. She would always ask me, ‘When are you going to get another job so I can get another sweatshirt?’
S: Thanks so much for sharing that. Going back to one of your first larger roles, can you tell us about your time at Myspace and how that led to you creating Tinder?
J: Yeah, that was when I was trying to be a product manager, or I should say, I was the project manager for search and recommendations there. At that time they were going through a major transition period where they were really trying to modernize Myspace. It was right after Facebook started really eating Myspace’s lunch. They were trying to re-design the entire Myspace thing, re-brand it, and make it cooler. Unfortunately, we didn’t get to execute on the vision because, I always like to joke that Justin Timberlake fired me. He didn’t personally fire me, that would be a more interesting story, but he was the investor with a company that took over Myspace and got rid of almost everyone except for the music folks there.
While I was there, it was interesting because I had never really worked on a project that was that design driven. They had a room with something like 100 designers and the branding was really interesting. The mistake they made though, is that when they did the design, they didn’t include the engineers in the process until the design was done. We would walk into the room and look at the design like, “hey, I don’t even know how we’re supposed to do this.” You want to try and incorporate the engineers when you do design as early as possible so they can give feedback. I was also in charge of recommendations and I remember asking off the bat, “How are your recommendations performing?” And they were like, “We don’t know, we just put them out there and don’t actually check.” They didn’t have analytics at all, so the first thing I did was to try and integrate that. We started thinking of different ways to do different types of recommendations, people to people, people to content, content to content, and that’s when I first started exploring the knowledge graph.
We did that by starting to work with this company that Google bought called Freebase. Freebase had an entity graph like a knowledge graph, so they knew facts through using their API. Like, on myspace you could look for Jennifer Lopez movies which meant you might like Jennifer Lopez music. Because there’s Jennifer Lopez the person, celebrity, artist, and Jennifer Lopez the musician, right? There’s all these facets to this one individual that they just weren’t connecting the dots on. I started to talk to one of my good friends Todd who was an exec at Myspace and we started thinking about, ‘wouldn’t it be interesting if you could take your social media, and you access all of someone’s friends and their likes.’ Essentially, what Facebook ended up getting in trouble for with Cambridge Analytica. But at the time I thought it was interesting because if we had all that data, we could put it into a knowledge graph and use that to figure out what else you might like and keep you within the Myspace platform.
After Todd and I left myspace, we created a startup that eventually got contracted with IAC. Now, IAC wanted us to build a restaurant recommendation thing funded through a company called Hatch Lab. Where they basically gave teams six months to launch a mobile product that was somehow disruptive. Eventually they paired me with Sean Redd, the CEO of Tinder. The first day they put us together they said, “You have to do a hackathon.” We were brainstorming on what to do, so I started talking out my initial idea about recommendations, “Hey, what if you could log into facebook, walk into a room and you can then figure out who’s in the room that’s also on facebook?” And then, you take their friends and likes and figure out who has the most affinity with each other. My idea was that you could know what topics to discuss with someone in a room like as an ice breaker to make friends and Sean went, ‘Nah bro, it should be about dating.’ So I said fine, and I built an android app proof of concept that did just that.
The original app was if you said yes and they said yes, then it’s a match and then you can talk to each other. That’s the core concept of tinder that was there in the initial prototype. But, we didn’t get hired to build a dating app, we got hired to build a loyalty app for restaurants that businesses could leverage to drive profit. So we put the hackathon app aside, went off and built the restaurant app, and presented at the TechCrunch Disrupt. We ended up running into an issue with Apple where we couldn’t get the app into the app store and IAC told us it’s going to take months to resolve. Sean, to his credit, said, let’s take the thing that we built for the hackathon with this time we have and see what happened with it. We put it out and it went crazy.
S: That is so fascinating, to think about all the seeds that had to be planted to lead to this great thing. After you launched Tinder, where did your career path take you?
J: After Tinder, I worked for Hulu as the head of mobile. I actually did a contract for Marvel years later, and now I’m on like my fourth go around with Disney, at this point I think we’re meant to be. What my team does now is the core messaging team for Disney+ and we’re responsible for push notifications and In-app messages. It’s an interesting time at Disney because they just bought Hulu, and we’re trying to merge a tech stack between Hulu & Disney+ which are totally different apps.
When I joined this go-around, my team was about 4 engineers and now we’re at over 20. We work with a lot of other interesting teams, data teams, marketing intelligence teams, marketing ops. It’s an interesting intersection of every part of Disney, because you also have to work with the front end teams. One of the bonuses is I get a discount at Disneyland so I’m there almost every other weekend. It’s great.
S: Now that you’ve had this prolific career and are in charge of hiring new software engineers, what are the things you look for in a potential candidate?
J: Well if you’re just starting out, the best way to learn how to do something is to build something. In this industry, if you go out and build something, that helps you stand out. Then there are the other key aspects of the job, like being able to communicate with stakeholders, being able to work well with co-workers and solve problems as a team. If I’m hiring somebody I look for: Do they seem like they want to learn? Do they seem like they can be taught? Do they want to teach other people? Do they want to solve problems and do they have the temperament to be in a room and disagree but commit? That’s one of the key things to having a very functional team, is you want people who are not afraid to voice their opinions respectfully and you want people that can hear other viewpoints or approaches that don’t necessarily align with theirs, and then as a team come to a consensus, that’s super super important. SO it’s not just being able to know how to code or know what a four loop is, etc. That stuff is important too, but it’s also showing that you want to learn, can be taught and that you can work with a team.
S: You were so kind to talk about your computer science experience at UCLA, have you felt the methods of learning how to code have changed since then?
J: I don’t think you have to have a degree to be a food software engineer. I’ve worked with many software engineers that don’t have degrees, one of my best friends is CTO at a big company and he was a Biology major. Also, computer science and software engineering are related, but they’re not the same thing. Computer science is all about the theory of computations. Being a software engineer is all about coding, algorithms, complexity, and being able to solve problems.
What you would look at beyond that when hiring is experience. And that’s not to say if you’re just starting you’ve got no chance. If you don’t have an internship or work experience to point to, try and build something, put that on your resume and be ready to talk about it. You don’t have to have a degree to be a good software engineer, full stop. When I was graduating back in the day you kind of had to, but now you don’t. I know plenty of companies that hire people out of bootcamps as well, big and small. I also generally recommend bootcamps to people who don’t want the college experience, because a bootcamp will still get you ready for a career in tech and get you a job.
In the beginning when you’re just starting out as a software developer, it’s really just about experience. What projects do you have, what are something you can point to that you’ve built, that’s why I think it’s easier to vet somebody’s experience than evaluate their technical skills.If you can talk about a project, I’d rather talk to you about something you’ve built and go into detail on that instead of a coding question. Coding questions are so subjective, and I don’t really tend to trust that style of interview as much as some other folks do. For me it’s about the technical challenges and talking about that, how did you solve it, what made it difficult, why was it difficult, where do you go when you get stuck, what would you do if you ran into a situation, etc. To me, that interview tells me more about your abilities than, “hey you have a list of 1000 words and find me the ones that are pallindromes.” But if you can tell me, “I wrote this app,” or, “I had this problem and I thought if I wrote an app it would make it easier for me to solve this problem and here’s the app that I wrote, here’s the tech I used, here’s how I built it.” That is more compelling to me.
S: That is fantastic advice. So, last question. What’s one piece of advice you wish you could go back in time and tell yourself?
J: Wow, hmm. Don’t let the fact that you’re not the best at anything keep you from trying to level up your career. It took me a long time to have the confidence to graduate from software engineer. And, I probably could have done it a lot earlier if I had just trusted myself. That’s probably the one thing if I could go back and re-do parts of my career, I would have leveled up sooner because I think I had the talent to do it, but I didn’t have the belief. The other thing I’d say is that, if you’re getting into a startup or sort of going down that route where there’s a potential upside of money involved, definitely get a lawyer. Have someone read the contracts, because if you don’t know a lot about that space and you’re very trusting, it’s very easy to be taken advantage of. Those are probably the two things I’d say, you’re good enough, so take the opportunity if it’s presented to you, and then, hire a lawyer.
Posts you might like
- Navigating the Tech Job Market: Insights from Sabio Alumni and Cybersecurity Opportunities
- Embracing the Climb: A Leader's Growth Mindset Journey
- This is the Perfect Time to Dive into Coding and Automation, This is Why!
- Troubleshoot Like a Pro: The Art of Debugging in Programming
- Beyond Bootcamp: Diverse Career Avenues in Tech
- Spotting Burnout in Tech Job Hunts: 6 Warning Signs & Ways to Overcome It
- Get Hired: Essential Knowledge for Emerging Programmers
- 7 Steps to Build a Personalized Continuous Learning Plan for Coders
- Empower Your Journey: Benefits of Remote Code Bootcamps
- Proactive Steps: Daily Rituals for the Job-Hunting Programmer
- Don't Sabotage Your Tech Job Search: Mistakes to Skip
- Unleashing Opportunities: How Bootcamp Career Services Propel Success
- From Lines to Offers: How Your Coding Experience Shapes Market Value
- Optimizing Success: Your Attitude in Coding Bootcamps
- Roadmap to Success: Tech Job Hunt with a Coding Bootcamp Mentor
- Crafting Your Tech Startup Roadmap from Bootcamp Grad
- Tips for Creating a Resume That Gets Interviews for High-Experience Jobs After Coding Bootcamp
- Accelerate Your Career: Embrace Bootcamps for Real-World Programming Skills
- The Coding Craft: Essential Skills Learned at Bootcamps
- Bootcamp Bonds: Tapping into Networks for Tech Employment
- Coding Confidence Booster: The Benefits of Coding Mock Interviews
- Programming by the Clock: The Impact of Effective Time Management
- Coding Freedom: The Value of Learning at Your Own Speed
- Calm Code Journey: Overwhelm-Free Bootcamp Success
- Polish Your Pitch: Tech Interview Communication Essentials
- Inside the Loop: Coding Bootcamps and Tech Industry Strategies
- From Zero to Hired: Decode the Experience Question in Tech Interviews
- Solving the Puzzle: Refining Your Problem-Solving as a Programmer
- The Art of Practicality: Using Coding Languages Without Overlearning
- Practice Makes Perfect: The Key to Software Engineering Brilliance