Anyone Can Learn Anything

This past summer, I had the incredible opportunity to work at Khan Academy as a software engineering intern. For those of you who aren’t familiar with Khan Academy, it is a non-profit organization whose mission is to provide a free world-class education for anyone, anywhere. The people at Khan Academy believe that you can learn anything, so I figured I would take this time to reflect on things I learned this summer.

Learning to work with remote coworkers

Khan Academy has a very remote-friendly work culture. This was my first time working at a company where only about 50% of the employees worked on-site. Thanks to Slack and Google Hangouts, communication about work went pretty smoothly; however, things like the time difference and missing out on “water cooler” talks made getting to know my remote coworkers a bit more challenging. One thing that I wish I had done as an intern was attend the remote tea-times. These bi-weekly meetings were designed for remote employees and on-site employees to gather and just chat about things that are not necessarily work-related. If I ever do find myself back at Khan Academy, one of the first things I would want to do is attend one of the remote tea-times 🙂

Learning about accessibility compliance

One of my projects this summer was to help the Learning Platform team rewrite the discussions feature. The old discussions feature had a lot of room for improvement with regards to accessibility. For instance, learners who navigate through the site exclusively with a screenreader might have had trouble interacting with different parts of the discussion tools. Working on the discussions rewrite definitely made me more conscious of how the tiniest details can make a huge difference in how easy or difficult it is for a user to engage with the interface. Simply adding a few ARIA attributes and updating the focus element already saves the user from having to tab through the entire document to see what changed after the click of a button. Although this probably was not the most technically challenging project I’ve ever tackled, I truly had a blast tag-teaming with my co-workers on a project that helps Khan Academy truly be a platform where anyone can learn anything.

Learning what to look for in a job

One of my favorite parts about working at Khan Academy this summer was being surrounded by people who are incredibly passionate about the mission of the company. The engineers at Khan Academy are incredibly bright, and I’m sure many of them could easily have chosen to work somewhere that pays them more than a non-profit organization. However, they choose to work at Khan Academy because they know their skills are being used for a really good cause. The office walls are filled with testimonials from students, teachers, and parents saying how Khan Academy has changed their lives for the better. Some of my favorites are from students who couldn’t afford fancy test prep courses or books, but because of Khan Academy’s free SAT prep, they scored high enough on the standardized tests to earn college scholarships. It’s quite remarkable if you think about it.

Everyone has different priorities when it comes to job searching, and I think this past summer has helped me narrow down my top priorities. First and foremost, I want a job where I genuinely enjoy working with my coworkers and where we all feel like we’re contributing to a worthy cause. As long as I’m in an environment where I feel comfortable asking other people for help and working with them to solve problems, I think I’ll learn a lot during my first few years in the workforce.

All in all, I very much enjoyed my internship at Khan Academy, and I hope that I’m just as happy wherever I end up full-time *fingers crossed* 🙂

my time at square

Yesterday was my last day at Square. Looking back at this summer, I can say for certain that it had many more ups and downs than my previous summer at Google in Irvine, but the experience overall was a net positive. I learned about Java best practices (I feel like I have to read Effective Java now), as well as the frustrations of working on a project without having gone through the proper planning.

Some of the highlights from this summer:

  • Hack week. Every so often, teams at Square will drop what they’re doing for a week, and engineers will work on hack projects of their choosing. Fun fact: Square Cash was originally a hack week project. Hack week was one of my favorite experiences from this summer because I met some awesome engineers on other teams, one of whom would become my best friend (and idol) at Square. I also got the opportunity to tackle a different part of the Register POS codebase, which was challenging but fun.
  • Intern hack week. Even though we didn’t officially have full-timers on our team for intern hack week, we had a tremendous amount of support from full-timers who were eager to help us out via Slack or in person. Most teams only have one intern, so this was a neat opportunity to work with other interns on a project while still benefiting from the knowledge of the codebase experts.
  • Meeting Square’s leadership. Throughout the summer, we had Q+A sessions with Jack Dorsey (CEO), Jackie Reses (Capital Lead and People Lead), Sarah Friar (CFO), and Gokul Rajaram (Caviar Lead). I was inspired not only by the amount of knowledge and experience they each brought to their roles, but also their commitment to using the company’s purpose of economic empowerment to drive business decisions.
  • Company-wide focus on learning. Jack Dorsey talks a lot about the importance of learning about machine learning in order to better prepare ourselves for the future. At one of the recent town squares, they announced that every engineer will be expected to go through ML Bootcamp, and non-technical people will have the chance to take an ML class for non-engineers. Don’t quote me on this, but I think at some point, they’re going to make this resource open to the public, too.
  • Square Speaker Series. One of the office hallways is lined with portraits of all the speakers who have given talks at Square, including Sal Khan and Nora Poggi. This summer, I had the privilege to hear DeRay McKesson talk about civil rights activism.
  • My project. This was by far the biggest internship project I have ever taken on, and I was surprised by how much responsibility they gave me. As an intern on the Checkout Experience Android team, I worked on a new feature for the Register POS app. The app is several years old now, so, over the past year, a team of engineers designed a new “futures” architecture to address some of the pain points of the current implementation. My feature was the first feature to employ the futures architecture, which was exciting but also frustrating at times. I could go on about how the management of my project could have been improved, but I’ll save that for a later time. Bottom line: I learned the hard way just how important it is to have a PRD and a design doc before diving into a project.

