Khan Engineering

Khan Engineering

We're the engineers behind Khan Academy. We're building a free, world-class education for anyone, anywhere.


Latest posts

Making Websites Work with Windows High Contrast Mode

Diedra Rater on March 21

Kotlin for Python developers

Aasmund Eldhuset on Nov 29, 2018

Using static analysis in Python, JavaScript and more to make your system safer

Kevin Dangoor on Jul 26, 2018

Kotlin on the server at Khan Academy

Colin Fuller on Jun 28, 2018

The Original Serverless Architecture is Still Here

Kevin Dangoor on May 31, 2018

What do software architects at Khan Academy do?

Kevin Dangoor on May 14, 2018

New data pipeline management platform at Khan Academy

Ragini Gupta on Apr 30, 2018

Untangling our Python Code

Carter J. Bastian on Apr 16, 2018

Slicker: A Tool for Moving Things in Python

Ben Kraft on Apr 2, 2018

The Great Python Refactor of 2017 And Also 2018

Craig Silverstein on Mar 19, 2018

Working Remotely

Scott Grant on Oct 2, 2017

Tips for giving your first code reviews

Hannah Blumberg on Sep 18, 2017

Let's Reduce! A Gentle Introduction to Javascript's Reduce Method

Josh Comeau on Jul 10, 2017

Creating Query Components with Apollo

Brian Genisio on Jun 12, 2017

Migrating to a Mobile Monorepo for React Native

Jared Forsyth on May 29, 2017

Memcached-Backed Content Infrastructure

Ben Kraft on May 15, 2017

Profiling App Engine Memcached

Ben Kraft on May 1, 2017

App Engine Flex Language Shootout

Amos Latteier on Apr 17, 2017

What's New in OSS at Khan Academy

Brian Genisio on Apr 3, 2017

Automating App Store Screenshots

Bryan Clark on Mar 27, 2017

It's Okay to Break Things: Reflections on Khan Academy's Healthy Hackathon

Kimerie Green on Mar 6, 2017

Interning at Khan Academy: from student to intern

Shadaj Laddad on Dec 12, 2016

Prototyping with Framer

Nick Breen on Oct 3, 2016

Evolving our content infrastructure

William Chargin on Sep 19, 2016

Building a Really, Really Small Android App

Charlie Marsh on Aug 22, 2016

A Case for Time Tracking: Data Driven Time-Management

Oliver Northwood on Aug 8, 2016

Time Management at Khan Academy

Several Authors on Jul 25, 2016

Hackathons Can Be Healthy

Tom Yedwab on Jul 11, 2016

Ensuring transaction-safety in Google App Engine

Craig Silverstein on Jun 27, 2016

The User Write Lock: an Alternative to Transactions for Google App Engine

Craig Silverstein on Jun 20, 2016

Khan Academy's Engineering Principles

Ben Kamens on Jun 6, 2016

Minimizing the length of regular expressions, in practice

Craig Silverstein on May 23, 2016

Introducing SwiftTweaks

Bryan Clark on May 9, 2016

The Autonomous Dumbledore

Evy Kassirer on Apr 25, 2016

Engineering career development at Khan Academy

Ben Eater on Apr 11, 2016

Inline CSS at Khan Academy: Aphrodite

Jamie Wong on Mar 29, 2016

Starting Android at Khan Academy

Ben Komalo on Feb 29, 2016

Automating Highly Similar Translations

Kevin Barabash on Feb 15, 2016

The weekly snippet-server: open-sourced

Craig Silverstein on Feb 1, 2016

Stories from our latest intern class

2015 Interns on Dec 21, 2015

Kanbanning the LearnStorm Dev Process

Kevin Dangoor on Dec 7, 2015

Forgo JS packaging? Not so fast

Craig Silverstein on Nov 23, 2015

Switching to Slack

Benjamin Pollack on Nov 9, 2015

Receiving feedback as an intern at Khan Academy

David Wang on Oct 26, 2015

Schrödinger's deploys no more: how we update translations

Chelsea Voss on Oct 12, 2015

i18nize-templates: Internationalization After the Fact

Craig Silverstein on Sep 28, 2015

Making thumbnails fast

William Chargin on Sep 14, 2015

