Suggestions for working effectively with junior devs?

Unfortunately you will either need to change your attitude or change teams. In your position, the expectation is that you are mostly a working through others and acting as a force multiplier of their work. So doing stuff like:

* figuring out what motivate your juniors and trying to align that with what needs done

* giving them work which stretches their abilities but doesn't overwhelm them

* giving them some space to fail but not too much

* grooming your juniors to be leaders themselves so they can do some of this mentorship

And in general, there are two ways to go. The first is to accept the fact that many senior engineering and most staff engineering gigs are more about this kind of mentorship approach than actually doing work. And basically accept that the prime "getting shit done" years of your career are done and you will mostly be working in this new way now.

The second is to change jobs where you are back in the driver seat. As a senior engineer, these positions DO exist even at FAANG (over on my team, I am the most junior with 12 years of experience). However, the more senior you get, the harder it is to find a role like this, especially in big tech - its the rare exception. Startups and consulting gigs probably better align with wanting to be hands on keyboard, but at the price of a paycut.

A: Welcome to management, it's a sneaky thing sometimes

B: My advice is pretty simple - whenever possible, don't fix their mistakes for them or tackle the cleanup on something they've made a mess of. It's tempting - you'll spot the issues coming way before they do and you'll have a better fix in mind fast, but they need to be able to touch the fire and feel the burn... It builds confidence for them when they do fix it, it shows you have made them responsible and they own something, and in the long term it builds team trust (use your 15 years of judgement here about what can be allowed to fail for a bit without breaking the bank).

C: There are some junior devs (not always labeled junior) who manage to keep their jobs by routinely going through their contacts and getting them to "teach them the code" which really translates into "doing their work". Politely stop doing this - a 5 minute conversation (or less) and a link to some relevant code is enough before you pat them on the back and tell them to go work on it themselves again.

Shocking when you realize places like Amazon will be one L6 and ten inexperienced devs. The L6 will just absolutely micromanage the low yoe devs. So come up with a design for the whole team, break it into pieces, and then grill them on their small designs. The CRs go under the microscope. Sprint planning with some absurdly short estimate. This is how modern software development is done. And its unfortunate that for non critical services, you actually dont need that many experienced engineers.

This is why ageism is rampant, some 35 year old would never agree to this setup.

Either do it, or move to a critical service team where theres actual adults

At a company with “flat team” aspirations it’s like this but the loudest juniors call the shots. Come in with 10 years exp in a language and get constant pushback on my suggestions because I’m new and unproven. After 2 years most of the loud ones that made all the decisions are gone and we’re stuck with something that doesn’t scale and needs to be rewritten because before end of quarter. Amazing how much tech debt is possible in this model.

It's like this in a lot of companies. At FAANG you are probably more lucky because at least most juniors are smart. In general I don't know how to navigate this well. You don't want to be the old guy that constantly dictates things to be done in old ways. But you also can't let them go completely wild with their ideas and have disaster strike later. Onboarding one or two new guys into a team is fine but teams with a majority of newbies are just difficult.

A major problem I have seen in the last years is that the young guys seem to have a preference for super complex systems. Everything needs a http API, Kubernetes, Microservices, multiple repos and complex build pipelines even when a simple server with a database would be just fine.

Nope, this is just how it is in Amazon. Other FAANGs tend to have a better spread of engineering experience. Root cause has always been the high turnover. Once you have enough experience and the AMZN name under your belt, most devs chose to jump ship to somewhere saner.

After having worked at a FAANG and having friends who still do, the way I've seen it is that with your YOE to work basically solely as an IC with less mentorship responsibilities you have to be in a highly specialized, challenging area (AI, ML, etc.). If you're in a more common area like web dev, backend engineering, data ingestion, etc etc. then you're more likely going to have those mentorship responsibilities.

Been at FAANG 6-7 years and was equally surprised as you coming in.

