When did you start working at Gilt?
I moved to NYC right out of college at the end of 2009, and started working at Gilt not long after that. At the time Gilt was still a startup, and was building out its quality assurance operations. I was hired to be a manual tester, which meant testing small features and changes on a day-to-day basis. Eventually I branched out into automation.
Although you were a QA engineer, you found ways to develop your coding skills.
In my early days at Gilt, I got automation and release management experience, which involved code coverage from Selenium tests, migrating code from an engineer’s commit to testing in stage, and getting the code to production. In 2011, I realized that I wanted more coding experience than that, so I enrolled in a Java Web Services course at NYU’s School of Professional Studies. Earning my certificate really helped me measure and prove that I knew how to code. I highly recommend that course, by the way.
Was Gilt supportive of your Java study?
Yes. I mean, it was all on me that I pushed myself to do it–no one else was going to do that for me. But there’s a lot of support here. There’s no traditional ladder to climb–working here is all about making sure you push yourself to new levels. People want to see you succeed.
More recently, I took the Scala class that Gilt hosted at our NYC office. It’s great that the company is investing in teaching us new skills. Even nicer was that the class was completely free and open to anyone. I just wish it had been longer than one day.
After you finished the Java certificate, how did you apply your new skills on the job?
Other engineers here knew that I wanted to learn how to code, so one of my colleagues taught me front-end development, and Yoni [Goldberg, Popeye Team lead engineer] taught me about service-side/back-end coding.
While still enrolled in the course I started diving into front-end development, and helped out with small features. After I got my Java certificate, I started taking on features by myself, and eventually was promoted to software engineer. I’ve since been a member of Gilt’s Popeye team, which works on the Login & Registration experience, SEO optimizations, and the new Insider loyalty program. Because of my QA experience I’ve been helping Popeye with our automation coverage while gradually becoming a full-time developer and taking on new features with the Scrum team. Like all of Gilt’s engineers, I’m expected to take product leadership and own my features.
How do you decide which projects to work on?
Because I’m still a junior engineer, I look for the smaller projects that can result in a higher ROI on a low amount of input for changing code. Recently I worked on Gilt’s wait-list page; the project involved UX, and no other engineers were free to take it, so I took it up.
How did Yoni and Team Popeye support you?
Yoni gave me the push and said, ‘it’s a great project, no one’s doing it, I think you should take it on.’ I was pretty skeptical about doing it by myself at first, but I dove into it and, piece by piece, it started to come along. All the engineers on my team know how to write code in service-side, so they helped me figure out how to do something scalable while not jeopardizing performance.
Because of the small projects I worked on prior to wait-list, I knew my way around the code base. The work was really fun. I had to wait a bit for the rollout of other features until I could turn on my own–but this was good, because I wasn’t sure how great my work was, or if it would cause problems. Having to wait gave me time to make sure my work was iron-clad and address edge cases that came up over time.
Old wait list:
How do you generally respond to setbacks?
You can’t call anything that happens “bad,” because you learn from every experience. Bugs can hurt revenue and your metrics, but it’s one of those things where, if you do something wrong, you learn never to do it again. At Gilt, we evaluate why things sometimes go wrong, as opposed to taking a “move on and don’t look back” approach. We try to put as many safeguards in place as possible, to prevent problems.
To avoid issues, we have strong code reviews, high levels of test coverage and great tools for deploys.
Doesn’t code review act like a personal progress measurement of sorts?
Yes, kind of. Starting out, I had tons of iterations, and then they became fewer and fewer. That’s when I knew I was getting better. My goal was to have fewer complaints.
The engineers looking over my code were hard on me, but this was helpful to me in getting the fundamentals down and knowing why things are done a certain way. Even seemingly minor issues like a missing space they would call out, just so I’d be up to the standards they were expecting. You don’t write code for yourself–you write it for others, or for yourself a year or two from now.
In one word, how would you describe Gilt’s work culture?
Empowering. People here are willing to help you do what interests you. If you identify a need, and want to help fill that need, the company responds. That’s what gives you more opportunities to succeed.
Any advice for engineers who are just starting out?
Technology’s always changing, but it keeps you on your game. You’re always learning something. That’s what an engineer is–someone who can pick up a project and figure it out, solve the problem, without knowing much of anything about it.
The hardest time for a young or new developer is the beginning. But over time, and with perseverance, you’ll gain confidence and know that you can build something out. Pick fun projects, and enjoy what you’re doing.