Disclaimer: This article is reflective of my opinion alone, and other higher level engineers may feel completely differently, and that’s okay. Additionally, much of this content is written from the perspective of someone who’s been in a large corporate setting for a good chunk of his career.

I’ve mentored and led somewhere around 50 junior & intern-level engineers (sorry I don’t remember all of your names). It’s not the most veteran number you’ll see around the professional world, but it’s enough for me as a Senior Engineer to have established what impresses me.

My main goal is to encourage fresh engineers who are young in their career and perhaps not the most confident in their skills, but this content would likely apply to many other professions. So let’s set the scene…

---

You’ve just been hired at one of your target companies, an opportunity you’ve been excited for since at least the last few months of your senior year. If you’re somewhere more modern, it’s likely your new team will proceed to stuff a hefty amount of documentation down your throat, the company will demand you finish your trainings immediately, and suddenly getting that real-world coding experience you’ve been longing for seems further away than before you started.

But not to worry; eventually your name will make its way to that slow-loading Agile dashboard and your first task will finally be assigned, pointed, and ready for development. And so your coding career begins in earnest — but what is your best path to true growth as an engineer?

Start Asking Questions

This might seem like a no-brainer, but the reality is that many, maybe even most, junior level engineers are too intimidated or lack the confidence to ask questions; this heavily depends on the personality involved, but at least in my experience this is generally true, even in an environment in which questions are encouraged. Everyone’s heard of the phrase “there are no stupid questions”, but in practice this is difficult advice for everyone to follow.

Unfortunately, this is also the number one way to display your level of engagement, curiosity, and ambition to the team around you. What differentiates an excellent engineer from an average one is not necessarily their dexterity of thought or how cleverly they’ll solve solutions (although this obviously plays a role too) but how well they understand what they are building. This criteria includes knowledge about both the technical side of an application/project (e.g. the framework(s) being used and why, the architecture design, tech debts, etc.) as well as the business side of things. Business in this context means an understanding of things like why features deliver what value they do; what value your assigned ticket is intended to provide; who is asking for it (other than your product owner); and so on.

There’s a ton of articles out there about how to collect all the required information about a story prior to starting development, so I won’t go into great detail about it here. If you’re interested in my personal perspective on the topic, let me know below and I can look into writing about it in the future.

Differentiate Yourself by Speaking Up

A good junior engineer delivers their assigned stories within a reasonable span of time, and moves to the next ticket. An excellent junior engineer should make up for their expected lack of experience and knowledge with an unparalleled hunger to learn and a fresh perspective. They speak up when baffled, they challenge when dissenting, and they influence through their attitude. With this mindset, they’re sure to succeed in virtually any role and see career movement in double-time.

The primary goal here is to speak up voluntarily in meetings and architectural/design discussions. A frequent failing of the average junior engineer is, as mentioned above, is giving in to that feeling of intimidation. Unfortunately, I can’t accurately estimate how many times I’ve personally raised discussion topics with my teams and asked for input from anyone, only to hear crickets, but when I’ll call someone out specifically, their ideas are shockingly insightful! I can only think, why didn’t you speak up before? Why force me to go around the table calling out names? What if you hadn’t spoken up and our team would have lost that value?

A often-cited less pleasant experience is if someone says something less insightful, or even a comment that reveals their ignorance of the matter at hand. The reality is that this is an excellent and, personally, very much appreciated, opportunity to clarify and correct (if needed) the erroneous or thought. More often than you’d think, this same thought will live in several other members of the team who were simply too timid to say the exact same thing. By having just one person speak up, their thoughts could be the key to answering several folks’ questions in one simple response.

Hunt People Down

A more straightforward path to professional growth to learn how to hunt people down. More literally, this means ensuring that your messages, emails, and questions placed on hold eventually receive a response. While this challenge is definitely present across virtually any role and experience level, junior workers in particular are susceptible to feeling ignored or stranded not necessarily because their colleagues are flaky or especially unresponsive (although this can also be a problem occasionally) but because they may not be familiar with the follow-up process.

It’s vital to understand that while folks may not immediately get a chance to answer your messages, or even have an answer handy, that doesn’t mean they’re purposefully ignoring you. Oftentimes people, especially senior level employees, are stuck in meetings for long periods of time and simply forget about your note. It’s not completely excusable to be unresponsive on many occasions, but ultimately these things happen and you’ll have to account for it.

