What makes a Mid-Level Engineer

It seems like eons have passed since I was in bootcamp at Flatiron School, bumbling my way through my command line project and hanging on for dear life in my career pivot. Perhaps it’s the pandemic’s ability to distort time, or maybe my ascension into a brilliant role at a dream company is what distances me mentally from my humble beginnings.

Either way, I write this to you from the perspective of a real live Tech Lead. Gone are the days of begging for junior dev roles, of pretending to care about my side projects or banging my head against the wall as I navigate the tricky world of Leetcode.

I’m in my second job as a software engineer now, at a startup called Health Note. I was fortunate enough to find a fantastic first job as a developer for Regions Bank shortly after graduating from Flatiron. I worked on a small team (three people, one other developer) where after a quick introductory period of learning the codebase, I was tasked with building a sprawling project management and time-tracking app that all of our HR Ops department would use going forward. I got to get my hands digitally dirty while learning under a seasoned dev who had been there before, many times. I couldn’t have asked for a better first job. I got to use my React/Rails skills immediately at a job where I was doing what I did in school, only on a scale previously unimaginable.

Still, there wasn’t much room for growth. It was my first engineering job, sure, but I’d been a professional for over nearly two decades before pivoting to software, and I knew I’d be able to rise through the ranks and become a leader in the industry were I given a chance.

I started lurking around the jobs boards and networking around nine months into my job at Regions. I was a bit shocked to learn what the going rate was for an engineer with experience, and comparing it to what I was earning at Regions, I saw the disconnect. I figured a few interviews and an eventual offer may give me the leverage I would need to negotiate myself into a leadership role at Regions (and obviously, a better compensation package).

The interview process was rough. I had a target position and comp package, and a job already — that made things easier for me. But that point of view has its drawbacks too. When you don’t have a job and are looking, you can devote full-time to finding a new one. When you are employed, you have less time, and less hunger because you’re not under the cosh.

To my surprise, I was inundated with interview requests right off the bat. Triplebyte streamlined the job search: I passed a few quizzes with really high scores, which, when combined with my limited experience as a dev and extensive experience as an award-winning editor equated to a desirable candidate.

My first interview was an utter failure. But I learn the most from failure. From then on, I became an expert at selling myself. I’d make it to the final round for a position and hold my ground when companies tried to low-ball me. This happened a number of times, and eventually it paid off.

I was in New Orleans with my partner when I made it to the final round of interviews for Health Note. I got an offer the same day as the house we rented was sold from underneath us.

New job and having to move houses — It was a dizzying week, but I landed at a job where I felt connected to the business and the company’s mission. Moreover, I felt wanted. Health Note made it clear early that they wanted me and what I bring to the table.

Now, if I’m going to title this blog post ‘What Makes a Mid-Level Engineer’ I should probably speak a bit more about engineering. In my role at Regions, I got to build an app from the ground up. That’s one skill I sharpened a great deal at bootcamp. We built a lot of apps ourselves. It came in handy at Regions.

At Health Note, the job is more grey area. I’m working in someone else’s codebase. There are less-clearly defined responsibilities. What makes me mid-level as opposed to a junior, in my opinion, is my capacity to not be terrified by that fact. This app is in Mithril.js, a JavaScript framework I’ve never heard of? No problem, I’ll get started on learning it.

As a junior dev, it took me forever to learn things because I was terrified of breaking something. At this point in my career, I relish breaking things, finding an app’s weak points, exploiting it, then building something better around it. That comes with confidence, which comes with experience.

Something I picked up in my few years developing is how important it is to truly know your app. That context is something most devs are cut off from, as big tech firms have entire departments dedicated to QA alone. Despite the obvious flaw as a best practice, I often had to QA my own app at Regions, forcing me to think like a user instead of as an engineer. This context translated into becoming more well-rounded — able to think about the entire business.

Now, I am the technical lead of our Onboarding Configurator, a Mithril app that plays a massive role in getting clients started in Health Note. It took me a long time of simply reading the code someone else wrote (and becoming good friends with the author) before I was able to truly make an impact. But, I found a way to become valuable. The person who designed the app is a brilliant engineer in Argentina. Pablo, who has wishes of coming to America at some point to visit, and I made friends quickly. We connected over travel while discussing the finer points of the app he built. I offered to give him English speaking lessons in exchange for a bit of his time each week whenever I’d approach a blocker to my feature or bug-fix. About a month ago, the training wheels came off as I no longer needed his guidance to perform my tasks. Just a few weeks of digging in, asking questions and learning the app was all I needed to take control of such a crucial tool in our company. As a junior dev, I’d have lacked the confidence to dive in and take ownership in such an abstract role. Now, it’s part of what makes me valuable.

I’m the go-to person for this app as well as a number of other projects across the business. I’m not limited to ticket-taking alone as a developer (not that there’s anything inherently wrong with that). I’ve leveraged my communication skills to lead meetings, my writing skills to overhaul documentation, my people skills to connect departments.

I’d have bombed this job if I had been hired right out of bootcamp. Now, I thrive between the lines and in the grey areas. That’s what separates juniors from the rest — the training wheels of a clearly-defined set of objectives. That’s why juniors need hands-on experience — it’s the only way to build the confidence it takes to be able to navigate an environment where everything isn’t spelled out for you.