I had a peer more used to it coming in, the best thing he did was build a relationship, subtly establish this wasn't going to be a great place to bring my full self, and be kind day to day minute to minute as questions came up.

More directly, what you described is how it goes and it's sad. The worst part is watching them either find a way to be a part of the grinding machine, get chewed up by it, or give up and be sad. Best thing you can do technically is what you're doing, if you build a personal relationship, you should help them pace and signal the lack of incentives

I too am at a FAANG, and I have 18 years experience(only hte last 4 years at a FAANG).

The "ramp up" barrier is less about how things are done in the real world, but down to a total lack of documentation. Stuff in FAANGs is never really world changingly hard in terms of technical, it mostly a case of playing murder mystery to find out what the "proper" way of doing things are.

There are a couple of ways to help and free up your time:

1) write good instructions for the feature they are supposed to be building. Point them to the systems they need to be using, along with some of the examples you've learnt from, give them introductions to the people they'll need talk to

2) use them as a resource for testing documentation. When they get stuck, help them reach out to the right team to get it fixed. If its your stuff, fix it.

3) have empathy, you are bringing up the next generation. Its your responsibility to make them happy, well rounded individuals, who will train the next generation so you don't have to.

You're not there to fix their shit, you will need to delegate tasks to them, in the full knowledge that they might fuck it up. Your job is to give them moral support so they can fix it themselves.

I’d say that this is less “how fangs work” and more “what gangs are like in 2023”. If you look at the devs hired per Q stats for your company I’m willing to bet that seeing mostly people with 2yoe will suddenly start to make more sense.

My personal theory is that the MBAs discount how much this messes with quality engineering culture, and have no idea what they’re doing by running teams with one experienced manager, one senior, and a bunch of excited juniors.

With 15 years of experience and a bunch of new engineers on your team, your job is no longer to build shit. It's to help everyone else on your team build shit. If that's a problem, you might need to find a new team. I hear that Netflix only hires senior engineers.

Not at during my time at Apple, but I did experience this at Intuit. It seemed like the best way for a manager to be promoted was by their headcount.

It’s important when hiring to make sure you have the resources needed to bring someone on. For hiring a junior dev I would be asking myself if the team can dedicate 10-20 hours a week for pairing for six months.

Also I find it helps both people if there is an expectation around when someone should feel comfortable. Again, no less than six months until I would expect them to feel comfortable.

Clear out what your obligations are with your management.

I've been in positions as a senior software engineer where it's my job to carve up projects and have make sure juniors can get things done. That means checking in with them, make sure they understand stuff, make sure quality is high, and ensure they're not getting blocked. Your management looks to you get the project done. You are not measured by your IC but by your ability to force-multiply to knock out projects.

In these situations, your individual IC contributions go down, but you effectively get to claim delivery of the project under your belt based on ensuring delivery success. (It may be critical in these situations to track how you made that happen.)

It's not just FAANG, it is how many larger organizations work. I would point to the Indian consulting shops like Infosys who typically grow rapidly, hire a lot of "freshers", have a lot of opportunities for promotion, and try pretty hard for the senior people to transfer their experience to the juniors. On a good day those organizations succeed at this pretty well.

I think you need to consciously and continuously figure out where your time is best spent. There is a spectrum between situations where you can afford to let them make mistakes while figuring things out vs. situations where you need the team to execute to your own standards. You can evaluate this in multiple dimensions: productivity, system robustness, code quality, etc.

Think in terms of interfaces, assertions, and consistency checks. How can you be more hands off in the areas where the bar can be lower? What does your involvement need to be when you need the bar to be higher? Is the bar high enough that they will tend to improve over time?

If you are a perfectionist, you will simply end up doing more work than if you had done everything yourself. If you can create a structure that allows you to relax in some areas while helping the team grow their skills, then you will be more productive.

In my experience this really depends on the type of the team. If it is a product team it is likely to have a lot of junior developers and not too many senior ones. If it is some deep Infra/backend team you can have a team that is mainly >L5. I was surprised when picking a team in FAANG the choices were you either join as a tl of a very large team of junior ish devs or you join as TL of a small team with mainly senior devs.

