JPMorgan Chase Career Development Videos, Forum, and Q&A

After watching the focus-focus-focus video in the level up your , I was thinking where to find place where I can learn stuff under the hood in java and gain higher level of knowledge.

Most books and tutorials out there I believe they focus on superficial stuff, just enough to get things working.

Thank you.

Recently, I was helping migrate my team’s entire codebase from a legacy Java DateTime library to the newer, built-in Java DateTime library.

I’ve never performed a migration before, so I don’t have context to know whether this kind of migration is typical (my current team isn’t very good). 

Some of the features of the migration:

• The codebase primarily contains poorly written unit tests or tests without assertions (and no E2E or integration tests)

• Consequently, we tested the application by setting up a separate environment, simulating user flows, and manually verifying results inside the DB

• The migration took over a month to perform - meaning constant merge conflicts from new changes to resolve

What might a migration look like at a good tech company? 

For the record, I’m not personally interested in game development - I’m just quite curious.

Everyone hears the following complaints across the gaming industry in general:

• Crunch time

• Lower TCs

I find this quite curious, because I imagine there’s a lot of technical complexity in building games and the numerous tools and engines needed to make them. 

Games are interdisciplinary, combining art, music, sound design, acting, writing, and game design, to create interactive entertainment software - so I would imagine this presents a unique world of challenges that make it just as complex as “regular” software. 

Plus, MMOs and games like Fortnite or Counter-Strike have to deal with all the technical complexity of ensuring a good player experience while having millions of players (clients) playing concurrently.

In fact, Gergely Orosz has on the subject that I found fascinating.

Yet, game developers typically complain of lots of crunch time and being underpaid - and, subjectively, the game dev industry is less “prestigious” than SWE.

Also, I’ve almost always seen devs listed as “game programmer” or “UI programmer” in the credits, as if their primary job is to just write code (and not build good, complex software at scale).

What might be the reason for the differences between game development and regular software engineering?

Questions:

1. Is learning design a worthwhile investment as someone most interested in doing full-stack work at product-based startups?

2. Might working in a small product-based startup be an effective way to pick up design skills while working as a SWE?

3. How can engineers build more complex side projects without any design skills?

Regarding #3:

I’d argue that basic product design skills are critical for building any CRUD application. You can’t build something without defining what it’s going to do first. 

Literally - you can’t write code for a feature if you don’t know how the app will behave during a loading state, an error state, a complex edge case from a wonky user flow, etc.

You can wing the design and iteratively dogfood it to improve its UX - but that’s the same as doing UX design while having zero UX design skills. It’s the software engineering equivalent of writing spaghetti code - except you’re not even improving.

Personally, I find that UI libraries like or are most helpful for solving UI problems like designing a button or a modal. However, they can’t help you decide how a screen in an app should work, nor can they abstract away all design challenges for more custom use cases.

Also, any CRUD application built with poor design will inevitably feel like a crappy database client. 

The design problem applies to backend projects, too. Backends exist to service frontends, so you can’t build a backend without knowing what features the frontend needs - and you can’t do that, either, if you don’t design it first!

These are all challenges I’ve faced working on my own projects.

I suspect the best approach is really to just learn UX design and a design tool like Figma. However, that’d be a hefty investment given UX design is a separate field from SWE - especially if it’s just for a side project.

Also, building cool stuff as a semi-competent engineer is tons more fun (for me) than learning design from scratch!

What are your thoughts on my aforementioned questions?

The question applies to everyone - but particularly to juniors with little experience using cloud services.

For instance, I once built a CRUD web app using Firebase. However, I was wary of providing payment info, given the numerous stories of people getting large bills from accidental overuse or DDoSing. Thus, I wasn’t able to use Cloud Functions, leading to me using Firebase antipatterns.

For instance:

• Creating new user’s profile data in the frontend (instead of a Cloud Function)

• Building a dedicated backend to securely make third-party API calls

• Manually versioning my production data by downloading JSON (no backups available on free tier)

I even considered migrating my web app to Supabase, which doesn’t have this problem (and is also SQL-based), just so I could avoid doing silliness in my code.

More recently, I’d like to build a hacky side project needing a service from Azure (or AWS, or Google Cloud). I could build an MVP in a few hours on the weekend (in fact, I already did - now I just need to connect it to the service). However, I’m wary of providing payment information.
I understand the typical policy is to forgive accidental misusages.

However, I’d prefer to use these tools properly instead of relying on goodwill (which, as , isn’t always reliable).

After all, it would be atrocious marketing to punish small players when most of cloud providers’ revenue comes from large, established organizations operating at scale.

How might I approach this? I’d be interested to hear your thoughts - I know Taro runs on Firebase!

Hey all, I’m a new grad who has been working at JPMorgan Chase for ~3 months, and I would really like some perspective on my experience so far. This essay question will be long, but the overall theme is that my growth feels stagnant and I’ve unfortunately grown to dread coming into work. I’d really appreciate any new perspectives or advice.

For reference, my current career goal is to grow to senior engineer at a startup/Big Tech company as quickly as possible (because a) I like working towards long-term goals and b) software engineering is lots of fun).

A quick timeline:

• I joined JPMC in early August on a React + Spring Boot team

• The first 4 weeks were solely dedicated to training and getting access to stuff

• Thus, I’ve been with my team in full capacity for ~8 weeks now

A core problem is no one is really interested in how I’m spending my time or enabling me to be productive, even with me trying to upwardly manage. For instance:

