We are a face-to-face social network
Why join us?
Small team (34 eng) dealing with major scale (millions of users) and growth
Founding team formerly created Meerkat, the first popular broadcast video app
Funded by well-known investors (Sequoia, Greylock)
Engineering at Houseparty
Our engineering organization is built around a single principle: building high quality software.
In practice, we achieve this by providing the best possible environment for our engineers to excel: an environment that is focused (we have a clear strategy of where the company is going, what to build and what not to build), has lightweight and strict project management (so we know at any given time where we are, how we are converging and what’s at risk), and minimal but disciplined software engineering process (from how to we spec things all the way down to atomic commits, thorough test plans and efficient code reviews to reduce risk of regressions and most efficiently propagate knowledge).
tl;dr Our engineering org fundamentally cares about building great software and paying attention to details.
At any given time, we have 20-25 “projects” in flight. A project is any work that is high-impact / cross-functional / involves several people and that is therefore worth tracking at a high level. Projects can be product-driven, engineering-driven, and occasionally marketing-driven. Examples are new product features, infrastructure scaling, introducing new technologies in the video pipeline, etc. They can last from a week to multiple weeks, depending on scope. Each project has a concise spec and clear end goals.
In the case of product-driven projects, the experimentation parameters are also defined (rollout, variations, durations, etc). Engineering teams tackle projects in a FIFO order: once one is complete or waiting for experiment results, the next one gets started. Engineers are free to work on any project based on their interest, skillset and what they already have on their plate. Each project also has an owner who is accountable for its end to end execution, typically a Product Manager but also often an engineer. When not working on a project, engineers are “floating” and helping with bug fixes, small enhancements, refactors, etc… anything improving the overall product and codebase quality.
We deploy the backend daily on average and release the mobile apps every 2 weeks on average.
Our primary technical challenges revolve around our essence: building a real-time presence and live video system at the scale of millions of users. We have presence signals coming from a number of sources like our social graph, people running our apps, live streaming videos, notifications, etc… While this may appear to be a “simple" problem on the surface, when you consider we have a worldwide user base, the variations in usage patterns, the fragility of cellular networks, many different hardware and OSes, the fact we cannot just throw dollars at everything, and finally very high user expectations in reliability and quality, it all turns into a unique large scale engineering challenge.
Example client project:
Our goal was to implement a simple system to communicate arbitrary “messages” to mobile users with custom layout, text, and images. (E.g. to announce events to our users, new features, or even new products.)
Obviously a user should never see the same message more than once and not all users might need to see the message if there are associated experiments. For a project like this one, which is not a critical feature, we want to optimize for the simplest solution in terms of reliability, implementation, and maintenance.
(We decided on an in-app modal with an OS web view. The content is statically hosted on S3 and the target URL of what to display is coming directly from Taplytics so we can precisely control who sees the message.)
Example infra project:
As part of ensuring our infrastructure can scale, one specific bottleneck was the number of connections we can have from the Kubernetes cluster (which runs our backend) to the Postgres cluster.
Each "instance of the backend” has a connection pool and a few connections to Postgres. Once you have hundreds of such instances, we reach the limit of what Postgres can efficiently handle.
(The solution was to setup PgBouncer between Postgres and the backend which required for ops, infra and backend work. This resulted in a significant decrease of number of connections and memory usage in Postgres.)
Working at Houseparty
We look for kind, humble people with a drive to do excellent work and a passion to shape the future of digital communication.
Unlimited paid time off
We have a variety of catered lunch options, a fully-stocked fridge for breakfast and snacks, and expensed dinner for anyone in the office after-hours
Well-behaved pets are welcome!
We encourage employees to take initiative with regards to personal/professional learning opportunities
We offer 12 weeks paid parental leave
General office hours are 10-6, but this is not strictly enforced. Work from home policy is flexible; we typically just care that our employees are happy and productive
Full medical, dental, and vision
We do a ton of team activities: happy hours,
fact Fridays(usually on Wednesday), company softball team, team offsite events, themed parties, etc.
We're in a converted garage in SoMa, with tons of natural light, fun murals themed on our app, and a wall mounted bike rack for commuters
Interested in this company?
Skip straight to final-round interviews by applying through Triplebyte.