How to be a Successful Junior Engineer

Hanah providing guidance at a workshop

I came to software engineering through a nontraditional background, and as a result, I entered the engineering world trepidatiously with a great fear of failing. As I gained experience in my first few engineering roles, I realized that being successful had to do with providing myself the right tools.

In this blog post, I outline some of the things that helped me get to where I am today: an accomplished software engineer that feels confident about the value I provide to my team and my company.

A little bit about myself

Hi! I’m Hanah, a full-stack engineer at Eventbrite. I work on the Incubation team, building new products for our event creators and attendees. I was not always an engineer –I studied economics and history in college, wrote a thesis on pirates (yes, YARRR pirates), worked in food education at Stanford, and then attended a coding bootcamp in 2016. Since graduating, I’ve held two engineer positions, and I wanted to share some of the things that have helped me become a successful junior engineer. I also now teach and mentor engineers from diverse backgrounds in my spare time. I do want to make a mention that this post can be applied to all types of junior engineers –self-taught, out of college, from a bootcamp, etc.

What is a successful junior engineer?

I think the important thing is first to define what success means. Sometimes, in the engineering world, we get caught up in quantifiable things –like how many lines of code you wrote or how many stories you closed. That’s only one indicator: YOUR terms should define success. Success to me is defined by two questions:

  1. Have I learned things?
  2. Am I able to contribute in a meaningful way?

I feel lucky to have ended up in a field where gaining knowledge is the predicate to success. I get to study as part of my job, and then constantly apply what I learn. Sometimes seeing an uptick in the number of stories I close can tell me if I am providing meaning. However, a lot of it has to do with measuring myself against the challenges I’ve faced.

For example, a year ago, when I joined Eventbrite I thought I knew React.js but quickly realized that I didn’t have good React practices. I spent a lot of time working with a senior engineer and reading articles to improve my skills. Now, a year later, I am the sole frontend engineer on my team, teaching React.js to two senior backend engineers (which is a lot of fun, gotta say).

Ask questions

Asking questions is the number one thing. Of course, when you face something you don’t know, you do your due diligence –Google search, read docs, check a book, etc. If you get stuck, give yourself max an hour and then find someone to ask. Even as a junior engineer, your time is better spent learning something than searching for the answer.

I’ve felt that sometimes there is an invisible cultural barrier to asking questions –there is a perception that questions place burdens on others. As much as possible, I want to dispel that. Asking questions displays a desire to learn, a search for answers, and curiosity. All of those things should be rewarded and encouraged.

Ask them to simplify it

It can be tough to get a subject matter expert (aka an engineer more senior than you) to explain things on a level that you can understand –especially when they have very intimate and in-depth knowledge of a system or complex subject. This is where asking questions becomes essential. You can use questions to help guide them to the answer you are searching for.

Get a mentor

Sometimes as a junior engineer, you don’t know what questions to ask or where to start. I remember when I was first teaching myself how to code by building static websites. I was googling things like “what happens when you hit submit on a form?”, and I wasn’t getting the answers I needed. Now I know that I should be looking for concepts like “event handling” and “form selectors”. But that’s because I found several mentors who were able to guide me in the right direction.
To this day, I still seek out mentors because having someone push me and guide me is invaluable. One tool that I found helpful when working with a mentor was to make use of a mentorship agreement, such as this one.

Set manageable goals

Lots of junior engineers end up placing too high expectations on themselves. As a junior engineer, you don’t know how long solving a problem will take –that type of understanding comes from having looked at many of the same types of problems before. This is where working with a mentor or your manager to set reasonable goals is crucial. They can help set solid scaffolding towards your goals, whether it be pushing out the next feature set or achieving the next promotion.

Study on your own time

As a bootcamp grad, I realized I had a lot of ground to make up because I didn’t have a traditional CS background. I was given React tasks at my first job, and I realized that if I want to add value quickly, I would need to ramp up. I took both work time and after-work time to learn React through an online educational tool. Moreover, that habit of studying still sticks with me today. My current mentor assigned several computer science books that I have been slowly getting through, and have been able to apply to my daily work to improve my code quality.

Read a LOT of code

I remember hearing from my bootcamp teachers that I should be reading something like 10,000 lines of code a week. Now, that’s a little insane but it gets the point across –to write great code, you need to see what both the bad, the good, and the ugly look like. An excellent way to do that is to read code reviews; that way, you can see what’s being actively maintained and improved. It also means you can ask questions in context and observe what other engineers are calling out.

Step it up

Take responsibility for something that seems slightly out of your reach. One of my previous managers at Eventbrite told me that he wants me to be sitting just on the edge fear because that’s where intense learning happens. I have a huge fear of failing, but taking responsibility means pushing yourself and growing as an engineer.

Bring something else to the table

Coding isn’t the only skill required in software engineering companies, and it’s not the only thing you should be good at. For example, good communication is also as important, if not more important, than writing code. I remember hearing somewhere that your code is only as good as your ability to work with people. Yes, there is the stereotype of the engineer holed up alone in a dark corner banging out piles of code, but that’s not how great engineering works at a corporate level. I’ve seen the result of single-person outputting piles of code at night. It’s not pretty –not easy to read, not easy to maintain. Code should be a collaborative effort.

One of the things I bring to the table from my previous jobs is the ability to communicate effectively and provide clarity. I also bring my non-engineer programmatic experience (i.e. creating long-term organizational programs). I led the effort to restart the internal mentorship program at Eventbrite, which now has 20% participation.

Imposter syndrome is real, and that’s okay

Imposter syndrome is defined as a belief “in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a ‘fraud’” (Wikipedia). As a junior engineer, this is something I felt every day for the first 6 months of my first job –I was continually asking myself, do I even belong there? This fear was amplified when I found myself in meetings with lots of very senior engineers.

I think what helped me get over imposter syndrome was realizing that I have the capability to learn and grow. Also what helped was learning to celebrate my successes, however small. I find myself often looking ahead, thinking about how much I still have yet to learn and worrying if I will ever ‘catch up’ or ‘know enough’. But, if I look back, I can see how far I’ve come. It’s critical to take a moment to be like “yeah, what I did is awesome”.

Success takes more than just you

I realize that most of the preceding advice places onus on you, as the junior engineer, to make it happen. A lot of the time, success is predicated not just by your actions but also by the environment around you. I have heard stories of junior engineers at companies where, because of the way things were set up, there was no opportunity to be successful. Either the teams were unfriendly or unhelpful, or unrealistic expectations were placed on the junior engineers.

Being a successful junior engineer requires a good culture, a good team, and the right expectations of what can be accomplished. If you find yourself in an environment where you reasonably feel like your success can’t happen, raise your voice –be the change you want to see. As a last resort, get out of that environment and find a better one. I am grateful that the environment at Eventbrite is exceptionally supportive, especially towards education and junior engineers.

Putting it all together

Being a junior engineer is challenging in part because of the stereotypes that come surrounding engineering –that to be a successful engineer, you need to be a ‘rockstar’ or a ‘wizard’. But no one starts out as the best, most amazing engineer ever. Success isn’t and shouldn’t be determined by being the best in your field –success is being your best, given your level of expertise and knowledge base.

In this post I talked about some tips, tricks and habits you can adopt so you can excel in your job and have a great career. There are things like suggested studying habits, or not being afraid to ask for help, or realizing what, in addition to engineering, you can bring to the table. Figure out what works for you –that’s honestly always the best method to being successful.

What are your experiences as a junior engineer? What did you do to help junior engineers? Leave us some comments below or say hello on LinkedIn.

Leave a Reply

Your email address will not be published. Required fields are marked *