> But in the meantime, my days are quite frustrating because I'm in teaching mode most of the time instead of building stuff.

Look at this as a huge opportunity for you to grow and increase your impact, to become a staff+ eng. Uplevel, teach, "use" them as a lever to do at the end much more than you would be able to do alone

You’re lucky! You basically have an opportunity to multiply the way you work; every day, strive to make yourself redundant. Hand off as much as you can and support along the way; if you do this well, new, more challenging projects will find you. Second, don’t treat them like children, but like peers. That being said, when the corporate bs comes for you or them, don’t throw them under the bus. In fact, protect them. Laud publicly, be critical privately.

As a senior dev, teaching should be a good chunk of the job. As a principal I spend a third of my time mentoring, a third of my time in arch/meetings, and a third of my time building (usually with other engineers doing some of the work). The lower you go down the ladder in terms of experience the more you should be coding.

In general, the role of senior dev is to break down projects into pieces understandable and achievable by juniors.

It helps get them experience and it helps you from having to do literally everything, because it isn’t particularly easy to hire more senior devs.

If they're hiring people who have no more than 2 years of experience they must understand that it will also take a senior like you to be an almost full time mentor to make them productive instead of you building stuff yourself. Are they expecting you to continue building stuff at the same rate you were without doing constant training? That would be a mistake. If not and you're just missing what you used to do, I think you'd have to move to a new team where you're not the one mentoring multiple juniors.

Welcome to being a senior dev. Your job is teaching, coaching, and developing others. Because the better and faster you do so, the better and faster the team will be at achieving your visions. You have the opportunity to set the direction for many engineers and build things bigger than you yourself can build alone, AND the people who will one day be able to help you do that.

Teaching is an investment (and is, imo, super rewarding). Think about where your team will be in one year if you spend the time now to level up everyone.

It’s important to understand your metrics and position roles. If your role is to guide and teach do that. If your org requires you to commit more lines of code then tech the ones you like and let the rest drown.

The success of the project is rarely your responsibility but if it is then obviously manage some sort of in between where you prevent damage, improve others work and do some of the core stuff yourself. This is the worse case scenario because you have to play both lead and manager