Lastly, and quite frankly the part I’m going to miss the most,

  • The top-notch human beings I met. It was pretty much like working with celebrities. Prior to this internship, I wasn’t aware of Square’s open source presence, but it’s there all right. It felt crazy to be going to the authors of mortar and dagger for help on my project, but they were always patient with me and more than willing to share their expertise. In addition to their programming prowess, Square engineers blew me away with their interests outside of work and their past lives. I worked with someone who used to teach ancient Greek literature in a prison, someone who practiced law before becoming a programmer, and even an aviation fanatic who also happens to be a Quora celebrity. As I hinted before, my project came with many challenges, but thanks to the incredible people around me, I made it through the summer in one piece, breaking the master build only a handful of times 🙂

This post originally appeared as an answer on Quora and has been edited to fit this audience.

Lessons Learned

I’m in the final four weeks of my internship, so a post about what I’ve learned this summer is probably long overdue. Last week was a rather turbulent week for me, so I figured it would be worth compiling a list of my key takeaways from the incident.

Here’s some context. My project is to implement a new feature for the Android app. Another intern has been working on the same feature for the iOS app; however, because the iOS team started implementing the feature long before the Android team started its own implementation, the iOS feature is much closer to completion than the Android counterpart.

It was always clear to me how far ahead the iOS team was with the feature, but I didn’t realize until last week that the way the Android team had originally intended to implement the new feature was completely unreasonable—it would have required rewriting large chunks of the app, which was definitely not happening anytime soon. As soon as my teammate and I came to this realization, we had a sync up meeting with the product manager and designers to redefine the scope of the project. We ultimately decided on reusing much more legacy code, which greatly reduced the scope of my project.

To be completely honest, when we first decided to re-scope my project, I was really disappointed. I was disappointed that some of my code would be completely scrapped. I was disappointed that we wouldn’t be implementing some of the cooler designs according to the original plan. But most of all, I was disappointed in myself. As the intern assigned to complete this project, I blamed myself for not keeping my manager better up-to-date on the progress of the project. I blamed myself for not pointing out how behind schedule we were according to the roadmap. I blamed myself for not realizing sooner that the game plan I was given was doomed to fail.

When I told my manager how I felt during our 1:1 meeting, he told me not to blame myself. While I do understand that I am not completely to blame, I can’t help but think of what I wish I had done differently. Here’s the list:

  • Make milestones as fine-grained as needed. Sometimes that means making your own milestones, too. I was given three large milestones for my project, but what I didn’t realize I needed was smaller subtasks for each of those milestones. My strategy has always been to do as much work as I can each day. It’s worked great for me in the past, but unfortunately, for this particular project, that strategy failed me. It made me blind to the fact that I was way off track and prevented me from evaluating my progress accurately.
  • Make it a priority to know who is involved with your project and in what capacity. One of the biggest problems I faced was not knowing who to voice my concerns to. Early on, my gut was telling me that I wasn’t working as effectively as I could be, but I wasn’t sure who to go to for help. If only I had established a point-of-contact for big picture questions, maybe things would have gone down differently.
  • Write a design doc. Last summer, I wrote a design doc for my feature but didn’t really think much of it. I thought it was just something everyone had to do as part of the process. Now that I look back, however, writing that design doc was a crucial planning tool that probably saved me a lot of trouble down the line. Even though no one explicitly told me to write a design doc for my feature this summer, I would have benefited greatly from doing so, even if only informally. My teammates could have given me feedback on the game plan and perhaps even foreseen the roadblock earlier.
  • Don’t be afraid to question the game plan, and certainly don’t assume that what you are given is correct. My most harmful assumption was assuming that because it was an intern project, someone else must have done a thorough job scoping out the specifications and creating the game plan. Full-time employees are not always given perfectly scoped projects, so it doesn’t make sense to assume that my project would be perfectly scoped either. As an intern, I had the additional handicap of being unfamiliar with the codebase. There’s no penalty for questioning the feasibility of certain approaches, and I should, by all means, question the validity of decisions being made. In the end, we’re trying to build the best product possible, which requires thinking critically and being able to back up our decisions.

People usually think of software engineering internships as opportunities to learn new technologies and to discover what it means to write production-worthy code. That’s certainly what I expected to get out of this summer, and it’s true that I did gain some exposure to writing Android apps—though in a distinctly Square manner. However, it’s going to be a long time before I forget how disappointed and frustrated I felt when my project was re-scoped so late into the game. Moving forward into the future, I’ll be sure to keep the lessons above in mind so that I never find myself in the same situation again.