The BIGGEST Difference Between Juniors and Sr (cloud) Engs
Seek to understand the differences to grow
hello avatars, celt here for a free post on what the biggest difference between juniors and experienced hires. An often covered, topic but i am going to put my spin on it. If you do not seek to understand the differences between these it will be more difficult for you to progress beyond the career L4 associate.
How to grow as a (cloud) software engineer
recently have been tasked with helping some of the new hires actually learn and progress. These kids lucked out, as finding a mentor is actually hard. When we get new hires all of them can can (and do) memorize 75 leetcode problems, data structures, algorithms, and other interview-relevant factoids. This knowledge represents the ‘What’ or the general technical knowledge to determine how to implement simple systems. “what algorithm is used for this function”, “what does the algorithm do”, these are the type of questions that can be easily determined from some independent study or googling. So generally its a waste of our time to answer these questions, which is bad for you.
Where junior engineers are lacking is the ‘Why’ or understanding tradeoff between design decisions. I am not talking about deciding between the space or time optimal algorithms. These decisions tend to be simpler. The decisions between design paradigms, technologies, or platform architecture tend to involve more tradeoffs and higher level org thinking as you must align these with your org-level initiatives. You want to understand how the higher level org decisions were made and the tradeoffs because those are the decisions the senior engineers are making. most juniors are so enamored with the algorithms and the code base they never really think to dig beyond the implementations to why, the the tradeoffs, and similar. These are the questions you should be asking your senior engs and above. Example: “hello <redacted> i noticed in <code file> that the implementation of <technical thing> involves <whatever>, could you provide context and clarity on the other implementations considered and how this implementation was decided on.” That is an example of a higher level question that is extremely specific and shows you have gone beyond understanding the current implementation and you seek understand the context and tradeoffs.
This is actually how i found out about the issue i covered in the last EKS post. I noticed a restriction on how our firm implements EKS that goes against common industry practices. I asked the owner of the design doc: “hello avatar, i notice that the design doc restricts EKS to single tenant on business unit accounts which is does not align with our other service offerings. Could you provide me the context on why this restriction exists and the tradeoffs considered.” Read the post to understand the context on why multi-tenant EKS accounts on AWS are a showstopper.
As time goes on your sr engs will have favourable opinions of you. As you ask these questions it feels like they are teaching you and you are learning and applying. Make sure you sprinkle in shoutouts so they get some credit too. These are the people providing feedback for your performance reviews at most companies, and theyll think about how you are asking stimulating questions and giving them shoutouts which is good for you. On the other hand, if the opposite side is true itll probably be negative feedback.
Bad questions == bad engineer
the depth of questions asks is generally deterministic of the quality of engineer. Generally, the higher level questions are not easily discoverable, and require some type of institutional knowledge to understand. if a junior is consistently asking surface level then it shows they never got past the surface level, or that they never thought deeper. These people are career L4s type and get that one promotion, then never gain enough institutional knowledge and critical thinking to progress and is forced to job hop for 10% raises. If all of your senior engineers are ignoring your questions, it is probably a sign that your questions are not quality enough to intrigue them or show that you are actually doing some due diligence before you ask a question.
A good guide on question asking and answering is here, from the great Eric S Raymond of Linux fame.
Other Ways to Get Promoted
Build a deep technical knowledge that expands past your org so that you can be respected across silos, and have influence across teams. To have that level of influence you must understand the technicals of the surrounding team in order to garner respect from other orgs. You may never be the best backend eng on your team, but you may be the best backend eng on your team with knowledge of DevOps pipelines. Finding that intersection can often be your ‘niche’. Otherwise you are competing with everyone else on the rat race.
The *fastest* way to streamline the learning process is to learn from the *experts* and apply the principles of what you learn to your org. View my recommended publications to see the BowTiedDataOrg, all experts with high quality SubStacks, that will accelerate your career. If you are a free sub consider supporting my work and arming yourself with the knowledge to be a 10x cloud engineer.