Klaire joined us this summer from the Computer Science program at Yale, where she is a member of the rifle team and a course assistant for CS50 (Intro to Computer Science). She's taking a gap year and will be continuing to work at Meteor through the fall.
Klaire joined the Services team and has touched every part of the stacks that our commercial products run on. She started by working on Galaxy and implementing some of the most highly request user features. She built a new page in Galaxy that shows users a list of all the versions of their app that have been deployed, and allows users to quickly and easily restore to any given app version in the history log. She also improved the safety of app deployments by writing a checker that tests whether or not a version will successfully have a healthy deploy before rolling all of that app's machines to the new version. Towards the end of the summer, Klaire also started doing a lot of frontend feature work for MDG's next commercial product.
Interview
How did you get into Computer Science?
Growing up in Silicon Valley, I was exposed to computer science from an early age, but I didn't actually have the chance to try it out for myself until college. I was really lucky to have CS50 as my first intro-to-CS class because there's a huge community and everyone gets together for office hours in a huge room that looks like the great hall from Harry Potter. No other class had that kind of community and it was really fun to get to work with all those people together on psets and problems.
What made you choose Meteor?
Like all good startups, everyone I talked to at Meteor was passionate about the work they were doing and the impact they made, but what really struck me was the sincerity, the kindness, and the sense of community. It was incredibly important to me that wherever I was, I could dare to ask those “stupid” InternInterviewQuestions and someone would answer them seriously.
And as I talked to more and more people at Meteor, I realized this might be that kind of place. Somewhere where I could ask until I understood and make honest mistakes and not be afraid of tripping up a few times along the way. And that seemed like the best place to become a better engineer.
What was it like working on commercial products?
I think being on the commercial products team gave me the opportunity to work on a lot of technical aspects of the product. I got to touch the frontend side and learn more about the backend required to be able to actually host apps for Galaxy. It was really nice in that there was a wide range of things I was able to learn and experience. On another team it might have been more focused (open source is heavily web and javascript), but when you're on the commercial side you can touch a lot of different kinds of things.
What’s a unique challenge you worked on this summer? How did you overcome it?
There have been so many challenges! Figuring out cursor-based pagination for GraphQL and Apollo when there aren't detailed tutorials on it yet. Figuring out asynchronous JavaScript. Figuring out Babel and Webpack configurations. I feel like a lot of the challenges were less problem solving and more environment issues and configuration, but there were a lot of very long slack messages that I sent to Tim in the middle of his night (he's in Australia).
I overcame them through a lot of Googling and Stack Overflow. A lot of trying things out to see what might work and trying out everything it could possibly be if I didn't have someone to ask. Asking other engineers who might know what the issues were was the most helpful, but sometimes I felt like it wasn't a big enough issue to ask about, so I tried a lot of different tweaking.
Did you discover any new passions this summer?
I would say competitive ultimate frisbee! When the sun was still up past 7 I would throw after work and I'm going to try and join the fall club league in the South Bay.
What surprised you the most about the team?
My head sometimes spins at how much trust, ownership, and responsibility the team bestowed us. We were interns, and yet in a summer, we touched and built core features of all of MDG's projects, from Engine to Galaxy to Apollo Client to the Meteor framework. There was no intern “side” project. We all tackled projects to achieve meaningful improvements. And throughout the process, my ideas were taken seriously. Engineers helped explain shortcomings, highlight pros, and participated in a lot of great conversations about design approaches in our projects. Even though we were interns, we were never “just” interns. Everyone at Meteor believed in us (maybe more than you might in yourself) and treated us like a fellow engineer.
What piece of advice would you give to next year's interns?
I think it's really good to keep a log of every little thing that you figure out. If it's a weird webpack issue (say you've never touched webpack before)? If it's how ECS and AWS machines work? It's good to jot those things down. It's good to jot things down because you're more likely to remember them and it'll be easier to start compiling a list of how things work. You think you'll remember all the small things as you go, but that can be hard.
David (my mentor) for example somehow knows the precise six characters that you need to write to a random unix command that will get you a sorted list of CPU information. People know all this random stuff, and they don't remember things just because they saw it one time, but because they figured it out and jotted it down with the intention of remembering.
The Services team does a standup on Slack, but it's good to also keep a log of what you do week-by-week. If you don't keep track of time the weeks and months go by a lot faster than you expect. If you keep a log you're more grounded and aware of the passing of time. It'll help keep you on track!