Once they have received their offer from a big tech company and see the actually salary, many software engineers start to worry.
Will I be able to life-up to their expectations, deliver results and be successful? Am I even smart enough to achieve any of this?
Don't worry - you are! If you made it through the technical interviews, you can be sure. I’ve also seen much more people not become successful due to bad habits than due to not being smart enough.
That’s why I share 4 habits which help you grow as an engineer and accelerate your career in any FAANG company.
1. Understand what problem you’re solving
This is the very first thing you should become good at. As you won't be able to deliver any meaningful contribution without understanding the actual problem.
You need to understand how will this thing you’re creating be used; it is almost always a part of a bigger whole.
Ask these questions before you write a single line of code
- What are we trying to achieve here?
- What is the user of the system (e.g. the owner of the service that will call you, the end customer) trying to achieve.
This is important, because it allows you to make a judgement call which technical problems are real problems, and which are irrelevant.
- Is a risk of worse performance a problem?
- Do you have to have bug-for-bug backwards compatibility?
- How robust do you have to be in case of a dependency going down?
- Is it OK if you lose some small percentage of the traffic?
You shouldn’t ever guess at these things, these should follow from the reasons that you’re building whatever you’re building.
2. Focus, Focus, Focus
Once you have understood the problem, you start implementing. A successful implementation is a completed one. The key is focus here, and this means to resist a lot of temptations and don't...
- Use all the shiny technologies around you
- Polish the code to infinity
- Try to fix all issues in the world at once
- Try to reinvent a different, much smarter solution to the problem if you’re not really sure it makes sense
Make it your most important goal to get stuff done.
3. Communicate clearly
Within a few weeks you spend on a new task, you become the local expert on the underlying problem.
Most frontend dependencies are not up to date and some have massive security vulnerabilities?
→ You are going to be the person discovering it.
The recently introduced backend architecture will have performance repercussions unless you make major changes to it?
→ You’ll notice that.
It’s your job to communicate these problems clearly to the folks above you. That means two things:
First, you need to communicate at all. If there’s a problem that will cause you to deliver slower, your manager and tech lead need to know. They need to know, because what you are building is a part of a larger whole, and so they might need to adjust some other work. But also, they need to know because they’ve seen a lot of stuff, and might have ideas how to solve the problem. And for that to happen, they need to know and understand the problem.
Second, you need to communicate clearly, extracting the critical parts. This, I find, is the crucial growth skill at large companies - the people who grow are the ones who can take a deep technical issue, and isolate the parts of it that are important for a more experienced person to reason about it; without requiring them to listen to a two-hour lecture.
So, when you encounter an unexpected problem, spend some time (a few hours? a few days?) trying to understand it, and communicate upwards.
I’ve spent a few hours trying to figure out how to do it; and so far no luck. Any ideas? How long should I dig before abandoning this effort?”
-
That includes being up-front about:
- when you think you made a mistake;
- when you’re having issues convincing some other team of something;
- when you’re unable to solve some problem.
Sure, it would be better if you were able to solve everything perfectly - but it’s muuuuch better to admit the mistake or issue than to try and hide it in a (almost always unsuccessful) attempt to look better.
4. Don’t create problems
Your manager, and your tech lead's goal is to make sure the team gets stuff done. When you have a strong opinion about something they want you to do, something like,
No, I won’t work on this system, because it’s in Java, and I think Java is evil
then you’re creating a problem that didn’t exist, and that they need to solve.
You opinion is valueable to them for sure, as you are much deeper in the weeds but you should always explain your concerns and provide context.
Hey, so I think that I’ll be less effective on this, because it’s in Java, and I don’t really know Java that well.
Now, you’re communicating clearly and you give all the context needed to understand the reasoning behind your statement.
This allows them to reconsider their decision and let someone else work on the java tasks. Or they on their end provide a little more context on their side and come up with a solution that is better catered towards your personal needs.
Something along the lines like -
“OK, I get it, and I expect to be less proficient - but we’ve got a lot of Java work coming up, and I think it’s more effective if you get up to speed - would you prefer to just dig in, or do you need some up-front time to do codelabs and stuff?”.
Thanks for reading this article! Leave a comment below if you have any questions.
Recently I have become a senior software engineer at Microsoft, prior I have worked at a mid-sized startup in Berlin, Germany. From experience I know, how intimidating big tech can look from a distance. To help other engineers to make the leap into a FAANG company, I demystify the coding interview on multiple platforms.
You can connect with me on LinkedIn, Twitter, or by visiting my youtube channel.
Top comments (0)