Copy-pasting more than just text

Sam Lau on Aug 31, 2015

No cheating allowed!!

Phillip Lemons on Aug 17, 2015

Fun with slope fields, css and react

Marcos Ojeda on Aug 5, 2015

Khan Academy: a new employee's primer

Riley Shaw on Jul 20, 2015

How wooden puzzles can destroy dev teams

John Sullivan on Jul 6, 2015

Babel in Khan Academy's i18n Toolchain

Kevin Barabash on Jun 22, 2015

tota11y - an accessibility visualization toolkit

Jordan Scales on Jun 8, 2015


Khan Academy: a new employee's primer

by Riley Shaw on Jul 20, 2015

I recently joined the developer team at Khan Academy. Since arriving I’ve been surprised by a number of intentional decisions the organization has made to empower its developers. Whether you’re working in tech or just curious about the inner workings of Khan Academy, there’s some great wisdom in how things are done here.

All aboard!

A benefit of working at an education startup is that everyone naturally puts a lot of thought into information design. As a result, this has been the smoothest onboarding I’ve experienced.

Onboarding actually started a few weeks before my first work day. As soon as my offer came through Andy sent me a short message:

I’m sure you’re being well taken care of, but if there’s any questions I can answer for you, or any magic words you need to hear to sign that offer, please send them my way.

I said something stupid:

As far as magic words go, I've always been a fan of "flipendo"

...and I got the coolest response ever:


Wat. He… wat? He made that? For… me? Wat.1

I spent the rest of the weekend pulling out my phone to show people what this wonderful stranger had made.

I got a few more messages from the team before starting. A fellow Canadian offered a couch to crash on while I was looking for a place. And I got a message from Jordan, onboarding buddy extraordinaire.

Onboarding buddies

Starting a new job is intimidating. When you’re new and have questions it’s hard to know who to ask, when to ask, and how often to ask. Khan Academy makes this easy by giving every new hire an explicit mentor, along with the following rules:

Who to ask: Your mentor. If they don’t know the answer, they’ll know who knows the answer.

When to ask: Now.

How often to ask: Probably more often than you currently are.

Having someone to relentlessly pester during my first few weeks was instrumental in getting up to speed quickly.


As soon as I arrived on my first day I went for a walk with my manager Marcia2. We strolled around the block under the beautiful California sun and learned a bit about each other. She showed me where the nearest coffee shop was. She told me that if I ever had a problem someone would be there to help. It was a warm welcome that set the tone for the rest of the day. When I got back to my desk I scheduled three more walks3.

Khan Academy encourages these casual, personal meetings. You frequently see teammates heading outside to talk through a technical decision. Anyone can set up a one-on-one with anyone, and it makes for an open team.


A recent-ish experiment at Khan Academy is Teams Initiatives Projects, or TIP. It’s a way of organizing the team across different axes.

The gist: Teams represent areas of deep domain expertise like design or mobile. Initiatives are cross-functional major company goals, like “Launch an SAT guided study program”. Projects are like mini-initiatives; they’re scoped at 2-5 weeks and involve 1-3 people.

I enjoy working within this framework. Everyone is on a functional team, so even though we’re spread across different projects we can pool our wisdom and make big decisions. Initiatives let us move toward big targets while projects help scope them down. My favorite part, though, is a side-effect: the support initiative.

Support rotations

Every three weeks a group of developers enters their scheduled support rotation. On support, you kill bugs. Having a team dedicated to bugs means that everyone else can focus on moving ahead with their projects.

New developers at Khan Academy start on support. Every company should do this. In the past I’ve felt guilty for swimming through the codebase at a new job, but on support that was my job! Tracking down bugs was a great way to learn my way around the stack while still contributing. As time went by I grew more confident and started taking on bigger bugs. It was a natural progression and made me confident in my ability to make changes4.

Anyone can fix anything

At Khan Academy you don’t need permission to fix things. If you come across some outdated code or CSS rules that are out of order… it’s all yours5. Be the change that you wish to see in the code.

I’ll admit that I was skeptical upon hearing this. “Fixing” a small bug can lead to chaos elsewhere if you’re not familiar with the system. As such, “anyone can fix anything” might have the corollary “anyone can break everything”. But it works out pretty well when everything is code reviewed!