My approach: 1) spot ways in which they are slower than you and demonstrate how to do it faster. A lot of people have a hard time doing this without being a condescending dick about it, but if you can pull off "can I show you a really good trick for doing that?" you will force-multiply by showing a bunch of noobs how to get closer to your speed. 2) Give advice on designs and approaches to problems, and try to explain why you're taking that approach. Articulate what principles led to your decision. Enable them to try it themselves, not just learn by pattern recognition. 3) Give away your ideas for free. Nothing pays off better than telling a junior dev "hey, I think you should do [very detailed plan]" and then when they do it, praise them to high heaven for the work they did, taking zero credit other than saying you helped them develop the idea. Everyone knows you deserve the credit, the junior dev thinks you're brilliant and generous (and wants to repeat the experience because they're getting a reputational boost), and you get your great idea implemented without lifting a finger (and can honestly mention your contribution/mentoring on your self-review).

I run a developer experience team at a large company. This something we work on all the time. Keep in mind new devs may struggle with some things we perceive as basic. For example they may spend longer on git or not know the command less. These things take a bit of time. For both code and infrastructure related things - What do you have in place so you’re not always repeating yourself? Is there onboarding documentation? Do you have an architecture diagram written down? Is it discoverable? Are tickets written in a digestible fashion? Are words in the tickets that might be new to them defined somewhere? Are there testing and release checklists with things that are commonly missed and that can’t be automated?

These are all things that take time to implement but pay dividends going forward. Some other companies in this situation may put you in the org chart as something like a “Software Architect”. Until they become more effective your main goal should be getting them collectively more effective. DRY doesn’t apply just to software - it is helpful in the context of documentation as well

I'm not an expert but the little experience I have is that you need to stop helping them. That's how they learn to take responsibility and listen to what they want to do and trust that intuition. You cannot share ownership, you need to trust before you can trust, it's a leap of faith.

OR ----

SoA is a necessary evil for multiple devs.: That way you let everyone free, but they are 100% responsible; and if they face plant completely you can replace a part entirely.

The trick is how to architect the structure: Replicate all services on all machines; they all call localhost; that way discovery is immediate and you can scale easy and read faults are both contained and tolerated. Write faults are never easy, so just accept them, nothing is perfect.

2 big hurdles to achieve that:

  - Your entire solution needs to be completely async., end-to-end = non-blocking on all servers and clients, even deployment.
  - Your data needs to be at the edges with relations to everything everywhere and unformatted = No SQL tables to alter.

----

Which you pick depends on your situation. In some ways you can think of these as before and after your kids move out.

> I'm a senior dev at one of the FAANGs with more than 15 years of experience, but the rest of my team consists of devs with an average of 2 years of experience.

I'm going to guess that it varies widely. I managed a team of 13 at a FAANG, with 1 new grad, 3 in the 1-5 YOE range, and the rest in the 5-10 YOE range. I was the only one with > 10 (over 20 range, actually).

Of that group, that company was the only company they've worked at. Success in getting stuff done was mostly about personality than background or experience. Those who had a need to push on things to get them done succeeded, and those that didn't had a harder time.

The main differentiator, IMHO, was that the FAANG-only folks had little to no concept of System Design or operational elements (i.e. what happens after software has been shipped). There was essentially no opportunity for the former, and no reason to dig into the latter. All the systems they needed to do work were in place, including high level architectures, data pipelines, metric capture, etc.

From the new hire side, the way I explain it is that they should ask the people with 2-3 yoe first since they're the ones closest to the code + have onboarded most recently. It's not that they can't even ask our senior devs questions, but we want to minimize random questions that anyone else on the team can answer. We also try to utilize slack/updated runbooks to make sure everyone learns the answer to questions vs answering the same questions over and over in dms.

Are you trying to be hands on and involved in everything to meet your standards? You have to trust the rest of the team and delegate things, and only step in when shit is completely unacceptable or you'll never get any work done. You should definitely talk with your manager about how much time you're spending on this and make sure that they are aligned with you on your priorities.

Lastly... are you still a new hire? Generally it's better to listen and learn as opposed to telling people to do it your way.

I'm going to make a normative argument here, so please forgive me for preaching, but I think the problem is twofold.

On the one hand, you should lean in to the opportunity to teach more - it's a great chance to consolidate and find your own blind spots. You should schedule a large amount of fixed hours (say, 60% of your work day) to this if its a crucial part of your role.

On the other hand, the company is underserving your juniors by having only one senior to confer with 15 juniors. The ratio should be closer to 1:5 in my experience. This also means you can spend more time with an individual junior to discuss technical points more deeply.

In terms of what you can practically do? That's harder to say, but the other comments here seem helpful. My personal suggestion would be to consider employment elsewhere (while being cordial and pleasant with your existing company throughout and after the departure).

I don't work in a FAANG. I do have 24 years experience in my field however, and most of the people that work for me have 2-3 years.

Stop looking at the differences. Start looking at the capabilities. Trust them with things and see how they do instead of hand holding them. They don't need it or want it. Treat them like coworkers, not subjects.

my team consists of devs with an average of 2 years of experience.

What I'd do. Dont let them write apps from scratch. Or you'll get tech debt and a team with low morale and skills. Have seniors do prototypes and refactors. Reward seniors who it well. Dont reward seniors who dont beat deadlines and keep on doing meetings.

When I was at Amazon I saw a maximum of around half the team being L4. Usually it was people with 5+ years experience at other companies getting down leveled to L4/L5. I don't think we ever had more than 1-2 legit new grads/juniors on a team.

It's not great that they didn't prepare you for this before coming on, but yes: as someone with 15 years of experience your job is not to get stuff done directly but to help your junior devs grow and compensate for their naivete.

If you want to be building this directly you might want to consider startups or consulting, places where they need someone who both has real world experience and can build things? At a FAANG the reason they're willing to pay you so much is your leadership, mentorship, and teaching capacity: you plus a group of junior devs should be much more effective than the junior devs would have been without you.

Talk to your manager and find alignment on what the team needs and how you might fit that. If your manager sees/acknowledges what you do and is in favor of you mentoring more — and you want that — figure it out, put it in writing, etc. If you don’t want that, find alignment with your manager. If they are a good manager they’ll allow you to focus on coding. You might be in a position to give a little and get a lot back both in the eyes of management and your own career satisfaction (teaching over coding as much) so I encourage you to try to zoom out, communicate, and get on the same page as the teams manager.

> my days are quite frustrating because I'm in teaching mode most of the time instead of building stuff

I have no experience at all with these companies, but isn't this one of the main reasons they hire someone like you?

The definition of "Senior developer" is a little bit different everywhere, but I think what's common is that YOUR JOB is now COACHING JUNIORS. Your role is just different, you have to accept that.

> I'm sure they'll figure it out over time. But in the meantime, my days are quite frustrating because I'm in teaching mode most of the time instead of building stuff.

This is what they hired you to do: to help them figure it out. Not over time, but right now. Your job is to power level them.

You aren't there to build stuff anymore. You're there to make everyone else build the right stuff, the right way, and learn how to do it without needing your help anymore.

For the company, you doing that job is more valuable than having you build everything yourself quickly.

To really become valuable in your role you need to leverage your experience and skills to become a force multiplier (as mentioned several other places in this thread).

There is some good advice in here to help junior devs level up. But I would start by boiling it down to one that is easier to remember as you become a manager / coach:

Try to remember what worked well for you when you were learning, and then do that for your team.

I have gone back to that well over and over as I've moved between senior, principal, and management roles.

In organizations that have separate management and IC tracks, there tend to be two ways that the IC track is interpreted as you become more senior:

1) You spend just as much time as you did before in development, only working on harder stuff.

