There comes a time in most every software engineer's career journey where a decision has to be made: front-end or back-end. But also maybe full-stack, DevOps, mobile, infrastructure, data engineering, etc. The point is that specialization is often a must for getting yourself into that next level of engineering roles. But choosing which path to go down isn’t always a no-brainer.

For some tips on deciding how to specialize in software engineering, I spoke with Mixpanel’s director of engineering, Aniruddha Laud. The former product engineer had his own interesting path to finding his calling in back-end and infrastructure.

The conversation below has been edited for clarity and brevity.

To start, I’d love to hear how you went about choosing a specialization in software engineering.

It wasn't really deliberate at first.

I did my undergrad in India, then I joined a fairly small startup in India where engineers on our team were actually doing a little bit of everything. But most of the challenges were on the product front, so it ended up that most of what I did was product-facing. It was only after doing that for a year that it became clear to me that I actually wanted to do infrastructure work.

The aspect that I liked about being a product engineer was the obvious user impact. Like, you add a feature and people are directly interacting with the code that you wrote. The part that I did not like as much was that, without a good understanding of the things actually powering some of these products, you tend to only have a very cursory high-level knowledge or understanding of how things are built. A lot need to happen behind the scenes for your product to actually do what it does, obviously. So when I decided to go to grad school at Stony Brook after that year, I was only really interested in distributed systems and infrastructure and those kinds of courses.

When I got done with grad school, I looked for jobs outside of the product front. I ended up joining Twitter, because I used and liked the product, but also, importantly, there were lots of interesting infrastructure challenges there. When I moved over to Mixpanel in 2015, the reasons were similar: There were a lot of challenges on the infrastructure front.

So you went from the umbrella of product-facing work to infrastructure work. Are these sort of the overarching engineering categories someone has to choose between before driving down further into more specific roles from there?

I would say for the most part, yes. More and more companies now have DevOps teams, too, and those jobs are more of just managing machines and those kinds of things. But most companies typically have either infrastructure engineers — positions like back-end, distributed systems, and those kinds of things — and product or front-end engineers.

You made your specialization choice between one side and the other after working in the industry for a year. Is that the best way to do it, or should students try to figure out where their interests lie before they graduate?

I think knowing what to specialize in is not something that you would get from academia. When I got out of school, I had no idea what I wanted to specialize in. I think it’s something that you only understand by getting that breadth in the field.

I would recommend people who are starting out to look at generalist roles, like an infrastructure generalist or product generalist instead of like something very specific. If you get into, say, a front-end role, you are only going to do JavaScript and other very specific things in the front-end. You want to try to optimize for getting a good sense of how everything works, end to end. And then you will actually figure out what excites you.

I’ve found that a good start to figuring this out is if you're a person that is excited by having others use your products, you're better off being a product engineer than working in infrastructure. You can iterate quickly, build up a scrappy prototype in like five days. Then you can have people testing ASAP and throw it out and start over if it doesn’t work. Infrastructure is not the same case. It’s going to be indirect and slower, but more time is spent on building things the right way.

Can a full-stack role be a real “best of both worlds” kind of job?

It can depend on the company. There are companies where most of what you would be doing [as a full-stack engineer] is just back-end infrastructure. Think of something like CockroachDB. For the most part, they have back-end needs. But there are other companies — something like Reflektive, maybe — where most of what they're working on is just the product itself, and there isn't a whole lot of back-end engineering going on.

You’re a manager who oversees engineering from both the front- and back-ends at Mixpanel. Would you recommend anyone interested in getting into management have experience working in both those areas like you have?

I don't think [having held product and infrastructure engineering positions] really matters so much if you're trying to become a manager. Your goal as a manager is to make other people successful, and that’s no matter what they do. You're not as invested in the technology as much as you are the actual individuals. Having some experience in the tech can obviously help in the job at times, but I don't think it is required as much as something like empathy [and other people managing skills].

How about specializing when it comes to working on specific teams at companies? How important of a choice can that be?

For people starting out, I would try to find a team that is very core to the business. One thing I hear often is, “I just want to work at Google, but I don't care about what team I'm on.” At Google, if you're not on the Google Ads team, it can be hard to have impact in the company. Ads is core to the business. Same with Facebook — you want to be on the Facebook ads team.

Once you've established yourself as a leader, then you can move on to [potentially more interesting] side teams doing things like Internet of the Future.

Since infrastructure is your speciality, do you have tips on where new engineers who recently decided to focus on that area should spend their time?

I think what's really important these days is for people to be very comfortable with the cloud. You really need to have a good understanding of AWS, Google Cloud Platform, whatever your pick is. Building a good background in distributed systems is also very important for someone doing back-end engineering today. On the other hand, I would say not to focus too much on languages. When I started off in infrastructure, everyone was using Java, and now a lot of companies are using Go. Five years from now, Go could still be cool, but it might be something else. You’re going to want to try to learn the basics of different languages.