Also posted on Medium here.

If there is one tip I could share with my fellow new engineers, it would be… Stop relying on the “Frontend/Backend” axis to understand the engineering you like. The “Frontend/Backend” axis doesn’t map well to engineers’ motivations. If you only use that axis, you can end up in projects you don’t like or worse still, give up on engineering prematurely. Instead, try using the “Product/Infrastructure” axis as the first axis to understand your career preference.

My goal is to share with you the language that could help you (and your manager) find your “sweet spot” engineering role. It took me a couple of bad internship placements and pure luck to figure this out. So I hope that this essay saves some of you months of job mismatch. Shoutout to Bolu who after my Tweet thread on this thesis went viral on Tech Twitter, suggested that I turned the thread into an essay¹.

“Product/Infra” maps neatly to the psychology of how engineers pick projects and their motivations for learning to code. Broadly speaking, there are 2 types of engineers²:

1. “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.

2. “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.

Product-first engineers map to “Product engineering”—building, launching and maintaining features that solve user problems. They often love being in the same room as designers and product managers to learn about users, and they love finding technical opportunities that can improve the product.

Code-first engineers map to “Infrastructure engineering”—building infrastructure platforms that support applications, be it via building CI/CD pipelines, implementing logging, or supporting high traffic etc. They’re motivated to better the craft of programming and are often obsessed with things like test coverage, using the latest technologies, code architecture, etc.

(To be clear, there are “Product engineering” and “Infrastructure engineering” roles whether your users are external customers, third-party developers or internal consumers of an API³.)

Notice that both Product engineers and Infrastructure engineers touch the frontend and the backend. Many of them, especially product engineers, choose to specialize into frontend or backend as well. The “Frontend/Backend” division is still a valuable axis.

However, using the “Frontend/Backend” in isolation of “Product/Infra” in project selection can lead to engineer-job Mismatch. Especially amongst Product engineers. I am a Product engineer. When I tried out “Backend engineering” in an internship, I was assigned to an Infra role where day-to-day I migrated databases. I had joined the company because I wanted to work on their product. But I didn’t have the language to explain that to my recruiter. They conflated “Backend” with “Infra” and I ended up with a role too far from the user.

When I tried out “Frontend engineering” in another internship, I was assigned to a product close to the user. But the frontend engineers and I were left out of the meetings that discussed how the features would solve problems.

If you split your engineers by the type of technology they work on (i.e. “Frontend/Backend”), it is easy to assume that your Frontend engineers are happy to just work on translating finalized designs into UI/UX components. But if you split them based on their motivations (i.e.”Product/Infra”), you’d want to loop your Frontend product engineers into product discussions.

(The same engineer-job mismatch happens for Infra engineers too, but it is less prevalent because the “Frontend” and “Backend” labels usually only officially apply in Product engineering.)

Now, this next part may be a reach… but I think many new grad Product engineers choose to be Product Managers because of this inadequate “Frontend/Backend” division⁴. Let’s jump back to my two internship examples. How would you feel if these were your only two internships over your college career? Given that you spent 12 weeks in each role, wouldn’t it be reasonable to conclude that those roles were mostly what “frontend” and “backend” were all about? Wouldn’t it be reasonable too to conclude that since you didn’t like both types of engineering, maybe engineering as a whole wasn’t for you? (And this self-dejection is especially easy to fall into if you are part of an underrepresented minority in engineering.) Why not be a Product manager and solve user problems?

This scenario is very common. Engineering is esoteric. Even with an intern-team matching process, an Product engineering intern may not know that they should select Product engineering roles, let alone know which roles are Product engineering roles.

But what if that same intern uses the “Product/Infra” language and advocates for a “Product Engineering” role?

I was such an intern. I was so drained by my Infra role that I reached out to Product Managers in the company to enquire about their jobs. But then I advocated⁵ for a Product Engineering role and… my manager gave it to me. As a backend engineer on a product team, I worked with a team to build the Video Newsfeed in Robinhood. I built a large backend pipeline and also had the chance to engage with product questions regarding newsfeed ranking, video tagging, and user engagement. I spoke with engineering, data science, and business, balanced those interests, and wrote the resolution in code.

I found my sweet spot.

At the end of the day, engineering is multifaceted and can be defined along more than one axis: B2B vs. B2C, B2B top-down vs. B2B “bottom-up”, API-first vs. application-first, “Forward deployed” vs. “Software engineer”, etc. If we’re serious about making engineering accessible to all, we should champion any and all frameworks that can help new engineers find their sweet spot and be happy.

Notes