Engineering in Big Tech: What I’ve Learnt So Far- Part 1

It’s been 8 months since I started working as a Software Engineer at a big tech company. It has in many ways turned out to be different from what I imagined. There have been unexpected challenges, and unexpected opportunities too. So I thought it fitting to reflect on my time so far and share some of what I have learnt in my first major full-time career stint as an engineer.

That LinkedIn Survey Was Right: Soft Skills Do Matter

… yes, even if you’re a coding ninja, sorry.

With the risk of coming across as immodest, I will say that I have always thought of myself as someone strong in soft skills. I can talk to people, I have experience public speaking and love making presentations. Coming into engineering, I remember thinking to myself what good are these, they’re never going to help me grow as an engineer.. Only strong technical skills matter. This, I realized, is far from true, at least at a big tech company.

Of course, your technical skills and knowledge are of paramount importance. But in order to succeed as an engineer and grow in your role, soft skills are incredibly important as well. Engineering at scale involves extensive collaboration, especially if you’re working on a team that’s building a customer facing product. You will have to attend meetings. You will have to give your inputs to your peers. You will have to talk with UX designers, with your PMs. Often times, you may have to push back on requirements coming from PMs or UX. And these conversations must be handled tactfully and with preparation. After all, you can’t simply say “No, we can’t build it in time.”. It often becomes imperative to give and receive feedback — on code, on engineering designs, on approaches to build features- to your peers as well as to engineers in other teams. This can sometimes mean taking the initiative to set and lead design review meetings.

And these soft skills become increasingly important as you rise up the ladder. Sure, as the juniormost engineer fresh out of college, you may have limited opportunities to lead projects or features and you may be working on relatively self-contained projects, but as you grow, you’re inevitably given projects which are complex and require extensive collaboration and conversations with all the three pillars of product development — Engineers, Product Managers and Designers.

Bottom line is, you may have topped all your CS classes and aced all your tech interviews, but it pays to be personable, friendly, and to have good verbal and written communication skills. These qualities are often underrated for budding software engineers but are incredibly important.

Building Software is a Team Sport

… And he best players in team sports are those who put the success of the team first. Turns out building products is not much different.

I’ve noticed that the engineers at the highest levels in all teams that I’ve worked with are also the most helpful and resourceful. They will spend hours reviewing others’ code. They will answer questions with detailed explanations. They will question designs and engineering approaches of their team members and push them to think of alternatives. And the people I’ve seen get promoted in my short time here haven’t necessarily been the ones knocking off the most story points or pushing the most code in the least time but rather the ones who contribute to the team by sharing learnings, writing documentation, answering questions, and helping other engineers in the team.

The so called “10x engineers” are the ones who not only make individual contributions but also enable the team to succeed by a) mentoring junior engineers, b) raising the level of code quality and c) enforcing good engineering practices across their teams and orgs.

A parallel can be drawn between the best managers/leaders and the best engineers. Rising in your career is not just about your individual contributions but about helping your entire team succeed.

Code Quality Is Important

In college, completing a project often meant getting it to ‘just work’. In many classes, you could have passed if you simply got all the tests to succeed, and those tests were often given to you in advance. In the real world, especially at a big company, the definition of ‘complete’ takes a whole new meaning. Handling edge cases, writing unit tests, writing clear and concise comments, testing in different environments — are just some of the things you have to do before you can say your task is completed.