• On my first day, I had to actively ask my manager and TL for my first task, but they had no immediate plan for me or the other new joiner(s)

• During my first couple weeks, I (nicely) bugged my TL for work so I can get my hands wet and start learning the codebase, to no avail

• Recently, I had a full week of no tasks assigned to me, and no one minded (I had stopped bothering asking for work)

I’ve considered the following:

1. Self-assigning myself work

   1. This won’t work because a) I don’t think that’s allowed and b) I’m not yet onboarded enough to be independently productive

2. Asking to pair program

   1. I’ve mentioned this to two engineers, to no avail

   2. Everyone seems to be focused on getting their own JIRAs completed, and pair programming will inevitably slow them down

Also, because my TL is so busy, it’s hard to get immediate, synchronous help whenever I get blocked, which leads to me having much downtime. In fairness, I understand people are busy and can’t drop their work on a whim, and I should have taken the initiative to get help from other team members too (to not overwhelm my TL).

In any case, the handful of tasks I have been given have tended to be very menial in nature - the type you could better offload to ChatGPT. For instance, adding 1-line changes to business logic or writing unit tests for existing code (that I only partially understand). Most of the work hasn’t helped me develop a mental model of how the system works or learn the business domain.

Here are a few other traits about my team that I’d like to mention, to provide more context in debugging my situation:

• My TL and manager spend most of the day pairing up to deal with production issues

• My manager doesn’t have 1-on-1s with anyone (even new grads)

• Everyone else on the team is busy, as if I’m the only engineer without much to do

• The engineering culture often seems middling at best - unit tests are often written without asserts (solely to reach 80% coverage) and code often has buggy execution paths

The whole experience is unfortunately becoming really frustrating to me. For comparison, I worked on a React/TS + Firebase side project over the summer (it couldn’t have been more than 80-100 hours of work, tops) and I learned so much stuff really quickly - not merely in terms of code velocity, but other higher-level concepts like the tradeoffs of SQL vs NoSQL, data modeling, reading documentation, how to keep a codebase organized, etc. and I also gained much more confidence in my technical abilities. The experience I gained of building something has given me more context to understand how software engineering works. Also, it was tons of fun (like grinding in an RPG, but productive).

On the other hand, I’ve spent almost three months at my first real job and I’ve objectively learned very little. As a result, I’m finding it hard to be motivated to take extra initiative and apply myself when it seems like the environment I’m in has turned out to be so stagnant and slow-moving.

Beyond this, the other major problem is I don’t feel like I’m providing value to anyone (including myself) when I go into work. My only incentive has (unfortunately) become running down the clock so I can leave, which, coupled with the boredom from a lack of work and a 2+ hour round-trip commute, is incredibly draining. It’s really silly - my primary goal right now is to get good at software engineering, yet I’m currently doing the opposite!

I have considered starting a dialogue with my manager and bringing up (some) of these concerns, but there are a few problems. Mainly, I doubt my manager would provide the best insight:

• He directly equates hours worked with productivity and suggests ambitious JPMC engineers should probably work 10-11+ hours early in career

• He suggested using my downtime to do some kind of arbitrary training (unclear what he is referring to), instead of finding real work to learn from

• He doesn’t seem to understand that the work I’ve been assigned is not very meaningful

• He spends all his time coding and very little time managing

• My manager (as part of JPMC for decades) seems to be in the siloed-off JPMC bubble where engineers join and stay for decades - so growth discussions would be centered around being the best JPMC employee, not the best software engineer in general

I don’t mean to criticize - my manager is actually a cool, friendly dude.

Plus, not everything is bad about my experience. There are several green flags:

• Most of the other engineers seem to like their work

• There appears to be some camaraderie in the team culture

• My manager seems flexible and understanding regarding people’s schedules

• My TL/manager have given very positive feedback on the code quality of my (few) contributions so far

• During my placement conversation, it sounded like there’s tons of work/scope available

Nonetheless, it still feels like I’m in a no-win state where my options are:

1. Stay until the tech market improves

   1. It feels really bad to intend on spending a minimum 1-1.5+ years working at a job where I’m learning very little and accomplishing almost nothing. It seems like it would hurt my career growth (and continue to be a really taxing, sucky experience).

   2. It seems like the only two things I’m getting out of this right now are a) income and b) resume continuity.

2. Switch jobs

   1. It feels almost as bad to want to look for a new job after ~3 months, given JPMC’s tech side is so large and reasonably well-known.

   2. Also, job searching as a junior in this current market would be very RNG-heavy, and I don’t want to have a short stint on my resume if I can avoid it.

3. Switch teams

   1. Internal mobility isn’t an actionable option because the program managers want us to spend at least 12 months in our first role.

   2. Also, to switch, you’d need to both find another team via internal networking and have your current manager sign off on the transfer.

4. Quit

   1. The large amount of downtime means I have to spend significant parts of the day running down the clock by simply sitting in my chair and doing literally nothing - which turns out to be far more mentally grueling than one might expect.

   2. The WLB on my in-person days is poor because I have a 2.5 hour round-trip commute, so I have little energy to do anything useful in my free time.

   3. I’ve tried to use my downtime to read books (like Designing Data-Intensive Applications), but this doesn’t remotely replace doing actual work.

   4. I have no expenses so I could quit, though that isn’t the best option. I only mention it because staying at my job comes at the cost of continually enduring this.

What does the Taro community think of my situation? I’d appreciate any and all suggestions on how to fix this.

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.

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

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?

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?

In this , 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?

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?

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.

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?

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.

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.