Our engineer team is known for bringing our dogs to the office and wearing Vibrams to work. But you're probably wondering what we actually do each and every day.
In just a few sentences each, let us explain!
Meara Charnetzki: I’m actually the very first support engineer on the team. It’s a new role. The idea is that the engineering team is heads-down a lot, and it’s distracting for some smaller, low-priority bugs to come in, so I’m pretty much the front lines for bug-defense. Bug squasher extraordinaire! And I do some other smaller UI improvements, things that affect students here and there and aren’t great for the user experience, but things that aren’t necessarily huge problems that need dedicated resources to work on.
Ken Schultz: I come from a Java background. I work with Rails and front-end development now. I’m kind of all over the stack, essentially. *Pets adorable black labrador retriever dog sitting on his feet*
Alex Koppel: What I do is maybe a little different than what the average engineer here does because I’ve been here for as long as I have. But I’m working on various projects, figuring out what are the things we want to accomplish like launching a given product, designing it, or handling some other technical need to build some product or address an issue. But what I also do is spend a lot of time thinking about where we’re going and what we’re going to need technologically two to three years out. What are the decisions we need to make now that we’ll be living with in two years that have to be right for both now and then? What are the strategic technical issues that are going to come up?
Kairui Wang: Like most of the engineers here, I’m what they call a “full-stack engineer”. What that means is that a lot of what I do is centered around building a particular product. So usually there’s some feature we want to build. And we say, in order to make some feature happen, what kinds of things do we need? Typically, there’s some amount of data that needs to be stored, there’s some amount of logic that we need to implement to make it happen, and there’s also some amount of user interface work that we want to add so that students and teachers can see the changes we’re making. Basically, being “full-stack” means that you are really thinking from the project perspective. So you’re working within all three of these layers: the data, the back-end (the business logic), and the front end (the user interface).
Hillel Wayne: My specialty so far has mostly been trying to implement something relatively small, realizing there’s a slight problem with the architecture, yelling at everyone nonstop, taking an axe-saw to the code base, trying to make it better, and after two weeks giving up and implementing the feature, and then occasionally saying “hey guys, we should work on this in pairs!”
Nathan Hatch: We all tend to do a little bit of everything, which can be anything from managing our servers to writing new features for the student experience or for teachers and admins.
Denis Roarty: Hillel and Nathan have covered almost everything, but I’ll add that we practice test-driven development. And I came from a totally non-test driven development background.
Gursimran Singh: I was an engineer when I joined, and now I’m a lead engineer. Largely what I work on now is growing the engineering team and also growing our product. What that means is that we want to have a strong impact on how students learn so that they can learn at their own pace, and we also want to reach a lot of students. So the kinds of projects I end up doing are related to solving all of those tiny problems that on a manual scale (by hand) aren’t a big deal, but when you try to scale it for thousands of students it becomes a problem. Basically, it means that I’m making processes and systems workable and possible at a large scale.