0

How to become a senior engineer at early stage startup by finding problems to fix?

Profile picture
Anonymous User at Taro Community2 years ago

I am a junior engineer at a series A startup. I was interning for the past 8 months and got converted full time, now working as full time junior engineer for the past 3 months. I had been getting "Exceeds Expectation" from my tech lead/manager.

But from the past 3 1:1s from the tech lead. He mentioned that

1. My code is not up to the mark to directly merge without taking a much deeper look into. Basically mentioning that my code is not levelling as a senior engineer. There are no senior engineers in my team, I directly report to tech lead. So I really cannot learn how to write better code as he mentioned. Where can I learn this?

2. I have been just crunching tasks or helping someone without understanding the root cause. He mentioned I lack "Product Thinking". I am really not sure what he means by this. I thought helping others would help me grow in my career. By helping others I mean if there is a small task that is required by some other team, I just go and do it without understanding entirely what they want.

3. The founders keep mentioning that there is a lot of growth potential in our company

I really work hard every day from 8 AM and late 11 till night but the work I do is not helping me to grow and I want to grow and become a senior engineer. There are not even tests in our codebase, and a lot of problems I see in the way we do things which I don't know I can help solve . How can i grow? how can I tell them that I can be that senior engineer to solve the problems? How can I learn to make good decisions as to what needs to be prioritised in terms of which task needs to be done? If I don't know let's say how to write tests, how can I learn that and cultivate that in the team?

126
1

Discussion

(1 comment)
  • 2
    Profile picture
    Meta, Pinterest, Kosei
    2 years ago

    I'll start by just addressing point #1:

    My code is not up to the mark to directly merge without taking a much deeper look into.

    Two thoughts:

    • You mention you don't have senior engineers on the team aside from the tech lead -- can you just look at their code reviews and their code quality? Or how about looking at senior engineers on other teams?
    • When you look back at when your code is reviewed, can you categorize the types of feedback you're getting? Are you noticing patterns? This is a really powerful way to learn.