Profile picture

Mid-level Engineer Career Development Videos, Forum, and Q&A

How A Mid-level Engineer Can Grow Their Career

Mid-level engineers have very strong technical proficiency, able to execute on small to medium-sized projects with minimal hand-holding, leveling up from junior engineers.

Mid-Level Software Engineer at Taro Community profile pic
Mid-Level Software Engineer at Taro CommunityPosted January 31, 2025

How can I gather ALL requirements upfront at project launch?

Problem: Whenever I have a project intro sync with a senior engineer/product manager (Subject matter expert) to gather requirements of a project (say a backend API) - I ask SOME questions and leave the meeting, at the time, feeling satisfied with my understanding of what I need to do and THINK it is clear of what to do. (I usually do not ask clarifications on what I believe are "small details", and leave it to myself to figure out the "small details"). I incorrectly think that asking many questions about "small details" makes me look like an inexperienced/ unreliable engineer. However-down the line during project implementation, a few weeks later, I realize there are a many ambiguous/unclear details that I need to re-ask the subject matter expert. This happens again, and again sometimes - as a few weeks later, I ask MORE questions - that sometimes make me rewrite a lot of my code, and has me chasing my tail/ making me look like an unreliable/slow engineer. When someone asks me "Am I making sense? Is this clear to you?" - I ALWAYS say yes too early, without thinking about edge cases/ unmentioned ambiguous details. (I incorrectly think that saying something is clear to me quickly, makes me seem like a sharp/fast-learning engineer. TLDR: How can I gather ALL requirements upfront at a project launch efficiently? How do I ensure I am 100% clear what/how to implement a project software-wise? (Especially since I have a horribly persistent bad habit of incorrectly saying details are clear to me, almost in a "happy-go lucky" fashion, wanting to seem like a easy-going engineer, that can pick ambiguous problems up quickly, without much explanation) THANK YOU! This has plagued me for my whole career.

37 Views
2 Comments
Mid-Level Software Engineer at Taro Community profile pic
Mid-Level Software Engineer at Taro CommunityPosted May 1, 2025

How to Discuss Edge Cases, Alternate Solutions, and The Approach in DSA Interviews?

I just finished the Master DSA Interview Course—fantastic material, thank you! I have three questions: In many problems, if we recognize the right pattern early, our initial code already handles most edge cases. So when a “Strong Yes” solution includes identifying 8+ edge cases, is the goal mainly to communicate to the interviewer that we’ve considered those scenarios (and confirm our code handles them), rather than necessarily rewriting the code to cover each one? Sometimes, a non–strictly worse alternate solution may not exist for a given problem. In those cases, are we expected to justify why no such alternate solution is possible? Or is it uncommon for interviewers to press on that point? I recall doing these types of proofs in university DSA courses, but I’m curious how often that level of justification is actually part of an interview setting. Alex emphasizes the importance of discussing your approach before jumping into code. How detailed should that discussion be? I sometimes find it difficult to clearly articulate a strategy when I haven’t seen the problem before. I might recognize patterns and have a general sense of how to attack it, but summarizing that strategy clearly—while still working through it mentally and continuing to talk—can be challenging. Any advice on how to strike the right balance between clarity and real-time problem solving?

34 Views
3 Comments
Mid-Level Data Engineer at Taro Community profile pic
Mid-Level Data Engineer at Taro CommunityPosted September 2, 2024

Caused a SEV - Publish RCA?

In my 3rd week at Big Tech, I was over-eager to get my first PR merged (into a particular legacy Airflow repo) so I could complete my first ticket and show some progress. I made probably the most classic rookie-mistake of not properly testing my code in staging, and my code ended up causing a sev that took down Prod for about 30 minutes. Since this was a particular legacy Airflow repo, it wasn't the end of the world since only internal workers were affected, only a small subset of the company, and it happened at night. Still, this was a pretty bad look for me to my manager and I've been working hard since to make a better impression. At my company, for every sev, there's a process to write up a Root Cause Analysis (RCA) Doc where you describe the issue, 5-whys for why it happened, the timeline for how it happened, who it affected, and a few other details. There's technically an SLA of 2 weeks set to each RCA, but looking at other RCA docs, I see a lot of them were never actually filled out. From my perspective, the reason for the sev was simple: I didn't adequately test in staging. The oncall guy who helped me navigate the issue encouraged me to not personalize it as much and to think in terms of the process, e.g. testing in staging should have been required or canary testing in prod should have caught and rolled back my code. I have filled out the RCA doc on Confluence and can publish it but am hesitant to do so because I'm concerned about reminding people that I caused the sev. I have 2 concrete questions: Should I publish the RCA? I can prob get away without doing it since it doesn't look like it's enforced. I guess if someone does decide to follow up and sees I haven't filled it out it could be a bad look, but given that it's been over a month since I was supposed to publish it, it doesn't seem likely. If I should publish, should I look to engage with my oncall mentor regarding implementing some of his feedback for making testing in staging required or canary rollbacks? It seems like a lot of work to do (for myself or others) for something that was a "me-error" and people might get annoyed if they now have to test everything in staging when they don't currently have to. It also takes me away from my current tickets (which my manager prob cares more about me completing). Thank you for reading this!

34 Views
2 Comments

Learn About Mid-level Engineer

A mid-level software engineer has all of the foundational technical skills, industry knowledge, and practical experience that allows them to contribute to software projects. They can collaborate with cross-functional teams, handle complex tasks, and demonstrate a deep understanding of the technologies they work with.
A mid-level software engineer can demonstrate a certain level of technical proficiency and independence. They should be able to handle most bugs without needing constant guidance. They should also be able to independently implement features with medium complexity. It is the level where one becomes less reactive and more proactive. Proactivity means anticipating where bugs may show up as well as suggesting improvements in the codebase. They should have a high standard of code quality and high velocity of code velocity.
The journey from a junior to a mid-level engineer is a significant step in one’s career. It’s important to focus on developing the skills necessary for the next level. This shift involves being able to write code to being able to write better code faster. One should be able to understand systems, plan out projects, meet deadlines, and occasionally function as a lead to make the transition. They should also be improving their communication skills during this period and seek feedback on their work from more experienced software engineers.
The transition from a mid-level engineer to a senior engineer involves a deeper mastery of technical skills, leadership capabilities, and a complete understanding of the software development lifecycle. Senior engineers are responsible for making high-level architectural decisions, guide the technical direction of a project, and mentor junior and mid-level team members. Collaborate with your manager to develop a formal growth plan. Take the initiative to write the document yourself and discuss it with your manager. One should be able to recognize gaps that a mid-level engineer has so they can improve them: writing more code rather than reviewing code, not being available to help out during big incidents, or only dealing with one’s own code. By focusing on these issues, you will be able to exert your influence more broadly across your team and company. You should also consider mentoring some of the more junior members on your team to help them grow and develop their skills.
The journey from a junior engineer to a mid-level engineer or a mid-level engineer to a senior engineer involves a continuous process of learning and refining one’s technical, communication, and leadership abilities. One should strive to have more and more impact and influence across their company to have a successful career progression.
Show more