This is the first of a series of interviews with engineers at Grammarly. We want to highlight the personalities, backgrounds, talents, and perspectives of our Engineering team—the people who bring to life our ideas.

Today our interviewer is Stas Kravets, a back-end engineer on the Acquisition team, the team that helps Grammarly to expand our user base. Stas has been with Grammarly for close to six years. Stas will be interviewing Sunshine Yin, a full-stack engineer on the same team. Sunshine was an intellectual property lawyer before she became a software engineer. She joined Grammarly about a year and half ago as the second engineering hire in Grammarly’s San Francisco office.


Stas and Sunshine

STAS: Sunshine, you have an unusual background for a software engineer—you were a lawyer. What inspired you to become an engineer instead?

SUNSHINE: When I was looking to leave law, I met with dozens of people to try to understand their jobs. I tried a lot of things, but coding was the one thing that stuck. And when I say “coding,” I don’t mean just the physical act of writing code, but the engineering ethos as a whole.

The first thing that drew me to engineering was the sense that it’s a community that values efficacy and solutions over ego. It is one of the most welcoming and meritocratic work cultures I’ve found. To be proven wrong is healthy, because it means you learned something. That’s the kind of community that I want to be in. It’s also the kind of engineering environment that Grammarly offers.

The second thing is that coding is simply addictive—there’s a dopamine surge from the instant feedback you get about whether your code worked or not. But that’s just the beginning. What makes coding so appealing to me is that the same working piece of code can be written in different ways, which requires creativity, sound judgment, and the ability to hold abstract, interconnected mental models in your head. In other words, your code is on a spectrum of right to wrong, and it’s a multi-dimensional spectrum where reasonable minds can disagree depending on their preferences and experience (geez, that almost makes it sound like law, doesn’t it? Uh oh…)

STAS: Having been in the industry for almost 20 years, I agree with your evaluation of engineering culture. The only thing that matters is the quality and elegance of your work. Coding is addictive to me as well because it feels very powerful to create new things. Moving on: what was the hardest thing about the transition? Was it scary? Was it super time consuming?

SUNSHINE: Yes, to both. But I actually got to a point where I felt that I was taking a bigger risk by not making a career switch. I felt stagnant at my last job. It was also scary because I was still trying to pay down law school loans and worried about my ability to continue living in San Francisco. Financial concerns aside, though, the hardest part was making the decision itself. Part of me felt like, gosh, I’ve spent three years in law school getting this shiny law education—am I really just going to throw it away? Once the decision was made, though, executing on it—even the financial aspects—was not so scary. I scrounged for several months and took out a personal loan to pay for Hack Reactor (a coding bootcamp) and to ensure I had at least six months of runway.

Ultimately, I was more afraid of being stuck in a rut than of failing at something new. My friends were incredibly supportive, too, which helped a lot with the emotional toil of the decision.

STAS: That was very brave indeed. I admire people who have the guts to change their career after investing a significant amount of time and money into it. I know people who have left careers in chemistry, finance, and electronics to become very successful engineers. What are some hard things about being a newish software engineer?

SUNSHINE: My transition happened quickly. Like I went to bed in a suit and woke up in a hoodie. I didn’t have a chance to figure out what being a good software engineer means to me, so I rely heavily on observation of how other people are doing it. I’d like to be able to develop better internal judgment.

Because I didn’t major in CS, I also constantly feel like I have to play catch up in my free time. For better or worse, this feeling of insecurity (what many describe as imposter syndrome) is a great source of motivation for me. It keeps me on my toes and ensures I maintain an open mind. But it’s sometimes stressful to think that no matter how many hours I put in, I may never be as fast or as good as people who’ve been coding since they were kids. Being surrounded by others who are much more experienced than I am is very humbling but inspiring.


Sunshine coding

STAS: I remember in the 90s it was enough to know one programming language and one framework to start doing things. Now, the industry evolves so quickly that unless you are supporting legacy code, you have to constantly learn new stuff. How stressful was it to start?

SUNSHINE: I’m not sure if you or others could tell, but there were some days when I felt completely lost. Sometimes I had nothing to show for my hours at work, and yet at the end of the day I felt completely drained. I was also slow to ask for help, in part because of the time difference (half of our engineering team is based in Ukraine), but also because I was afraid to let on what I didn’t know, so I developed a habit of just banging my head on things until I figured them out. It was good in some ways, but bad because it made the development process slower and impeded my learning.

