What we built this summer: Meet our 2017 intern class
As an engineer who helps run the intern program, I want to give you a view into what it’s like being a technical intern at Asana. As the summer of 2017 came to an end, I caught up with a few of our summer interns to hear about what they built this summer.
Meet our summer interns
Andrew (back row, second from the left) is from Waterloo. His hobbies include hiking and lock picking. In terms of music taste, he is a self-proclaimed “hardcore Shakira fan :)”.
Nathan (back row, fourth from the right) is from Iowa State, and ballroom dances competitively and likes to rock climb “as much as possible”.
Tammy (middle row, fourth from the left) is from Waterloo. She likes playing video games with a strong storyline, and dabbling in uncommon sports like archery.
James (first row, second from the left) hails from Waterloo, and is interested in art, and music. He’s in an acappella group, and owns a keytar.
Molly (last row, sixth from the right) is pursuing a PhD from UC Santa Cruz. She is passionate about machine learning and data visualization. In her free time, she plays guitar, reads a lot, and plays League of Legends.
What projects do interns work on?
At Asana, we treat interns like full time employees. When they start, they’re placed on a team with a mentor, and are a core part of the team. This provides a better experience for the interns, as well as the teams they’re on, as they work on meaningful and complex tasks that impact the team’s goals. This means that we expect our interns to really own their work and drive it to completion. Here’s a look at a few technical projects our interns worked on this summer:
Andrew’s mentor gave him a choice of ongoing projects he could work on and let him pick which one he found most interesting. He was interested in upgrading our forked version of Node.js to a more recent version. This turned out be quite complex, because the way we use Node.js is relatively unique. Instead of having a single Node.js process, we fork multiple ones for better parallelisation and to prevent reparsing code on every session launch. This means we maintain our own, unupdated fork of Node.js.
After the upgrade, there were several small bugs that cropped up, including one corruptive one: after a while, a forked Node.js process would stop working in a non-deterministic way. Andrew dug into the Node and V8 source code to eventually find that processes would wait for garbage collection to run, but Node.js wouldn’t do this in the forked processes. This caused them to hang endlessly. Thanks to Andrew’s work, we’re going to be able to take advantage of the speed, memory and security benefits of newer Node.js versions, making Asana faster and our server bills lower.
To read more about infrastructure engineering at Asana, see Asana server deployment: A pragmatic approach to maintaining our legacy deployment system.
“I never thought I would get to touch C++ and OS level system calls.” – Andrew
Nathan worked on our Monetization team, where his first big project was an Asana premiumness API. We have a number of types and tiers of paying customers for whom different features are enabled. Previously, when we created premium features, each engineer would code their own check to control access to that feature. This led to a lot of repeated work, messy code, and checks distributed throughout the codebase. Nathan worked closely with a teammate to create a simple module that could handle the data model intricacies and allow premiumness checks to be standardized across the app much more simply.
His second project was more self-driven: an in-product “dunning” notice. “Dunning” is when a customer has been unable to pay their bill, usually due to their payment method expiring. This is one of the biggest reasons for our customers churning, so Nathan worked to create an announcement integrated with our payment provider to notify our customers that they needed to update their billing information. Since launch, we have already seen great results: the notice is succeeding, and fewer users are churning due to outdated payment details.
For more on product engineering at Asana, see Product Engineering: Reimagining role boundaries at Asana.
“I got to pair with every person on my team for different little experiment projects, which was really fun.” – Nathan
Tammy worked on many projects with the iOS team. Her biggest project was User Pages. User Pages is a very popular feature on Android that the team decided would be valuable to have on iOS. Tammy was the primary driver of this project, and owned it from start to finish. She built the entire feature, collaborating with Product Managers and Designers to make product designs more effective. She also had to consider the project’s objectives, stakeholders, trade offs to make, and how to integrate it with the legacy code. She was the single point of contact and context for the project.
For the rest of her internship, she got involved with accessibility. Accessibility is a recent effort with a small group of volunteers, led by Tammy’s mentor. Their goal is to make Asana more accessible for everyone. Because there are many unknowns within accessibility—it’s a new program—Tammy started from the bottom and worked up. She self-audited the iOS app and determined future best practices, bug fixes, and feature developments. She worked on the first focused accessibility project, iOS VoiceOver for the blind and those with low vision. Her work laid the foundation for a more accessible Asana.
For some of the many features the iOS team is shipping, see our latest shipping round up: Announcing Asana for iOS 11.
“With some help from my team I did essentially everything for User Pages, except for the design and prioritization, of course.” – Tammy
James was a member of the Client Infrastructure team. He worked on improving our client-side TypeScript framework to allow for a faster user experience. His projects were all open ended. The team identified a number of performance problems, and James figured out how to solve them. One problem he worked on was improving the performance of hypertext navigation. When clicking on a link in the app, you need all sorts of information: its projects, parent tasks, privacy, and other metadata. But fetching all of this information quickly is technically difficult. So James wrote a design document outlining his solution, as well as other potential solutions. The goal of the doc was to share his ideas for improving hypertext navigation and receive feedback. In order to write this doc, James needed to dig into various parts of the app and really understand how we use links throughout.
James also worked on improving load time by removing the need to generate TypeScript data model definitions. LunaDB, our reactive server-side data system, needs Scala model definitions to determine what data to send to the client. These Scala definitions are generated into TypeScript models that are used in our front end framework. This increases the size of our client side JavaScript bundle, which slows down page loads. To get rid of this code generation—and thus speed up load time—James used Typeable Programming. Now we can write definitions and rely on a compiler to ensure definitions are used correctly at compile time, rather than using actual generated objects to achieve the same end.
For more on improving our performance, see Treating performance as a product: The technical story of Asana’s arduous rewrite.
“My work involved interfacing our old UI framework with our new codebase. This meant I had to learn how to gain a lot of context very quickly and interact with a massive code base.” – James
Molly worked on user clustering with the data science team. Asana user behavior is not homogenous. For example, marketers at a publishing company use Asana differently than doctors at a non-profit. To understand our different customers, it’s useful to segment them into groups with similar user behavior. To do so, we look at things like how many tasks they create, how often they visit the site, or if they use the API. This was the core part of Molly’s work.
One of the challenges she faced was skewed user behavior data. This meant she had to explore different data transformations and clustering algorithms to make useful clusters. While there’s a whole field of research on clustering, not every clustering algorithm is useful on skewed data as well as compatible with Redshift (our data warehouse). In order for Molly’s clustering work to be applicable, it needed to cluster users effectively and be productionized (so we can use it at scale). This made her project very open ended and challenging.
For another large data science project we undertook, see Helping customers’ success, through data: Rebuilding Asana’s Account Health Score.
“The first half of my internship was focused on research. Later on, I spent most of my time productionizing my code and communicating my findings to other people in the company. ” – Molly
What does mentorship look like?
At Asana, mentorship is an important part of our culture. For interns, this means working on projects, while supported by several mentors on their teams. At Asana, mentors serve to unblock interns, connect them to teammates to collaborate, and be a coach. They help interns find the work they’re interested in and enable them to achieve their goals.
“My mentor had a lot of knowledge about operating systems in general and guided me in the right direction. I wouldn’t have been nearly as effective without him.” – Andrew
“Even though people on my team technically knew what was going on, they didn’t know how to fix every problem we encountered. We tackled those issues together instead.” – Tammy
“At first, my mentor was very hands-on. We spent all of our time together working on the same problems. Later on I transitioned to working on things by myself, always asking her when I had questions.” – Molly
“I took down Beta for about an hour one day and my mentor took me out for ice cream.” – Nathan
“I really enjoyed that everyone on my team was willing to take the time to mentor me.” – James
To read more about mentorship at Asana, see Engineering mentorship at Asana.
How does Asana’s culture impact the internship experience?
At Asana, we have events because they’re fun, but also because we want to foster a sense of community. We ramp this up when our interns are here, and we ran over 20 events this summer! Some team favorites included:
- A visit to KitTea, a cat cafe near the office
- Movie night, with popcorn, featuring a showing of Mean Girls
- A summer camp-themed Back to School social, with campfire and activities
Our interns felt connected to the company in different ways. Here’s what they had to say on Asana’s culture:
“I love that everyone is focused on learning.” – Nathan
“I appreciated how willing people were to help. If I were working on a part of the code that was relevant to someone, they were very willing to guide me through it.” – James
“The people I have interacted with have been really great. Everyone is nice and really open to talking.” – Tammy
“My favorite part was the focus on meditation and non-violent communication.” – Molly
“I loved that my mentor helped me focus on my interests. He found whatever opportunities he could to help me get the experience I wanted.“ – Andrew
To read more about how we think about making Asana a great company for new grads, see Advice to engineering new grads: Don’t start your career at just any company.
To learn more about our university program and see open positions, visit our University page