The means of combating this is actually very straightforward: Just try again. Give them a couple of hours, maybe even a day depending on the urgency of your message and what you can do in the interim until it’s answered, but always attempt to follow up. This can be as simple as telling them you want to follow up on the previous message — nothing fancy is required here.

In rare instances, this approach simply doesn’t work for a variety of reasons. In these circumstances, your best bet is to consult your leader and/or someone who works with your target to gently escalate the issue. Escalate might seem like an extreme measure here, given the nature of the word’s meaning. To some extent, this is true — no one wants to get messaged by a director effectively slapping their wrist — but it’s also necessary and ultimately beneficial to everyone. You get your answer and the respect you deserve, and they learn a lesson about responsiveness.

Understanding the Business Needs

To most engineering folks, the business side of things tends to be the least interesting part of the job. Unfortunately, that doesn’t mean it’s not important! When you take on and develop a given task, story, feature, or even sometimes bugfix, you do yourself and your team a disservice if you don’t try to assess the overall value and reason for your delivery. This means that prior to taking on the work assigned, the correct, appropriate, and impressive approach is to grill the hell out of whoever you can about the ticket until you’re confident there’s no more unknowns, at least initially.

This approach is obviously easier said than done. When you’re new to the team, and in many cases new to some of the tech stack, it’s definitely overwhelming. That said, asking these questions is how you learn; on top of benefiting your team with more questioning of the system, you benefit yourself by going through the standard discovery & refinement process. I’ve worked with many folks who generally knew how to deliver a story but they would show just about zero initiative otherwise. They never contributed to bettering the application through their own ideas, and for years simply stagnated in every sense of the word.

Beyond self-improvement, the ability to fully understand the impact of your work and others (as we’ll discuss below) enables you to grow directly as an engineer and as a pseudo-product owner through one of the most notorious aspects of development: edge case handling. One of the great banes to a robust, comprehensive system is missing edge cases during the planning stages of a feature. These scenarios often result in disasters ranging anywhere from minor to catastrophic failure. It is for this exact reason that learning the business end of things is so absolutely vital and why asking the questions mentioned above is such a subtle but core part of development. The engineer capable of planning for these things is the one responsible for a smooth end to end flow.

Finally, understanding an application’s roadmap is essential to planning your code design. A basic example of this is determining whether or not something needs to be reusable; sometimes it’s not worth the effort to break a module down so much to enable reusability when there is no foreseeable usecase for re-use. With a general understanding of the vision for your project, you can make much more educated decisions about your implementation strategy and what level of effort is worth sinking into a given design pattern.

Building Relationships

Many of our best friendships will form during our college years (or in just long-term classroom settings), due to the sheer amount of forced exposure, collaboration, and shared experiences we undergo with our peers. Professionally, this kind of relationship is fundamentally very different; exposure is definitely much more varied, collaboration is often dramatically different than in a classroom setting, and a single average team will typically see a huge range of experiences.

The college-esque friendship/relationship is nonetheless an important model to strive for in a workplace. Will you get along with all of your peers? Unlikely — and yet you’ll have to work with them anyway. The main goals are understanding and teaching. If you understand your colleagues, collaborating on various features becomes that much easier; all of you can account for each other’s strengths, weaknesses, interests, and general knowledge when scoping work and delivering tickets.

In conjunction with understanding, you’ll always have the opportunity to teach as well. Even in a junior setting, it’s likely you’ll have some new technology or engineering design you can share or discuss with other junior, mid-level, and senior engineers. This act of mentorship and knowledge-sharing brings yourself and the team closer together, and reinforces the concepts discussed above.

To achieve these goals, the process is actually very straightforward. Schedule one-on-ones with your fellow junior engineers frequently. Make a point to meet with your senior engineer(s) and leaders for consistent feedback — and note, many seniors are often bogged down by meetings, so you must chase them down.