STAS: I remember this time. We were ready to help, but I guess this is something that everybody has to go through on their own. Clearly, you survived and are stronger for that experience. Since then, you’ve shipped a great many features to production, from simple to complex, sometimes solely responsible for their implementation. What are the most notable things you’ve worked on?

SUNSHINE: In my first few months here, I built grammarly.com/edu, which helps educational institutions learn about Grammarly and allows them to buy subscriptions in bulk for their students. Our web stack is Webpack + ES6 + Babel + React, and I came in with almost zero experience in any of these, and no experience dealing with payment APIs such as Braintree, etc. It felt like a huge triumph to finally have my code merged. The best feeling was that, by the end of the project, I felt like if given the same assignment, I could’ve done it in one third the time. Here’s a before and after of part of the site:

Before:


After:

It’s also been rewarding to see the impact of my work. What I built helped pave the way for an enterprise-level product. Our team is now working on expanding our offering for enterprise-level users by building a dashboard that shows usage statistics and helps manage their accounts.

Another thing I’ve enjoyed is working with the marketing team to implement experiments they create (e.g., if we want to A/B test certain designs or functionality). I love brainstorming ideas, and implementing experimental designs and features means that I always have to teach myself new stuff. Also, I realized that because of my background in writing (I was an English major), in IP law, and in inhabiting the mind of a tech noob for most of my life, I’m good at breaking down technical concepts in a way that non-engineers can understand, which helps our marketing team to design experiments and products that take into account engineering complexity and effort.

Though my experience at the outset was more focused on frontend, I’ve also done backend work at Grammarly. Actually I recall that you led a Java tutorial for me and a couple of other frontend engineers when I started, and within a couple of weeks, I had Java code in production. I’m currently working on an analytics dashboard for users to be able to see their usage statistics, and there’s been some fun SQL work, too. The next big project I’m eager to tackle is building out our own in-house experiment framework. (Because of the technical limitations and integration-related inefficiencies we’ve encountered in using 3rd party A/B testing frameworks, we think we may need a more custom solution that we can better control.) I’m really excited for the expected and unexpected challenges this will bring.

Finally, our teams at Grammarly are vertically integrated, which means we don’t outsource DevOps to one team; instead, every team is responsible for the whole process of deploying their own projects (from configuring load balancers to continuous integration to monitoring/alerts), so that means individually you are given a huge amount of latitude, ownership, and responsibility. Navigating this web of technologies and interdependencies was pretty confusing at first, but increasingly I have a greater appreciation for the art of infrastructure and architecture design.

STAS: Let’s talk about the team now. What do you like about Grammarly?

SUNSHINE: Everyone at the company is well-intentioned. There is no ego. People may have very different opinions about what is best, but I feel very confident that everyone shares in the good intent.

Our engineering culture also really fosters curiosity and learning. Every other Friday we have “fun days” where we can work on pretty much anything we want to. Tech leads volunteer to teach classes on functional programming (Purescript) and encourage us to carve out time to do things that interest us, not just to tick off Jira tasks. Our team is resourceful and inventive—we love building our own tools, we have spirited debates, and for better or worse, we have a litany of languages in production (which we are trying to standardize), everything from Go, Lisp, Clojure, Scala, Java, Python, Purescript, Typescript, and more. And this week we have a Hackathon for our entire engineering team!

Basically, I get to learn a lot while making a product that improves people’s lives, and I work with a diverse, empathetic, and exceptionally talented team. It doesn’t get much better than that.

STAS: Do you have a better vision of things you want to do and achieve in tech?

SUNSHINE: Something I realized after getting into tech is that not everything is a software problem. Most problems are human problems, and sometimes tech is the solution and sometimes it’s not. In some ways, technology—software in particular—has made our lives immeasurably better, and in other ways it has estranged us from the experience of being human. I want to use tech to bring out the human in people.

STAS: What are the lessons learned you think may help others?

SUNSHINE: Shed your ego. This is pretty cliche, but it’s something I still struggle with. Get comfortable with discomfort, like the discomfort of not knowing how to do things.

Persistence every day, but to a limit. If at first you don’t succeed, try again. But the tenth time you don’t succeed, you should probably just sleep on it.

Just try things—this is something I still struggle with. Sometimes I tend to think too many steps in advance and get paralyzed by the internal debate in my head. Try something and then learn from it.

STAS: That’s it. I hope our talk will benefit many human beings and motivate them for a change. Thank you! Keep pushing, we have many new features ahead!