0

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

Profile picture
Entry-Level Software Engineer [P3] at Atlassian2 years ago

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?

65
1

Discussion

(1 comment)
  • 0
    Profile picture
    Robinhood, Meta, Course Hero, PayPal
    2 years ago
    • Just to set expectations: You are not likely to have a lot of say over what projects you choose as a junior engineer. At this stage in career, coding proficiency is the most important, meaning that you want to be able to write extremely high quality code very independently and very quickly. Teams/managers generally don't want to overload junior engineers by placing the cognitive load of project selection on them as well.
    • At Meta, entry-level engineers (E3) were explicitly not held responsible for impact as the projects they're working on are pretty much all given to them. You shouldn't be punished or rewarded due to the quality of your tech lead, which isn't something you can really control.
    • The main calculation to make with a project is yield vs. time. You want high yield and low time it takes to complete. Try to label any project you come across on these 2 axes if you are in a position to choose.
    • When it comes to evaluating yield, look for metrics, which you may need to generate yourself, especially with more infra-style projects. Try to match projects against the KPIs/OKRs of your team.