Things I've learned while working at Groupon

Today marks the end of a three-year journey I’ve taken with Groupon. I could write at length about my wonderful experience here, but I think it’d more useful to share some of the valuable lessons I’ve learned along the way. So here are a few of them, in no particular order:

Good management is extremely multi-dimensional

I’ve had the privilege of working with extremely effective managers at Groupon. Across the board, I’ve noticed that they:

Interviews are most useful when they bring out the best in candidates

Most people who work in engineering have heard (or experienced) horror stories of entitled, arrogant engineering interviewers trying to trip up interviewees and then belittling them when they make mistakes. Fortunately, Groupon’s recruiting staff is very aware of this problem, and has taken deliberate steps to make our interview process more effective.

Before giving any interviews to candidates, Groupon engineers are required to participate in thorough, thoughtful interviewing trainings. One element of the training that particularly impressed me was the focus on making sure a candidate feels comfortable during the interview. This should be obvious, but it turns out that most interviewers don’t think about this unless specifically prompted to.

This idea, in my opinion, is based on the premise that tech interviews are unfortunately a bit inherently flawed. Tech interviews test candidates on their technical abilities in an environment in which they’ll never actually work: that is, with an employee over their shoulder, watching them code, and all the while deciding whether or not they deserve a job at the company. Not many people perform at their best in that environment! And those that do aren’t necessarily the most qualified developers: being able to write code while someone watches and evaluates you is a very different skill set from being able to write code that meets a team’s and company’s needs on a daily basis.

So the culture of interviewing at Groupon was focused on ensuring that a candidate feels at home during a technical interview. I often would tell candidates to treat me as a coworker while coding on a problem – that is, to talk through their thought process verbally, to ask me questions to the extent that I can answer them, to Google things when it makes sense to, etc. The result is that I was able to get a sense of what it would be like to actually work with the candidate day-to-day, which is far more useful interview feedback than whether they can uncover traps I’ve laid for them while I berate their coding ability.

Software development is about so, so much more than writing code

I think that learning this lesson was necessitated by the fact of working at a huge, international corporation. I’ve observed that the most successful developers at Groupon – and by successful, I mean those who are first to be promoted, are granted the most autonomy, and tend to have the most influence over significant engineering-related decisions – are those who understand the anatomy of a large company. They are those who understand that interpersonal/-departmental interactions don’t function in the same deterministic, “tidy” way that code does.

The challenge is that it is in the nature of software engineering to encourage engineers (or at least, junior engineers) to think about problem-solving in a very specific, narrow way: I’m given a task, and I have specific tools with which I can complete it. But being successful at a large company like Groupon requires also working with people, not just code.

With teams distributed around the world that each have their own viewpoints and codebases and timezones and concerns, being a successful software engineer thus requires that you learn additional tools. Among others, these include:

I’m sure there are many others, and I certainly don’t claim to master all of these. But it’s been educational for me to see these tools in use at Groupon, and they have in turn become criteria I use when interviewing candidates for senior positions.

Career growth doesn’t have to mean moving into management

I, like most other developers I’ve worked with, really like writing code. And it doesn’t make sense to us that, the better of a developer you are, the more likely you are to be “promoted” into a management role where you’ll no longer get to write any code. What a waste of a great developer! And furthermore, the skills required to be an effective engineer have limited overlap with the skills required to be an effective manager. As my former manager Chris Powers mentioned in his great talk on making the switch from developer to manager, asking a developer to manage a team is reminiscent of the Mitch Hedberg joke, “Oh, so you’re a chef! Can you farm?”

That’s why Groupon doesn’t force engineers into managerial roles when they’re promoted. You can instead work your way up the software engineering ladder by growing technically and by learning to contribute effectively to the company’s engineering organization.


Prior to Groupon, I had worked primarily as a solo developer, with only Google to consult when I wanted to learn about some new technology or best practice. I joined Groupon in part so that I could be surrounded by experienced devs from whom I would learn and grow technically. And while I’ve had the privilege of being surrounded by some of the most talented devs I’ve ever met, I’ve found that it didn’t just make me a better “code-writer”: it also taught me what it means to be an effective contributor to an engineering organization and a whole company.

So while I’m excited for my next opportunity, I’ll always look back fondly on my time at Groupon. And when I mention Groupon’s name in writing, it’ll continue to be accompanied by Unicode code point U+1F49A. 💚

Me posing with a Berlin TV tower made of Groupon-green LEGOs