Entry-Level Software Engineer [P3] at Atlassian

Does it get worse as you progress from L3 -> L4 -> L5 -> L6 -> etc? Intuitively that seems like what would happen as your scope grows across promotions: Is there more overtime associated with the more senior levels?

How does work-life balance shift across levels?

I'm looking to get promoted as fast as possible, so I really want to understand how very senior engineers think. Here's some additional questions to add more depth:
1. If you were to backtrack and retrospectively analyze the careers of the engineers who reach staff level at Big Tech, what's the common thread with all the projects they've worked on?
2. How were they able to land themselves on those projects?
3. What allowed them to put themselves in a position to contribute to such high impact projects?

What are the common themes behind how engineers at Big Tech reach Staff+ levels when it comes to their project execution?

As I figure out which team to join, oncall comes to mind. I've heard that oncall can be pretty intense and stressful here, especially on infra teams. The company has said that they're making efforts to fix this problem, but I'm unsure what to expect there.

How can I figure out whether a team has a healthy oncall rotation? I don't want join a team just to be burned out by a crazy oncall.

How do I factor in oncall into my team selection?

Back when I was an intern, I worked incredibly hard, often times with late hours. Aside from the personal downside of burning yourself out, is there any other way this can hurt you career? Can it skew the team's perspective of you in a bad way?

How is overworking perceived? Can it be viewed negatively?

I recently accepted an offer as a full-stack developer for Atlassian (P4). I have about 2 years of experience.

 My first company was about 12 people (all engineers, no teams) and my current company is about 400 people (about 20 engineers, with my team size being 5 people). The team I'm moving to at Atlassian has about 100 engineers in total, and the team I will be on should have around 10 engineers I have been told. The hiring manager said that the teams are made up mostly of mid-level and senior engineers. 

What can I do to make sure I get up to speed in ample time and be able to make an impact? I would like to become very career focused starting with this job and focus on advancement. My main concern is that maybe my experience in only smaller teams at smaller companies will cause friction for me as it will be a big adjustment.

How can I hit the ground running at a bigger company?

I've heard it's always good to try and understand your manager's perspective, their expectations, and what they need from you.

I assume most junior engineers wouldn't have prior management experience, so it would be useful/insightful for junior engineers gain some perspectives on the priorities and challenges a manager faces whilst running a team, so they can better help the team.

What are some steps one can take to try and understand/see things from their manager's perspective?

My goal is to join a team that would allow me to have the opportunities to work on projects that have the potential to produce higher business impact & learning opportunities to grow and reach promotion in the shortest possible time. Early in my career, I don't think I would mind working longer hours or being stressed as long as it is for good reason (such as the opportunity to be promoted) and within my capacity to handle it and also as long as it is not something that is long-term and chronic stress forever.

This is why I want to understand more about oncall. I know that oncall can be very stressful, and this applies to Atlassian too. Can being oncall be good for learning, even for a junior SWE, or does it always just give you chronic stress for no good reason?

Does being on-call during early career teach you things or allow you to grow technically?

In my earlier experience as an intern, I haven't had much previous experience where I had significant influence over the projects I get to be allocated into; it was typically out of my control as to the sort of projects I got to work on. I've had opportunities to work on incredible projects where I grew a lot and also projects where it didn't quite align with what I wanted to do and also had limited opportunity to grow (e.g. working on some proprietary language or a lower impact project designed to be assigned  to interns).

As I start my job as a junior engineer, I'd like to play more of an active role (wherever possible) to influence the direction as to the sort of project I work on and my growth direction.

In my experience and from my understanding, I think there are several factors when evaluating a project:

1. Your own personal technical background and experience (Zone of Proximal Development)
2. Your own personal career goals and skills you're trying to develop
3. Growth & business impact potential (if your goal is promotion)

Do these factors make sense when evaluating a project, and are there any others I'm missing? Also, how can I figure out #3 more in-depth for any project?

What are some of the frameworks/thought-processes you can use evaluate whether you should pick up a project?

I've heard that situations at Atlassian and other companies in general can be very competitive to the point where engineers are competing against each other for survival with systems like stack rank and team quotas. I'm wondering what's the best way to navigate through systems like these.

How do you deal with zero-sum situations where one's success comes at the expense of another?

Atlassian Corporation Plc is an Australian software company that develops products for software developers, project managers and other software development teams.

Atlassian

Entry-Level Software Engineer [P3]

- Kudos on considering this angle: Most earlier-in-career engineers I've worked with don't even realize that this is a thing!
- The 2 main aspects of an oncall:
  - Severity: How rough is the oncall when you're on it?
  - Frequency: How often are you oncall?
- You want both of the above to be as low as possible (obviously).
- For severity, understand SLA (i.e. how fast you need to respond to issues) and issue volume (how many fires hit the oncall on average).
- Questions to ask:
  - How many people are on the oncall rotation?
  - How quickly do I need to respond to issues?
  - How many issues does the average oncall person face in their rotation?
- Overall oncall attributes:
  - Mobile oncalls are generally more relaxed as you can't fix everything instantly like you can for web/back-end.
  - Flagship products will have more stressful oncalls.

Related resources:
- ["How can I maintain work-life balance with a hectic oncall?"](https://link.jointaro.com/bpTivsdJEbRoNDjA8)
- [1.5 hour masterclass on choosing a great team/company as a SWE](https://link.jointaro.com/RMfMmsJVnVhTfFQo8)

Robinhood, Meta, Course Hero, PayPal

Alex Chiou

Appreciate the advice! What are some examples of good and bad on-call schedules?

- In a vacuum, aim for an SLA > 8 hours so you can sleep, at least 8 people on the rotation so oncall is around once every 2 months, and time spent fire-fighting during oncall to be <50%
- The Android oncall I was on at Instagram (which I also designed!) was an example of a good oncall (it actually came in 1st in the engineering survey of my org rating how healthy eng pillars were). It met all the above attributes.
- Some of the back-end oncalls in my org at Instagram, at least earlier on in their lifespan, were what I would consider a bad oncall (for the individual). Ads is high-pri as it's revenue generating, back-end SLA is low as you can fix/break everything instantly, and some of these oncalls had only 5-6 engineers so you're oncall fairly often. I would read their oncall summaries and they would sometimes have to debug like 25 issues during the oncall, which is crazy.

One thing to evaluate is the **type** of incidents the oncall has historically faced. (Best to talk to a senior eng on the team to talk you through it.)

Some oncalls are difficult because the team is basically middleware -- you get the alert, and your job is to find the correct team to actually fix the issue. These are not fun teams to be on, and it's hard to make these oncalls better.  

However, some oncalls can be improved relatively easily, through better documentation, or building a simple tool around timing or correlation. If that's the case, joining one of these teams could actually be an *opportunity*! Improving the oncall is a great way to ramp up, and generally the bar is lower to "ship something" compared to a production feature.

Meta, Pinterest, Kosei

Rahul Pandey

Almost every software engineer starts their full-time career journey here. The content here breaks down how you can start your career off with a splash and grow past this level as quickly as possible.

How do I factor in oncall into my team selection?

Atlassian

Discussion

Atlassian