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


Receiving feedback as an intern at Khan Academy

by David Wang on Oct 26, 2015

When my first piece of code was reviewed at Khan Academy, my mentor Dylan prefaced his comments with the following:

(Kamens’s post here, Tom’s post here)

And to be honest, I chuckled when I read that: I had already expected seeing a bunch of red during my first code review, and if I received a ShipIt on my first go without any comments whatsoever, I would’ve questioned the efficacy of the code review process at the company :). I asked Dylan why he felt the need to open his code review with this lead-in, and he described his experience with his first code review as an intern. It would have been discouraging to receive so much critical feedback all at once, had he not received the same piece of advice. Somewhere in the middle of that conversation, he let me know that the quality of my code had little to do with the quality of my person, and that code critiques != character critiques.

This interaction with Dylan led me to wonder about feedback - as a whole in addition to code feedback - more than once throughout the course of the summer. What is Khan Academy’s view on giving feedback in general, and giving feedback to interns in particular? Why does it hurt so much to receive criticism, even when it is delivered with the best of intentions? Why is it that we feel we have to tread so carefully when we’re delivering it?

Khan Academy and feedback

While every one of these questions can have an entire blog post devoted to each of them, I’m going to just give a brief overview of what I’ve discovered on all of them here. First, regarding KA’s view on feedback, after chatting with managers and poring through docs, I discovered a page on the company wiki about developing a feedback culture. Perfect! It said that the company views feedback as a gift: it’s given with the best of intentions it should be considered a positive sign that my colleagues are willing and choose to invest in me (and my development). All cheesiness aside, I think I’ve come to really appreciate that metaphor as much as that other one about today being a gift. I can pinpoint instances, both in work and in school, where I’ve gotten the impression that people have given up on me. And to be honest, being ignored for me is a much worse feeling than having criticism barraged at me. In addition to this metaphor, KA views a feedback culture as one that is regular / ongoing and 360 degrees, where anyone feels comfortable asking for feedback from anyone else.

And for interns? As part of the mentor/menteeship experience at KA, I had weekly 1-on-1s, where I checked in with my mentor and talked about how the last 7 days have been, and whether I was getting what I wanted out of my summer experience. While it’s acknowledged that these 1-on-1s are a good time to exchange feedback between mentor and mentee, it’s not always explicitly stated that that is one of the goals. Thus, something I’m very glad I did was at the end of each 1-on-1, asking for one actionable piece of information that I could change or focus on for the next week.

In addition to the weekly 1-on-1s, one thing I’m glad Khan Academy does is offer a more formal midpoint evaluation for each of its interns. And from the context of a single internship, the midpoint evaluation is (in my opinion) more valuable than the final evaluation: it’s less a performance evaluation (where we discuss how us interns have performed compared to what has been expected of us) and more a coaching opportunity. By getting recommendations on where we can improve, we can take steps towards playing at a higher level. And if there’s 6 weeks left to an internship during its midpoint compared with 0 at the end of the internship, the feedback given at the halfway mark allows for greater growth.

The process as a whole

In general, I've often asked myself why receiving feedback is so hard. After introspecting, talking to some folks, and digging around, I think that there are three things at stake:

  1. We feel wronged if a piece of feedback seems inaccurate. This leads to a host of possible reactions: we deem the feedback as simply wrong, or maybe we believe that the person giving the feedback has made unfair assumptions about the motivations that drove our behavior.
  2. We might reject the feedback because of how we feel about the giver. Perhaps it was unsolicited, perhaps we believe that person doesn’t have credibility in what they’re critiquing us on, perhaps the feedback hasn’t been communicated well, or perhaps we’re unsure of the intentions of the feedback giver himself.
  3. We perceive feedback as a threat: it might cause us to question our relationship with ourselves. One of our core human needs is to be accepted the way we are, and this is so ingrained in us that signs of rejection (through critical feedback, for instance) lead to the same flight-or-flight response in our limbic systems as actual threats to our physical safety.

As to treading carefully when giving feedback, I think it's a matter of taking the cautious route after briefly taking the perspective of the feedback receiver. We understand how difficult it is to be on the opposite end, and we lean towards a soft approach to make the experience more positive and less stressful.

Lastly, I believe that after all this discussion on feedback and constructive criticism, we should not underestimate the value of compliments. Not because they’re used as part of the "feedback sandwich" technique to make people more open to feedback, but because it’s important for us to know when we’re doing things correctly and what we could be doing more of. To borrow the wise Ben Kamens’s words, “If your team isn’t taking advantage of the chance to also acknowledge good work and the little sparks of genius that pop up here and there, you’re doing it wrong.”


Looking back at my time at KA, I’m glad that they’ve been willing to throw me in the deep end and hold me accountable for the work I’ve done. During these 12 weeks, I broke part of the site for the greater part of a day, gave a company-wide presentation on social psychology of all things, and helped build a recommendation system for the company hackathon. And in the spirit of growth, I’m glad that my mentors Dylan and Sergei have encouraged me to try things that are outside of my comfort range, and have provided guidance, support, and feedback across all things technical and non-technical.

When people ask me what I learned from my internship or what my most major takeaway was, I tell them the meta lesson I’ve reinforced in myself about learning, which can be described by any of the following synonymous statements:

  • To quote the eloquent David Hu, “Assume you’re stupid so you can always be learning.”
  • From Zen Buddhist Shunryu Suzuki on adopting a beginner’s mindset, “In the beginner's mind there are many possibilities, but in the expert's mind there are few.”
  • With my own words: frame feedback as opportunities for coaching instead of evaluation, and frame mistakes as learning experiences instead of failures.

In case you were wondering, Dylan’s comments to me in my first code review were to write a more descriptive commit message and test plan :). I hope I received the feedback well.