Senior Front-End Engineer

We are looking for a Senior Front-End Engineer to join the web team—the team behind the Unsplash website. Over the years, we’ve taken Unsplash from a humble Tumblr blog to a fully-fledged web app supporting tens of millions of users and tons of useful features. We’ve done all of that with a lean team of just 4 web developers, but there’s still so much more to learn and do, and that’s why we need you!

The website’s architecture

To get a taste of what it’s like to work on the web team, here’s some insight into how the website has been built so far.

The Unsplash website runs on Node and uses React to render both on the server and the client. The HTML we generate via React’s server-side rendering is cached by our CDN (Fastly). Once the HTML is received by the browser, we’ve optimized the critical rendering path to ensure there are no blocking resources. All of this means we can render the page as soon as the browser begins receiving HTML, without waiting for any other resources (such as CSS or JavaScript) to download and execute.

To provide the best user experience we use React on the client-side as well on the server-side, but in case JavaScript isn’t available for some reason (which happens more than you might think), most of the site will still work. (Try it yourself: go to https://unsplash.com/?disable_client_render_in_production and try to search or navigate to a photo page.) Progressive enhancement is core to the website’s architecture.

Interactive front-ends involve the coordination of many different asynchronous events. To deal with this complexity we have adopted functional reactive programming (via RxJS), and to join this together with our React components we use observable-hooks.

By adopting (strict) TypeScript and functional programming we’ve eliminated whole classes of bugs. We use finite-state machines and tagged unions such as RemoteData to make “impossible states impossible”.

At the application boundary we use io-ts to decode external data such as API responses or URL query parameters, so when an API response inevitably goes awry, the data doesn’t flow into our components and cause an obscure error further down the line—it’s immediately clear where the problem is and the API team (not the web team) is notified.

For layouts we take full advantage of CSS grid and flexbox. We organise our component styles using CSS Modules.

The way we work

The web team is currently just 4 people and we work closely with the API team (4 people) and design team (3 people).

We designed our company in a way to get as much of the stuff that’s not the creative work out of your way, so you can do your best work. We don’t believe in a top-down, shoulder-tapping, 9–5 type culture. You have the autonomy to manage yourself. We don’t work set hours. We respect flow. We believe you should be able to structure your days for what makes you feel the most energized and creative.

When we’re working on a new feature, someone from each team will spearhead the project for that team. Everyone has the chance to be a leader and has the opportunity to influence and push their own ideas.

In-depth code reviews help us share knowledge. We don’t review code just to pick on some style nits—we automate as much as we can so we can spend time reviewing the important things like code architecture and identifying patterns for potential abstractions.

Frequent and smaller code releases help us identify problems early and validate our impact. On an average day the web team alone deploys 3-6 times.

We constantly monitor front-end performance, using SpeedCurve to set budgets and alert us when we exceed them. When there’s a regression in performance we take the time to investigate and fix it.

When a runtime exception slips through the net, we take the time to understand what went wrong and to find the necessary steps to prevent it from happening again.

What you will be working on

• New features
• Internationalization/localization
• Back-end/Node performance
• React performance
• General website performance (e.g. optimizing the critical rendering path and Core Web Vitals)
• As we grow the website, you will help us evaluate the website’s architecture and trade offs between various solutions.

What we’re looking for

We’re looking for someone who:

• is comfortable being part of a small, autonomous and distributed team.
• can communicate sensitively and clearly.
• is genuinely interested in the product we’re creating. Someone who cares about the end-product beyond just writing the code that makes it work.
• has a high level of experience with most of (but not all of) the various technologies mentioned in the architecture section above. Most importantly: Node, TypeScript, functional programming, advanced React.
• can bring new creative ideas to improve the quality of our product and codebase.