Just a web page?

Or, why be an engineer at Medium?

When people imagine working at Medium, they may think of our accomplished founder or our sweet offices. They might have read about our alternative organization structure or our mindful perks. They might associate Medium with great design, and are aware of our vision.

For an engineer, all these things sound great, but more importantly, he or she wants hard and interesting technical problems to solve. On the surface it may seem like Medium won’t have many of those — “it’s just a content site,” right? But that’s not the case. Let’s take a look at some of our current challenges.


We aspire to help all stories on Medium find their right audience. That means helping the good stuff rise to the top no matter who wrote it or when it was published. We deemphasize recency in favor of quality, wanting to surface the best and most relevant posts to readers. But how do you write an algorithm to determine quality?

Currently we employ a variety of signals to identify the best posts for a reader, through a combination of reading history, recommendations, social relationships, and recent activity.

But there is a lot left to do.

How might we determine that a post from two years ago is relevant to current events? How can we deliver two-minute reads during the morning commute, but 30-minute essays for your lazy Sunday? How can we uncover hidden gems?

Writing Tools

We’ve received a lot of praise for our online editor. We endeavor to make it simple and intuitive to use, at the same time enabling you to tell beautiful stories.

Under the covers, you are editing an abstract data model that is more constrained than HTML. Edits are stored as deltas against the base model, allowing for simpler merging, smaller payloads, and easier version recovery.

If you’ve ever tried it, you’ll know that implementing rich text editing on the web is hard. We want to continue to push the boundaries of what you can create without adding complexity for the user.

We want the editor to help authors make good typographical choices, beyond what we currently do — hairline spaces around emdash, arrows →, “smart quotes”, ❤’s, and ellipses… How can we make software that actually improves writing?


When Medium launched, it didn’t have page-level comments like most sites; instead we allowed paragraph-level notes. We believed that this would encourage people to make more relevant comments and participate in better online discourse.

Notes are also a collaboration and copy-editing tool. Before you publish a post you can send it to your friends and colleagues, who can highlight typos and make suggestions.

Making collaboration even better is an interesting UX problem that offers many engineering challenges. What does it mean to have multiple authors write a story? How can we enable professional work flows? Are there automated tools to help you write better? How could someone write a book on Medium?


We are currently working on an iPhone app. We hope it’ll provide a delightful reading experience. As with many things at Medium, it’s the hidden details that make for an interesting and challenging engineering project: maintaining 60fps through complex transitions, ensuring graceful and seamless behavior offline, smart preloading so the user never has to wait, etc...

Going forward, we want to build the best mobile reading and writing experience. We also want to bring Medium to Android.


A screenshot of a Medium post looks like a simple HTML page. There’s a header image, some text, maybe some inline images. But there are a lot of subtleties that we believe differentiate the experience of reading on Medium versus on other platforms.

As you scroll, the header fades away. Clicking on an inline image blows it up fullscreen; scrolling causes it to collapse back into place. Full-bleed images blur as text scrolls over. When you get to the bottom of the post and click on the next post in your reading list, the post flawlessly slides into place without a visible page load.

These details shouldn’t get in the way of the reading experience, and we are constantly working to improve performance. The code that powers this is a service-oriented Single Page Application. Simple is hard.

Continuous Iteration

Continuous deployment is the norm these days, and we’re no exception. We push every day from HEAD. We run client tests with PhantomJS, use nodeunit for backend tests, and have HTTP level functional tests run in a hermetic environment.

In-progress features are guarded by variants, which can be triggered on a variety of different conditions.

Data Driven

We log a lot of metrics about how people are using our product in order to help us make informed product decisions. Our core metric is time spent reading, which is computed using a number of heuristics, including scrolling and event interaction.

We run A-B tests in order to understand the implications of product changes and experiment with new ideas. But at the same time, we’re not scared to make choices that are in conflict with what the data shows if we think it’s better for the product and our users.


We use AWS extensively. DynamoDB is our main datastore. SQS powers our offline processing and event tracking. We use RedShift for offline data analysis. Our webservers are written in Node.js. We use Go for image processing and a couple of other backend services. We’re bringing up Neo4j as a graph database for managing relationships between people, posts, and collections. Our web client uses Closure Tools. On the iPhone we build for iOS7.

Cross Functional

We aspire to be a truly cross-functional team. Engineers will have specializations, but they should be able to move from backend to web, to iOS, and Android if they want.

Having exposure to and understanding of different parts of the system helps you make better decisions and makes you a better engineer. For example, seeing the benefits and limitations of architectural choices in Objective-C will carry over to work you do on the web, while experiencing how interfaces and structs work in Go will change how you think about inheritance patterns.


Every company says they have an awesome team, and most likely, they’re right. The challenge is finding the right awesome team for you. The engineers here at Medium are humble, respectful, and supportive, as well as curious, smart, and ambitious. They are equally willing to teach and be taught.

So, what do you say? Interested? Drop me a line.

Written by

Englishman in California. Father, engineer, photographer. Recovering adrenaline junky. Founder @ www.range.co. Previously: Medium, Google.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store