Junior Engineer Career Development Videos, Forum, and Q&A

Some additional questions:

1. Does it vary between big companies and small companies?
2. Do you need to work a lot to be a high performer?

I see engineers like Alex and Rahul, and they have had many accomplishments with pretty fast trajectories leveling up. I'm wondering if there's a primary common theme among software engineers like that - What are they doing that others aren't?

Alex and Rahul and the other senior people on Taro have consistently emphasized how important good software engineering fundamentals are to long-term career success as a software engineer. This is in contrast to learning the latest popular framework or area of development. Can people define what those fundamentals are and how one should go about acquiring/improving them?

Thanks!

Hi everyone! I will join Palantir as a Forward Deployed Software Engineer(FDSE). I need advice on tackling the first 2-3 months at the company to gain team respect and trust. I am excited about this opportunity and want to grow but do it efficiently, if that is even a thing😅. Jokes aside, All I want is to have a great career at Palantir.

YOE: over 2.5years(including just over 1year of internship).

Stack Experience: Ruby on Rails, Python, some Java

Current Work: Backend Engineer. Building and maintaining APIs

Crux is when you’re learning and digging deeper technically. How do you approach taking ownership and growing your impact on not just the project but across the team and larger axis?

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?

My team owns a really wide set of features spanning across multiple repos and programming languages (C++, React, Angular). On top of that, each person works on pretty different areas (telemetry/data, UI components, client side api, etc.). We have a v1 of the app being maintained and a v2 currently being developed with some people working on v1 and some working on v2. It's impossible to know all the context behind every pull request.

How can I give quality code reviews? At most I can only provide feedback to simple code logic and really well written PR descriptions. Should I be trying to private message the developer for each PR to understand more, or is this just something that comes with time?

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.

In particular, I'm having trouble figuring out really complex bugs. For example, on my current project, we're auditing a lot of the existing feature set to see what issues they have so we can fix them as we revamp them. I'm happy to find lots of issues, but I have no idea how to fix them, even after finding a code pointer.

I talked with a senior engineer on my team for help, and they were able to get more color on the situation. However, they mainly were able to do this as they have been in the org for a while and knew who to go to for what: I can't replicate that deep knowledge they have as I'm fairly new to the company. How can I create a systemic process I can follow to figure out these situations?

Amazon is well-known for its design doc reviews, which appear to be small-scale system design reviews. However, I'm having trouble understanding them, let alone recommending modifications.

I'm aware of Alex Xu's , but I'm skeptical using it as it's specifically for interview preparation. I want to learn for the workplace. I can definitely look at blog posts and current design documentation, but I'd prefer something more structured. How can a novice learn system design and grow to the advanced/intermediate level? What books or resources would you suggest?

What can I do to get on the radar of senior engineers within the company and build respect for me overall? My company is also relatively small, so I'm fairly close with the CTO as well.

I'm pretty good at leetcode (was able to pass some 3 to 5 rounds of interviews), I got good at by practicing and continuous learning. Now I want to be good at software engineering in general like debugging, building components, understanding complex things/systems, etc. I see one of the suggestions is to improve on fundamentals of software engineering, how do I do that? and What action items can I follow consistently? Any concrete suggested steps will be great instead of just some general bullet points. Thank you all.

I have recently been laid-off, I was working as a Frontend developer for almost two years. I have prepared my resume and started applying for roles but I have not been in touch with the interview scene in a while. Should I just grind Leetcode?

I'm really new as a Google FTE (still doing some logistical onboarding like getting my laptop fully set up), but I want to hit the ground running and start growing at Google as fast as possible. However, I don't know what I don't know - There's a lot to take in, and I'm unsure where is best to focus and allocate my time.

Fear/stomach-turning when I think about asking people for help (especially in public channels) has been a major blocker for me as a junior engineer.

I am mentoring juniors for the last few weeks. In the past, I've been mentoring people with some professional experience but this colleague doesn't have any. Now, after these few weeks I am wondering:

1. How much time should I spend helping them? Currently, I have to spend 2-3 hours for person per day otherwise they will be blocked for days. Even though I am trying to explain that they can ask other colleagues as well, they are not asking anyone else.
2. How can I be sure what are they suppose to know and what's not? For me, I have my own understanding of what they should know but I know for others may differ. In my country the juniors must be part of an academy before applying for a job. I know what they learn there, so I know what hthey should know and what not. Now, after these few weeks I realize they have gaps which they shouln't have. On the other hand, the academy is typically more than an year and it makes sense many things to be forgetten with the time.
3. How can I measure properly their performance since they are just starting? What is a normal performance?
4. How deep should I go in explanation of his questions? I believe this is where the high quality questions will help them, but I believe they have a lot of gaps to make a quality question and give the proper context.
5. How can I help them to improve their questions instead of having to explain for hours one topic and then another, etc?
6. When should I say I give up on him? I really want to try everything before giving up.
7. How to stay less emotional when explaining the same things for hours to the same person?
8. How can I help them to understand me better? Sometimes, no matter how am I explaining specific case/topic and no matter what examples, nothing helps.

I think the colleagues are really motivated and this is one of the reasons I want to help them. I want to be sure I did everything I can.

I've heard Alex, Rahul, and other engineers within Taro talk about handholding when joining a new company for all engineers and for newer engineers in general.

What does it mean that an engineer doesn't require handholding anymore? Does this mean the frequency of the questions gets diminished or is it more about needing as much initial help to start tasks or something else entirely?