Entry-Level Software Engineer [SEP] at JPMorgan Chase

I feel like it's more joyful to positively impact the life of others vs. only getting a really high title/pay. The latter also has high stress, and I don’t want work to be everything. I believe that teaching is a way to improve communication skills and software engineering skills overall, and I would like to mentor more junior engineers than myself at work. Another option I'm considering is going back to my bootcamp App Academy bootcamp to teach others how to code.

How can I be an effective teacher when it comes to teaching coding concepts or mentoring within the company?

I'm currently moving a bit slower than other engineers on my team. Here are some of the problems I'm facing:
- I talked to the manager and he said that if you get stuck after 30 minutes, just ask for help. I will often spend many hours to an entire day working on a problem before asking for help.
- I feel unmotivated to do work until I actually start it. I need to get into the zone, and it takes a while to overcome the initial hurdle.
- How do I feel more uncomfortable in the unknown? The uncertainty is discomforting for me.

How can I be better at executing on my work when it comes to coding and breaking down ambiguity?

For people who work on side projects: I was wondering what is your system when it comes to coding at work and then coding after work? How do you divide your time effectively between the two?

How to best split your time between work and side projects?

I want to be able to plan my work better for sprints, so that I can avoid spillovers or call out anything that might lead to that as soon as possible.

How do I better plan my work during sprints?

Sometimes I feel like I didn't get 40 hours "worth" of productivity after a week, and it didn't make sense to physically spend 40 hours working that week. Is it possible to succeed as a software engineer working less than the traditional 40 hours? I imagine it requires being able to get the work done faster - What are some techniques to do that?

Is it possible to do well at a SWE job working less than 40 hours a week?

How can we identify what are the core in-demand "Legos", especially in the context of what we do commonly on our day to day job?

As software engineers, we are tackled with new things to build regularly, so I was wondering how I could focus on the components (i.e. "Legos") that are built more regularly and learn to build them with high-quality.

I don't have a concrete need for this right now, but I want to be more efficient at work and keep this in mind for when I do get into a new technology. As a web dev, a core in-demand Lego will be like responsive design or something like that right?

How do I identify the core things to learn when picking up a new tech stack?

For context, I mainly work on the web-side, building customer-facing surfaces. I don't want side projects to be something like DSA where it's good for interviews and that's it.

The concept of side projects makes me think of Flappy Bird when it came out. It seems like it started off as a side project, so this is all interesting to me and would love to learn more about the benefits.

How will side projects enhance my skills as a software engineer on the job?

I want to start incorporating habits to benefit myself as an engineer.

What are some habits that strong developers / devs that other enjoy working with have?

