Behind the scenes #6: First hire, chaos engineering, landing page
Behind the scenes #6: First hire, chaos engineering, landing page
In this issue:
Big news — our first hire! A former senior engineer from AWS has joined our team as the first hire! Read on for the backstory, the interview process, and how we managed the onboarding.
Gearing up for a public launch. We’ve launched a landing page. Learn how we built it.
Chaos engineering all around. Learn how chaos engineering helps build empathy with mobile users.
Latest podcast episodes. Episode 38 with Karl Ulrich, a Wharton professor of entrepreneurship and innovation and episode 39 on work and life in immigration are out! Listen to “Metacast: Behind the scenes” wherever you listen to podcasts.
If you know someone who will enjoy this, please forward the email!
Behind the scenes, vol. 6
Newsletter archive: vol. 1, 2, 3, 4, 5.
TLDR: We’re the team behind Metacast, the podcast app that is unlike any other. We’re in closed beta right now and are gearing up toward a public launch.
This newsletter and our Behind the Scenes podcast is where we share our entrepreneurial journey with anyone who’s into storytelling about entrepreneurship and product development.
So, what have we been up to since the last newsletter?
Big news — our first hire!
In vol. 4 of this newsletter, we said that we signed our first hire. Check out the archive if you’re interested in how we were thinking about awarding equity to employee #1 and the framework we established for the company.
Jennie Buechner joined us as a Sr. Software Engineer in early October. Some of you may remember her as a super fan of the Metacast podcast. Jennie was a guest on our bonus episode (ep. 17) where we talked about her transition from a teacher to a senior engineer at AWS. Jennie called us “minor podcasting celebrities,” so she definitely passed the test for sense of humor and culture fit.
The interview process
The interview process was intense. In a typical Amazon style, we did six rounds of interviews, including one with a bar raiser. It was a logistical nightmare because Metacast was just Arnab and myself at the time and each of us had to interview Jennie three times. Oh, and we also had a tug-o-war as to who gets to be the bar raiser…
Just kidding.
Jennie was on our team at AWS and we worked together on a day-to-day basis for a few years. At some point, Arnab told me that Jennie was going to leave Amazon, so we should talk to her about teaming up with us. It never crossed my mind to do an “interview.” The whole process was rather a sales pitch where we wanted to get someone we really respect and trust to join us.
Onboarding
We hire for general programming skills, cognitive abilities, and culture fit. In other words, proficiency in a particular stack is not that important. An experienced engineer can learn a new stack fairly quickly.
To help Jennie onboard and get me up to speed on Flutter as well, we set up an internal crash course. Arnab walked us through fundamentals of Dart, Flutter, and the asynchronous nature of the beast. Then, each of us built a simple throwaway app, which helped get our hands dirty and familiarize ourselves with Android Studio. Finally, Arnab walked us through the structure of our code base and we built a skeleton of a new feature together.
That was good and very effective.
Initially, we considered doing a generic Flutter crash course and inviting a few external people. We’re glad we did’t do it because it’d have a) prevented us from going into our own codebase and b) put too much pressure on sticking to schedule and meeting expectations. The vibe of those sessions turned out very laid-back, open, and enjoyable.
As part of onboarding, we are following Amazon’s playbook yet again — Jennie is documenting her onboarding steps, so that we can make our next hire effective even faster. Tasking new team members to update onboarding docs is the only way to keep them up-to-date.
Jennie, welcome to the team! ❤️
Gearing up for a public launch
We’ve still got plenty of stuff to do before we can launch publicly, but with two engineers cranking out PRs daily, it feels like we’ll soon be on the final stretch of shipping an MLP (minimum lovable product).
In preparation for the public unveiling, we launched a landing page where you can enter your email address to get notified when the app ships. Feel free to go to metacast.app and put your email right in.
Psychologically, having a landing page feels good. It def makes me feel more legit.
To build the landing page, we used Carrd. It’s a simple one-page site builder that doesn’t cost you an arm and a leg. We pay $49/year and can launch 50 sites on the platform. This feels like a good deal. Also, it only took me ~2 hours to launch the page. I did it all in one sitting.
I was baffled to find out that to collect emails, we’d need to use a service like Mailchimp or Zapier that charge on a per contact or transaction basis. At our expected scale (in the range of thousands to tens of thousands), our bills would run to hundreds of dollars per month.
This seemed excessive for a simple database of email addresses. So I devised a scrappy scheme…
Every time someone puts an email into the form, we’ll get an email that contains this person’s email address. We’ll use Gmail API and write a simple script to parse those when the app launches and we are ready to send a notification. A script like this shouldn’t take more than a couple of hours to write.
If you know anyone who likes podcasts and (better yet!) doesn’t like Apple Podcasts or Spotify, send them to metacast.app.
Chaos engineering all around
Netflix has created and open sourced Chaos Monkey, a system that “is responsible for randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures.”
We took this principle and implemented something similar in our app.
In debug mode, the app will randomly make some API calls fail or slow down, so we can see how the app behaves if the internet connection is lost or too slow, or if there are some weird unexpected errors. We don’t have to have a solution for all of those but, at the very least, we got to catch exceptions, avoid dead ends, and have human-readable error messages.
When we develop locally on a 1 Gigabit internet connection, things happen very fast. When someone uses our app in a basement, things are very different. Chaos engineering helps us empathize with users. It’s annoying when we test the app in a simulator and it randomly slows down or fails. But we do get to see the experience from the user’s perspective and address those problems before they’re reported.
Latest podcast episodes
Ep. 38: Wharton professor Karl Ulrich on teaching entrepreneurship and value of MBA in 2023
A discussion with Wharton professor Karl Ulrich on teaching entrepreneurship, value of MBA, working at the MIT AI lab in the 1980s, and a career as a professor and founder.
Ep. 39: Work and life in immigration
How living on a work visa affects your risk appetite? How does immigration change you? What are some gotchas? Today, we talk about our immigration journeys and discuss these important questions.
Get new episodes on Apple Podcasts, Spotify, YouTube or wherever you listen to podcasts.
Coming up next
Episode 40 (coming out next week) is with our friends over at Tramline, a release management tool for mobile apps that we can’t live without.
Episode 41 (two weeks from now) is going to be with Jennie! We’ve not yet recorded it yet but I anticipate it’ll be epic.
Support our journey
There are a few ways you can support our nascent business.
Subscribe to this newsletter
Forward this email or our podcast to a friend
Buy The Pragmatic Podcaster book or gift it to someone
Buy a t-shirt on our merch store
Ciao!