School: MIT (Computer Science and Music)
Fun fact: I built a violin in high school and it sounded pretty good. Also, my right thumb is shaped like a toe.
Team: Platform & Infrastructure

School: Stanford University (Computer Science)
Fun fact: I play ultimate frisbee and once got to play with Bill Nye as part of his Netflix show.
Team: WNRS (Workflows, Notebook, Requests, Spreadsheets)

School: MIT (Computer Science and Molecular Biology)
Fun fact: If offered a one-way ticket to become a Mars colonist, I would do it.
Team: Infrarad Scientists (Molecular Biology, Front-end Infrastructure)

Rebecca: “My friend from college, Tony, currently works full-time at Benchling. He’s the one who initially put Benchling on my radar and encouraged me to apply. I have very little biology background, but I was nonetheless intrigued and impressed by what I observed about Benchling. For example, during the application process, I read a blog post about Tony’s intern project from a few years back. He built a customized and performant DNA search engine over the course of the summer, which made it to production shortly after. That sort of high-intensity, high-impact project was exactly the kind of thing that I was looking to work on during my own internship. Benchling’s caliber of engineering and their commitment to giving interns consequential projects is ultimately what convinced me to spend my summer here.”

Kevin: “I interned at Benchling in the winter, and initially chose it because I’d experienced firsthand how cumbersome paper lab notebooks could be in biology research. After that experience, I decided to return for the summer because of the complex product problems to tackle, the collaborative and nurturing culture, and the company’s promising impact in accelerating life-saving technologies.”

Karen: “At school, where I take classes in both fields, I’ve always been struck by the difference in the pace of work in computer science and in the pace of work in biology. Even in other fields of research like psychology, iteration time can be a lot faster because scientists aren’t limited by ordering antibodies, waiting for cells to grow, and so on. I thought that working at Benchling would be a great balance between my interest in molecular biology and my interest in computer science, while also being an excellent way to relieve the frustration I experienced in lab classes due to the slower pace of life science research.”

I built out Benchling’s support for codon optimization during my summer internship and readied it for release. Codon optimization is the process of tweaking a DNA sequence to make it easier to work with or easier to translate into a protein. It was a highly requested feature from our users, across life science industry and academia, because they are interested in artificially synthesizing proteins from DNA. Codon optimization is biologically possible because the conversion from DNA to protein is not one-to-one. For example, the codons TTT and TTC both encode the amino acid phenylalanine (F), so we can switch one codon out for the other and still get the same protein.

In the feature I worked on, users select an input sequence and optimization parameters, and then run the optimization process to get back the optimized sequence. The most interesting parameter for me was to optimize a sequence from a source organism for a destination organism. Imagine a scientist that wants to have bacteria synthesize a human protein: the original human gene may translate poorly because concentrations of codons within humans (source) and bacteria (destination) differ, but codon optimization can tune that, while making sure it translates to the same protein. To make this work, I integrated the open-source DNA Chisel library into Benchling and extended it to support the full set of our parameters. I also moved the codon optimization UI to live side-by-side with the DNA sequence; before it was siloed in a modal. This required bridging legacy code in Backbone/JavaScript with my code in React/Redux/TypeScript. Toward the end of my summer, I iterated on the feature based on customer usage and feedback, and then we released it widely to all.

Benchling engineers periodically participate in an infra week where they focus on projects to improve developer productivity. During that week, I standardized the way objects in our product are addressed. For example, a DNA sequence can have ID seq_fcZi9llW. Before, it’d have varying URLs like /seq-fcZi9llW or /fcZi9llW. These inconsistencies across the product were adding overhead for both developers at Benchling and our customers, so I standardized them all to /seq_fcZi9llW. Now, objects are identified in the ID and URL the same way. I had to make the change carefully because some features specially parse Benchling URLs, and we also didn’t want to break legacy URLs.

I overhauled the way users input lab inventory locations in Benchling’s tables during my summer internship. Benchling has a lab notebook with tables for users to enter tabular data, and it also has an inventory database for users to track the locations of their biological samples. These two products integrate closely: users can define a special type of table, transfer tables, that allows them to keep their inventory up-to-date from directly within the notebook. Imagine that you’re a molecular biologist, and today you’ve isolated a piece of jellyfish DNA inside of a test tube. You’ve stored that test tube, identified with a unique barcode, inside of a box inside of your lab’s second refrigerator’s third shelf from the top. This illustrates how hierarchical our users’ locations are, just like mailing addresses or phone numbers. Next to your notes, a transfer table allows you to keep Benchling updated with the DNA’s current location by specifying the source sample (the jellyfish DNA) in one cell and destination location (that refrigerated box) in another.