2) You become more like an architect or an attending physician, where you're spending some time in development and some time teaching or consulting more junior devs.

I think most senior ICs would prefer #1, but in reality #2 is more common.

what was it like when you were a new dev? were you frustrated by the lack of mentorship from experienced devs? or did you have some guidance?

could you reframe the situation and see it as, "this is cool, i have all of this experience to share with new developers."? unless you don't want to be a mentor, which idk, good luck.

Wait till you learn their salaries.

Echoing others, embrace it or move.

I’m about a year and a half into working with 4 juniors at big tech, and I’m just amazed by how capable they are now. The first 3-6 months were slow, but now I am struggling to find things to do!

Asking questions is helpful.

Knowing when it's fine to let them go with a 80% perfect plan

You have to build the right thing through them. Then, they can maintain it themselves. If you build it all yourself, you will have to maintain it all yourself.

Source: me, a former team lead who built it all himself.

"because I'm in teaching mode most of the time instead of building stuff."

Based on the structure you detailed, it sounds like that's by design. I guess embrace being a teacher, or leave?

Spot big tickets early and split them into smaller tasks. More junior devs seem to favor large pull requests, which are impossible to thoroughly review.

> I'm in teaching mode most of the time

You have 13 years of experience in the industry more than your buddies. That's expected. And it's not wasted time.

This is what it feels like to get more senior. Your role is to coach others increasingly versus delivery.

You're a journeyman or a master with apprentices, embrace it and schedule your time accordingly.

Mentorship is part of seniority.

If you don’t want it, you don’t want it.

Pair early and often, especially if working remotely.

so leetcode is not hiring the right people after all? too bad

Sounds like you work at Amazon. They had to attempt this method because their reputation/pay is so bad in the industry they’re not able to hire experienced devs.