We're on a mission to make the world better friends. ❤️
At Picnic, we are big believers in the importance of friendship. We build tools that allow people to further enjoy and strengthen their friendships.
Our product is a supercharged group chat app, built for friends - based on the science of friendship.
Quality time together is crucial for healthy friendships, but 90% of our interactions with friends today actually happen during the ‘in-between time’. This in-between time lives on messaging apps that are still only doing the bare minimum for friendship:
At Picnic we believe there is huge untapped potential. We’re building a 10X better way to spend ‘in-between time’ with friends. That means chat spaces that:
We are early stage and currently in 'stealth mode' while we polish off the app.
The app is currently in Alpha testing (you can sign up to try it here) and is set for a wider Beta release in July 2020.
We're well backed by world-class investors and advisors, including:
You can find full details of our hiring process here: https://www.notion.so/teampicnic/Software-Engineer-React-Native-Node-js-5445cb0e5c4a48c9985f1470723516c8
> We are looking for a React & React Native developer who loves creating products that people want to use. You understand that apps—and code—are for people, not for computers, and always strive to make our app and codebase more understandable and easy to use.
We currently have a product team of 4 people, and you'll be working directly on our flagship product alongside the founding team. As we're still small, we have a very lean product development process, and ship features daily.
We have absolutely no legacy code, and are free to make any technical decision that makes sense for the product.
This role is a brilliant opportunity for anyone looking to join a purpose-driven, ethical (B Corp Pending ✨) tech startup where they can make a huge impact from day one. This is a critical business role so we're setting the bar high.
To be clear, a "high bar" for us does not mean "many years of experience". Most of all, we are looking for someone who never wants to stop learning, regardless of seniority.
Since we are such a small team, and currently work extremely quickly, our main "hard requirement" is around React and React Native. Working with these will form the core part of your work, and we expect you to be proficient in them.
We strongly encourage women, people of color, lesbian, gay, bisexual, transgender, queer and non-binary people, veterans, and individuals with disabilities to apply. Picnic is an equal opportunity employer and welcomes everyone to our team. If you need reasonable accommodation at any point in the application or interview process, please let us know.
Our development philosophy can snarkily be summarized as "move fast without breaking things". Most of the decisions we make in terms of architecture and tooling are driven by whether they can allow us to make small experiments often, without fear of breaking existing code.
All of our code is written in [TypeScript]. We lean heavily on the type safety guarantees this provides, as well as the nice developer experience improvements like smart code completion and automatic renaming.
Our app uses [React Native], and we're using functional components and hooks throughout the entire codebase. We use [MobX] for all of our state management—we feel it provides the benefits of functional reactive programming without the boilerplate or conceptual baggage of other state management libraries (we've used them all in past lives). (We do use tiny bits of [RxJS] for slightly more complex stream wrangling.)
The app communicates with the server using a [GraphQL] API, built with [Apollo]. We generate TypeScript types from our GraphQL schema definitions, so we never push obviously broken code to production. Apollo also provides us with some [great tooling], such as performance metrics for our queries broken down by each field, and validating schema changes based on actual usage. This allows us to safely make breaking schema changes while ensuring that no outdated clients are still relying on the old schema.
We use [CodePush]to perform over-the-air updates without having to publish new releases to app stores. This allows us to release changes multiple times per day. We use [Sentry] to keep track of any errors and crashes that do occur (nobody's perfect, but we do try).
On the server side, we use [Node.js] and Express. All of our data is stored in [PostgreSQL], and cached in [Redis]. We treat Postgres as an append-only log of events. This log is read by "log consumers", which are each responsible for creating the specific data structures (currently in Redis) that are needed to efficiently serve each query. As a result, all of our reads can go directly to Redis, since all caches are always "hot". This allows us to build new features and optimize existing queries without having to perform schema migrations.
Since we're not at the scale to have dedicated infrastructure/SRE engineers yet, we are using managed hosting services for everything. Our servers are currently deployed to [Heroku], which provides us with good tooling for staging environments, server monitoring, logging, CI, and high-availability databases. This means we can focus on features instead of infrastructure for now. As we scale our user base, we will certainly face some interesting problems in this space, so if this is also something that excites you, we'd love to hear from you.
In past lives, we've been burned by endless sprints with badly defined objectives, so instead we've developed a process which is heavily inspired by [Basecamp's Shape Up process]: we align all of our feature work to 6-week cycles, followed by 2 weeks of "cool-down". Thinking 6 weeks ahead forces us to do a lot more up-front planning and design, while giving us freedom over how we actually implement the features we plan for. The cool-down period allows us to tie up all the loose ends (bug fixes, refactoring, "nice-to-haves"...) which in a "normal" agile process would have to be crammed into ad-hoc "bug-smash weeks", "feature freezes" etc, which tend to be extremely difficult to get buy-in for. At a day-to-day level, we track all of our work in [Clubhouse], which is basically "Jira except actually makes your life easier, not harder".
Permanent position or contract will be considered
For a permanent position