Code reviews

Coming from a freelance background, some of my biggest projects were completed in isolation. Working on a team again is exciting because I get to learn from my co-workers. Khan Academy does code reviews for every changed line of code, which is a fantastic way to share tricks and deep contextual knowledge. It also makes deploying less scary.


As a growing team – especially one that strives to be awesome for our remote members – we’ve put a lot of thought into internal communication. We use Hipchat heavily, and try to be transparent with our emails. We have a variety of tools that we use in different contexts, and as a result I have way fewer emails coming through my inbox than I’m used to. It’s great.


Khan Academy has delicious catered lunch, which I’ve almost come to expect as a Silicon Valley tech brat6. Something surprising about lunch at KA is that nobody takes their lunch back to their desks. Shortly past noon the office stops typing and shares a meal with one-another. It’s a pleasant part of the day, and it’s not usually encouraged as strongly as it is here.

Speak now

Once a week we’re treated to a technical talk from someone on our team. These cover a broad range of topics; in my time here I’ve seen talks on functional reactive programming, prototyping as a mindset, mobile architecture, database architecture, and the most ludicrous bug Alan has ever seen.

We recently introduced a related series called Demo Now. As our tech-talks gradually became more polished, ad-hoc demos to the entire product team fell by the wayside. Demo Now is an attempt to encourage unrefined demos of cool projects. When everyone is experimenting and pushing their boundaries it’s important to establish a culture that encourages showing unpolished work.

Ship ship ship

Our dev setup guide is titled “Your first day: Grok culture and get shipping”. It guides new engineers through adding themselves to the team page; many accomplish this on their first day. Strong ongoing mentorship and the support rotation keep the onboarding momentum in full swing.

In my first month I owned the development of multiple projects, tackled a big bug, mentored an intern and presented a technical talk to a full room. I’ve done my first (and second and third) proper A/B test, code-reviewed an accessibility project, and volunteered as an assistant at the Learnstorm finals and as a tutor at the Khan Lab School. I even found someone to play music with after work!

We achieve so much because we relentlessly focus on action. As Ben writes in Shipping beats perfection explained7:

Is this the right philosophy for all products? Absolutely not. But educational content is so badly needed right now, and students are so hungry, that it’d be vain of us to think satisfying our own hunger for perfection is worth more than students’ needs. We’ll get to the complete mobile app. We’ll get to better coverage of computer programming content. Maybe we’ll even get to a fully immersive physics simulation. One day.

If you’re the type who can’t “just” leave it better but must make code perfect, then you’re satisfying your own needs instead of learners’. You’re violating “shipping beats perfection.”

Open source

We’re committed to open source at Khan Academy8. If it doesn’t store private or sensitive data, it’s in an open repo. When we make something extra-useful, we turn it into a standalone library for anyone to use.

It’s cool to work somewhere that loves open source. We’re receptive to experimenting with new technologies9, and splitting our code into modular bits allows us to keep trying new things. We also have all sorts of contributors catching bugs and adding features for us. It’s useful and inspiring.

These are good ideas!

Just as code reviews disperse knowledge through a team, tech companies should share their organizational processes. Collaborating as a team of software developers is a yet-unsolved problem, but things get better every day.

So take this post as an organizational diff. If something seems healthy, merge it into your own culture and see if it compiles. If you think we’re missing something, let us know!

I’ve personally had a wonderful time getting to know the KA team, and am still as unbelievably excited to be here as I was on day one.


  1. For reference, this isn’t the first time that Andy has gone over the top

  2. My heels were injured at the time but the walk seemed important so I didn’t mention it. 

  3. Eventually I discovered that sitting was also an option and that I didn’t have to damage my body to talk to people. 

  4. …without breaking everything. 

  5. Of course, you can also delegate it to support if it’s a doozy. 

  6. We also send a small group out to Castro Street every Friday on opt-in lunch dates. This is far less common as far as I’m aware. 

  7. This post is almost two years old. Since then we’ve released a full mobile app and quintupled our computer programming content! Looks like this “shipping” thing is working out pretty well. 

  8. Our webapp actually used to be completely open

  9. For example, our first commit using React landed one week after the first public commit of React itself.