Lastly, but just as important, schedule one-on-ones with your business contacts as well! These folks will often operate under the title of Product Owner, Product Manager, Analyst, etc. but the title itself will definitely vary from company to company. Ultimately this should be the person who generally filters down the requirements of a given project to your team and works alongside you to get it done in the expected way. A healthy relationship with such colleagues is absolutely vital to ensuring your engagement in the company and your project is maximized and fulfilling.

A note on working virtually

In today’s day and age, virtual work is common and consequently some of these social goals are naturally more difficult to achieve. The best you can do is to make use platforms like Webex, Zoom, and so on (with video enabled) to schedule your coffee chats, one on ones, etc.. Additionally, simple events like Friday social lunches and playing online party games go a long way to building comradery. There is a wealth of content on this subject out there; it’s up to you to choose what works for you and for your colleagues.

---

A Timeline of Growth

It’s unreasonable to expect a junior engineer to instantly apply all of these practices immediately, but it’s absolutely justifiable to assume her or she will begin a gradual implementation into their workflow to get familiar. To maybe set some more clearly defined expectations, I’ve drafted a general timeline of how an ambitious engineer, fresh out of college, bootcamp, or even internships, can attempt to follow. I don’t view the following timeline as hardcoded dates, so to speak, but it’s a general list of goals that can be relatively easy to meet with enough effort.

Month 1 – 1.5

During this period of time you should expect to become a literal sponge, doing nothing more than absorbing as much information as possible about your team, your project, and your company. Onboarding, depending on the company, will often take a good chunk of time as well. You should be asking as many questions as you can think of and, depending on some of your colleagues’ personalities, bothering them as much as you need. In parallel, you’ll want to exhibit some independence in attempting to research topics not company-specific e.g. if the project uses Spring, read the documentation before asking someone about a given annotation.

One of the most important accomplishments you should aim for is to attain a decent level of understanding of the company tools available to you for information-finding. Popular tools such as Confluence for documentation, or even leveraging the Slack/Teams search capabilities to look up your queries enables you to skip the potential pain of waiting on someone for an answer, and directly cultivates your independent experience.

Month 1.5 – 4

You’re now taking on your assigned tickets as you receive them. Prior to beginning work, you should be meeting with your team, your senior engineer, or your product owner to ask some basic questions about the ticket. What is the exact requirement? What part of the system will this impact? How do I ensure all test cases are covered? The more of these questions you ask, the more fleshed out your story will be in your head. You’ll rapidly gain the experience and the confidence to make this a habit.

You can begin scheduling some one-on-ones with your colleagues (as mentioned above) to start building those vital relationships and becoming a valuable part of the team.

Month 4 – 8

You should be beginning to understand some of the more minute details of your application and why the main features exist & what they offer to your end consumer. You’re able to contribute somewhat to design discussions (even if it’s just helpful questioning) and offer insight during debugging sessions or answer some simpler questions from team mates. Your delivery is speeding up as you continue to familiarize yourself with the tech stack and refactoring opportunities slowly become more apparent to you — existing code is no longer just a given but something to potentially be optimized in the future, where possible.

Your relationships with most of your colleagues are at the very least functional and is directly enabling a greater level of collaboration.

Month 8+

After this point, the expectation is that you are now a fully functional engineer that is ultimately still learning. Your delivery speed is on par with your similar-level peers. Your understanding of what the application’s goals are, and what its roadmap looks like for at least a good chunk of the future, is perhaps a little spotty on some details but generally pretty solid. You are a vocal part of meetings and actively contribute in innovative, if not completely viable, ways to architectural or design discussions and your input is generally respected/valued. From this point on, the main path to growth is traversed simply by doing what you’ve already been doing. Keep it up and get that juicy experience!

You should be fairly good friends with some of your fellow engineers, assuming the personalities are good fits. Your senior engineer(s) typically have you in mind for interesting work, especially side-projects if bandwidth allows, and are generally impressed by your level of engagement. Your business partner(s) are similarly thrilled by your ongoing interest in both them on a social and professional level and will often want to include you on discussions relating to feature planning, strategy solutioning, and so on.

Do you agree or disagree with any of my assumptions, judgments, or content? I would love to hear about it! I hope this article was insightful and useful as a general guide to grow. While the focus was definitively on junior engineers, I would suggest many of these points are still certainly relevant to senior level folks who have maybe not grown in their company as much as they would like