In this [Taro Premium session about onboarding at Robinhood](https://link.jointaro.com/mgGgt1vTvcnxVYoE7), Alex mentioned that his technical documentation stood out because no one wrote docs in that much detail.

Are tech docs mainly for how you plan to accomplish a project and are they useful for junior engineers? If so, how do you write good technical documentation?

What should tech docs be written for and how do you write good ones?

I see a lot of engineers get excited by new frameworks, and I can’t emulate that same enthusiasm. There are some exceptions (e.g. when I learned about Storybook.js, I was excited to pick it up as it was applicable to my work), but for the most part, I'm just not as excited as other software engineers about picking up the latest and greatest tech. If I’m not going to get my hands dirty with a new framework or use it at work, I just don’t really care for it. What can I do to be better about this kind of learning?

How can I stay curious while working as a software engineer, picking up new technologies?

JPMorgan Chase & Co. is an American multinational investment bank and financial services holding company headquartered in New York City and incorporated in Delaware.

JPMorgan Chase

Entry-Level Software Engineer [SEP]

The answer is "yes", but there's many caveats here. The 2 broad axes are:
1. Company
2. Your own skills

I was able to work a little less than 40 hours a week at Meta after covid hit and still do well, and I mostly worked a good amount less than 40 hours a week back at Robinhood as a tech lead and also did well. I'll break that down more below, primarily in the skills section. The caveat with the skills is that they're more applicable for senior engineers, but I think the overall mentality is still relevant at any level.

**Company**
- Some companies equate work with raw hours spent, and this is very much the case at more traditional, older companies. The most extreme manifestation of this is making a software engineer hourly instead of truly salaried, which was the case back when I was at PayPal as an SE1: I filled out a timecard every 2 weeks stating that I worked 80 hours. *It is very hard to work less than 40 hours at these companies*, and unfortunately, a lot of companies are like this.
- This means that in order to work less than 40 hours a week, you either need a company that explicitly doesn't expect that of you (these are the more "chill" companies that heavily prioritize WLB) or a company that's more modern and values impact over raw hours spent.
- For the more "chill" companies, the failure mode is that they move really slow and simply don't have enough work for you to do 40 hours a week. This leads to poor personal growth for you.
- For the companies that prioritize impact, they often times just expect so much of it that you need to work 40+ hours a week anyways. This is the case for most engineers at Meta I feel.

**Skills**
- **Prioritization:** If you work at a high-performance tech company, you're going to always have a million things on your plate. It's very easy to feel pressured to do all of them ASAP, and this is often the case for earlier-in-career engineers. I made this mistake myself during my career, especially at Meta. When I went to Robinhood, I had a much more relaxed mentality as I wanted better WLB. I always had a bunch of ideas on projects I could work on, but I would aggressively only do around 40% of them, prioritizing ones that were urgent + high-impact.
- **Working through others:** This is the next core pillar I relied on to work less hours, and this is a staple of every tech lead. By taking the time to mentor other engineers, you can start scaling yourself and handing off pieces of your work to others. The more your mentees trust you, the more eager they are to take things off your plate - This is why I invested so much of my time getting better at mentorship across my career.
- **"Overshooting" your level:** You want to be in a place where even if you only give 80% effort, you are still solidly meeting expectations at your level. There are so many ways you won't be able to function at 100% for a while: Health issues, personal problems, and much more. So if you're gunning for a promotion, try to get there without overworking. This means that when you get promoted, you have probably "overshot" a little bit - You are already functioning at 10-25% above this level. If you need to get promoted by working 40-50 hour weeks every week, that's not a stable promo, and it will be very hard to scale down from 40 hours a week and still survive.
- **Side projects:** This is the least applicable and hardest to do, but if you can make it work for you, it's a productivity gold mine. So instead of doing 40+ hours of work a week to get better at coding, you do coding after work via side projects. I did this a lot, and this made my Android coding velocity *extremely* high. However, YMMV with this - It's definitely easier with front-end and with smaller companies (like Course Hero) where the code of your side projects is similar to your code at work.

Related resources:
- ["What's the difference between a low performer software engineer and a high performer?"](https://link.jointaro.com/rXuwXuTw1Fgxroox6)
- ["What does work-life balance look like across the industry?"](https://link.jointaro.com/T2kFurv9T4s4MP6PA)
- [The Silent Killer Of Too Many Software Engineer Careers: Burnout](https://link.jointaro.com/JksC7EdpqFWCcqC86)
- ["What’s considered working hard?"](https://link.jointaro.com/6Z3kp5pRWqjFbcuv9)

Robinhood, Meta, Course Hero, PayPal

Alex Chiou

Alex already answered this really well. I will just add one extra point

You need to take a step back and better define what you mean by "do well".
If the goal is to get good ratings and become a productive, reliable engineer on the team, absolutely (especially in a health working environment)

If your ambition is to learn as much as you can, quickly become a domain expert in some area and establish yourself as the expert of several areas, then no.

Be honest with your ambitions and choose accordingly.

Staff Software Engineer @ DoorDash, ex-FB, ex-Klaviyo

Seed Zeng

This collection represents the best of what Taro has to offer, personally curated by Alex and Rahul. If you're short on time, go through the content here.

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.

We all have the same 24 hours in a day - The difference is that some are able to get far more out of it than others. Here's what they're doing that others aren't.

Is it possible to do well at a SWE job working less than 40 hours a week?

JPMorgan Chase

Discussion

JPMorgan Chase