Before the overhaul, clicking on the table cell to select a destination location opened a pop-up modal. On one hand, power users knew how to navigate the modal to choose an existing location or create a new one. But it was a jarring experience for new users, because it took them away from the transfer table they were just filling out. I redid selecting a location to be a dropdown inline — no modal. This dropdown packed a lot of functionality that the users needed — browsing locations, searching for an existing location, navigating up and down the hierarchy (aka showing location’s ancestors or descendants), displaying the remaining space available in a location — all in the compact UI of a table cell. I also had to handle loading and managing the front-end state of this location hierarchy, so I leveraged Benchling’s abstractions around React/Redux/TypeScript (soon-to-be GraphQL) to make sure it was available on demand.

I built the Benchling Functions framework to enable customers to easily build custom integrations on top of the Benchling platform. I launched the framework internally for our Customer Engineering team, with the vision of releasing it to our end users in the future. Our Customer Engineering team builds custom integrations for enterprise customers. For example, a recent integration they built conducts a weekly PDF export of Benchling Notebook entries along with some metadata.

Our custom integrations are deployed on AWS Lambda, Amazon’s serverless compute service that lets you deploy standalone applications to the cloud without worrying about the infrastructural details such as the server on which they will be run. But of course, things are never as simple as they seem — there are many services that the Lambda might need to connect to: Benchling services, like the Benchling API; AWS services, any of the multitudes of services that AWS provides; and external services like third-party monitoring platforms. Connecting to these services can be complicated, and requires a lot of scaffolding. In an ideal world, developers writing new integrations would just be responsible for writing the core integration code, not setting up continuous integration or knowing how to package the integration. Whereas it previously took the Customer Engineering team to a few days to write an integration, this framework — with many components abstracted — allows developers to focus solely on writing their integration code and deploy an integration within hours.

I structured the Benchling Functions framework into two main parts: a CLI tool that allows you to create, develop, test, and deploy integrations via a simple interface, and a SDK for standardizing common tools across all integrations. You start with the init command, which creates a project by generating a directory containing skeleton starter code, pre-configured to work out of the box. When writing the integration code, the SDK helps you connect to various resources like a database, a secrets manager, or the Benchling API. Finally, the deploy command deploys the Lambda to production. With just a few commands, without having to worry about any scaffolding, the Customer Engineering team can deploy custom integrations easily.

During infra week, I built a Slackbot integration with my mentor Tony to improve developer productivity. Every day, Benchling Engineering makes a few releases to production. For each release, each engineer who contributed a change must verify their change on our staging environment. Our bot tracks the verification state of each release and gently reminds engineers who are left to verify, so that the release owner doesn’t have to manually keep track it themselves. Seeing our bot get used every day in the deploys channel was pretty gratifying!

We asked our interns to describe what it was like to work at Benchling.

Most of all, they enjoyed essentially being full-time engineers.

Rebecca: “I was given the same sprint allocation amount, reviewed code, made design decisions, and was generally held to the same standards of work as everyone else. I really liked this. I felt like it allowed me to work at my max potential, and I became integrated into the team really quickly.”

Kevin: “Your project is something that you get to own fully, and the work you do is meant to tackle a key product need. You get to work alongside some of the most compassionate and talented people you’ll ever meet, all of whom are always eager to pass on knowledge to you.”

Karen: “An aspect of working at Benchling that surprised me was the extent of the input engineers have on design decisions, which is due in part to the fact that Benchling is still pretty small.”

They also reminisced about some fun activities.

Rebecca: “From company-wide events like the weekly happy hours on Fridays, to team bonding at woodworking or mixology classes, to getting to know people personally during one-on-ones, it was a privilege to meet and work with such truly wonderful, capable coworkers!”

Kevin: “You’ll also always be able to find people to go on weekly Wednesday runs or hone your shuffleboard skills.”

And they noted that it’s an exciting time to be at Benchling because it’s growing quickly!

Karen: “At least a couple of new hires started work during every week of my internship, and towards the end of the summer we moved part of the company to a new office to accommodate more people. Because of this, it’s a really exciting place to work and it feels like new things are always happening.”

Kevin: “Especially at this stage of the company’s growth, every day at Benchling is an invigorating experience filled with hands-on learning and fun memories.”

Our summer 2019 interns and their adventures in DNA, inventory, and Lambda was originally published in Benchling Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.