Mid-Level Engineer in the Fight (1): Beginning to Become a Core Force in the Company
¶ Foreword
I had already been promoted to a mid-level engineer when I was at Mujin. Later, I joined a friend to start a company; after that venture failed, I returned to engineering. I was also fortunate enough to find a position at T2, Inc, an L4 autonomous-trucking company [1].
This series corresponds to my previous series, “New Software Engineer in Training”, and its “newcomer” (shinmai). After undergoing a period of refinement, I can now stand on my own and become a core member (chūken) of the company.
I have always believed that documenting personal experiences can help many people. The previous series aimed to help students and newcomers understand what junior engineers are like. Going forward, I will use the “Mid-Level Engineer in the Fight” series to chronicle the journey from mid-level to senior [2], and I hope it can help engineers from the junior to mid-level stages.
I have now been at T2 for eight months. As a “mid-level engineer,” I can tangibly make an impact on the company. I need to work closely with different teams; the projects I propose affect the whole company; and I also help share my team lead’s workload. The scope of my work is far beyond that of junior and early mid-level engineers. As one of the company’s core forces, leadership gives us substantial freedom and enough of a voice, because the company believes in our professional capabilities and needs to rely on us to complete the vast majority of its work. At any company, mid- and senior-level engineers are the main force.
(My colleagues and me at T2)
¶ Development speed
After several years of experience, together with AI assistance, being an independent and efficient developer has become second nature to me. For problems with clearly defined boundaries, such as “developing an autonomous-driving simulation map system that conforms to common standards” or “implementing polygon Boolean operations,” mid-level engineers can solve them very efficiently. With AI assistance, the efficiency can even reach three to five times what it was in the past.
As mid-level engineers, we can handle independent projects well. For example, not long after joining T2, I realized that we had no QA platform. Our most important tests were all operated manually by integration engineers. This was not only inefficient, but also made QA impossible to scale. I therefore spent one or two months on analysis and proposals. After receiving my boss’s approval, I spent two weeks building the MVP. Around a month later, I began promoting it for company-wide use. My boss also came to understand the importance of the QA platform to the company, so the project began receiving more resources and additional development staff.
However, when it comes to projects with broader scope, greater technical difficulty, more personnel and resources involved, and a closer connection to the company’s business—such as “developing an entirely new end-to-end simulation system”—mid-level engineers can feel overwhelmed. At that point, we still lack the ability to grasp the whole picture and coordinate many people, so we need senior engineers or even staff engineers to lead us.
¶ Revenue metrics
Junior engineers generally do not need to care much about whether what they build can make money. On one hand, the scope of their work is too small; on the other, they are primarily learning and mostly receive tasks passively. Mid-level engineers, however, need to start considering whether a task serves the company’s interests and helps its business. Places where money flows, or where money can be made, also offer more opportunities. In other words, learn to look at “revenue metrics” and get as close to “money” as possible.
After joining T2, I was assigned to a new simulation team. No one knew what the team was supposed to do, so I spent considerable time researching, interviewing people, and trying to identify viable topics. A new team at a startup has too many possible topics, and most of them are interesting. In the end, though, I chose to start with a topic that could directly make money for the company and had a low barrier to entry: a QA testing platform. The results were also significant. The new project began gaining visibility in just one or two months and received more and more resources. In contrast, another topic that I also found very interesting—a full end-to-end simulation—was not suitable to take on because it was more difficult and had no direct connection to making money (which is highly counterintuitive for a self-driving company). It faced considerable resistance and was difficult to secure resources for.
Projects that spend more money are usually more important too. Even if a project may not directly make money for the company, places with funding generally do not fare too badly. So either find a team or project where money is being spent, or find a way to make your own team or project one the company is willing to spend money on.
¶ Influence
At the junior level, you mostly build small features or small systems. You are merely an endpoint in a system, so your influence is very limited. After becoming a mid-level engineer, the projects you develop and own grow in scale. You also need to collaborate with more teams, becoming a node within a system that connects various subsystems. Once something is built, it gradually gains influence and increases the weight of each connection. When the number and weight of these connections reach a certain level, it becomes a highly important hub.
A few months after I built the QA testing platform at T2, quite a few people in the company had begun using it and bringing more requests to me. Different company systems and functions gradually integrated with my platform, and I even had the opportunity to report directly to the entire engineering division.
Influence has a compounding effect. When a few people think your product is good, word of mouth builds up and more people begin using it. Naturally, people come to you to collaborate, forming a positive cycle. When the QA platform first went online, I had to personally ask people one by one to give it a try. Now everyone uses it proactively. Whenever I enter the office, people will even come to me on their own to discuss how to expand its features. I interact with different departments every day and feel my influence growing. The process is tremendously rewarding.
¶ Learning and growth
As a startup, T2 is indeed quite chaotic, and I think that is also why I was hired at a high salary in the first place. In the short half-year since I joined, I have changed teams once and team leads twice. Together with constant changes in senior management and ongoing organizational restructuring, it can often leave people at a loss. But perhaps this is unavoidable at a startup. Every organizational change requires readjustment, and every change of team lead means rebuilding relationships. Wherever there are people, there is a social world. Understanding its rules and seeing through each person’s behavior and mindset are abilities I still lack.
At the same time, the AI era is redefining what mid- and senior-level engineers should be. People may think that AI will inevitably make them more efficient and lead to better results, but that is not necessarily true. AI is only a tool. While AI speeds up problem solving, the truly difficult part is finding problems—especially valuable problems. The ability to make forward-looking judgments remains important in the AI era. AI also cannot replace the true core value of people: evaluating project value and the company’s interests, building connections between people, understanding customer needs, and so on. These are still abilities that must be accumulated slowly, step by step.
I recommend reading @philhchen’s “Career advice in the age of AI ”
Whether we stay at startups or live in an era of dramatic AI-driven change, we need to keep learning, growing, and looking for opportunities. At work, I work seriously and observe new opportunities; after work, I write open-source software to sharpen my AI development skills. The more educated I become and the older I get, the humbler I become, and the more I feel how small I am. In the current of the times, all I can do is keep improving and hope that one day I can truly become an outstanding person.
For the specific process of finding this job, see my earlier article, “My Experience Job Hunting as a Mid-Level Software Engineer in Japan and Taiwan in Fall 2025.” ↩︎
Because job levels differ from company to company, “mid-level” here is equivalent to Google’s L4, while “senior” is equivalent to Google’s L5. Therefore, mid-level engineers broadly refer to engineers at the L4 to L5 level. ↩︎