Ask HN: Suggestions for working effectively with junior devs?
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. At first when I joined, I thought this was an aberration, but there are many teams around me that are structured similarly. Is this how FAANGs try to scale teams? The devs on my team are smart but mostly naive about getting stuff done in the real world. 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.
134 comments
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.
* 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.
I never worked at a FAANG. Do these teams not have managers? Most of those responsibilities seem like the job of a manager. In my career, this approach of one senior person on a team of juniors means the senior is responsible for a lot of the system design and other high level technical decisions, but they wouldn't be counted on for things like motivating other employees.
I think in the end, it's hard to separate technical leadership from human leadership. After you do your system design, you need to divy it up amongst the juniors to get it implemented. When deciding who gets what piece you have to consider what motivates them, what their strengths and weaknesses are, etc... But for sure your manager is helpful in figuring these things out.
At this level, your manager basically becomes your partner, with the same goal of getting the work done most effectively. Your domain is the technical, their's is the human, but there is ton of overlap in the middle
At this level, your manager basically becomes your partner, with the same goal of getting the work done most effectively. Your domain is the technical, their's is the human, but there is ton of overlap in the middle
It's rare a good architect is also a good (and willing) people manager. Organizations and teams profit most when separating those roles, unless you happen upon an individual who does both well. Separating mentorship and design from management has a huge cultural advantage: people who want to make more money don't have to always seek more political power, they can focus on technical skillsets that will make the organization wealthier and more fun to work at.
The architect ALWAYS ends up doing this. The other manager needs to be very active and engaged to actually deliver any value to the team and take some of this work off of the architect.
On my team at least there's a grey area between managers responsibilities and Tech lead responsibilities.
Managers are ultimately responsible for getting tasks that stretch employees abilities, but also in my experience don't have hands on the code. They're usually dealing with politics around team priorities, goals, keeping people motivated, etc.
Managers rely on tech leads to identify work that needs to get done and would be a good fit for the newbie. Tech leads also have to teach newbies best practices, offer advice on designs, etc.
Managers are often technical (e.g. used to be programming daily), but are not actively writing code anymore.
I feel this is a bad situation for tech leads since they have to sort of manage, and do design work, and write code. Kind of a thankless job
Managers are ultimately responsible for getting tasks that stretch employees abilities, but also in my experience don't have hands on the code. They're usually dealing with politics around team priorities, goals, keeping people motivated, etc.
Managers rely on tech leads to identify work that needs to get done and would be a good fit for the newbie. Tech leads also have to teach newbies best practices, offer advice on designs, etc.
Managers are often technical (e.g. used to be programming daily), but are not actively writing code anymore.
I feel this is a bad situation for tech leads since they have to sort of manage, and do design work, and write code. Kind of a thankless job
In my last corporate job we didn't have a manager. Tech lead was filling that role.
"Do these teams not have managers? Most of those responsibilities seem like the job of a manager."
I wish! I do not work at FAANG, but I don't think I've had any managers that were that involved in our work. It's mostly a push-it-down-to-the-dev so everything is on the dev's plate at the end of the day. Which is funny, because I always thought the point if the manager was to remove overhead and coordinate the work so the devs can get more done.
I wish! I do not work at FAANG, but I don't think I've had any managers that were that involved in our work. It's mostly a push-it-down-to-the-dev so everything is on the dev's plate at the end of the day. Which is funny, because I always thought the point if the manager was to remove overhead and coordinate the work so the devs can get more done.
You forgot the part where they:
1. Take credit for your work.
2. Promise to research something and tell you that you can get more work done because they are "handling it" and then provide no information, so you are saddled with MORE work in addition to what you already had to do.
3. Give direction without understanding anything to feel important.
As you can see, there is some recent trauma here.
1. Take credit for your work.
2. Promise to research something and tell you that you can get more work done because they are "handling it" and then provide no information, so you are saddled with MORE work in addition to what you already had to do.
3. Give direction without understanding anything to feel important.
As you can see, there is some recent trauma here.
Same. Cosign, I've been prepped for it for 2 years and it's still a surprise and bad because I gave every opportunity, and then some, to prove it wasn't this silly and lazy. It is.
They will tell you as little as possible, at the very last minute, when they get bored of you asking for help.
You can literally change a field and if you expect your manager to do anything to help along the way, they won't. When you ask, they won't. When you ask again and highlight real bad behavior, they won't. When the bullying occurs right in front of them, they'll blame you and the other manager and tell you they didn't understand. Do. Not. Stress. Yourself. For. These. Places, dear Reader
They will tell you as little as possible, at the very last minute, when they get bored of you asking for help.
You can literally change a field and if you expect your manager to do anything to help along the way, they won't. When you ask, they won't. When you ask again and highlight real bad behavior, they won't. When the bullying occurs right in front of them, they'll blame you and the other manager and tell you they didn't understand. Do. Not. Stress. Yourself. For. These. Places, dear Reader
I think having this position is actually a tacit partial compromise (a perk) for people like the OP (or myself, I'm in a similar situation and have similar feelings about it). I've seen people willingly jump from being a senior dev to being a manager, and either cease or limit actual dev work; however myself and many others don't want to be a manager, full stop. So, I end up doing the tech lead work (planning, design, divvying up work, interacting with other teams a lot esp. on high level, making sure it all comes together), and some of the more technical mentorship/etc. stuff, while the actual manager, who is also my manager, does most of the latter, including most of the motivation and all the HR/promo stuff. If I had to do all the latter I'd likely switch jobs, my manager might suspect as much.
That seems like a pretty good compromise ... in your case.
For most people in this position the sane advice is GET OUT.
The company plans to leech as much of the value of your experience as possible, and pass it on to cheaper juniors.
Furthermore they will pay you nothing for this (it's an opportunity to "give back"), but they will use you to hook naive juniors for lower pay (an opportunity to "learn from the best").
Basically the company is exploiting you to scam your replacements.
For most people in this position the sane advice is GET OUT.
The company plans to leech as much of the value of your experience as possible, and pass it on to cheaper juniors.
Furthermore they will pay you nothing for this (it's an opportunity to "give back"), but they will use you to hook naive juniors for lower pay (an opportunity to "learn from the best").
Basically the company is exploiting you to scam your replacements.
Hmm, so if there are a lot of junior developers - inevitable as more people are getting STEM degrees - I should not help them grow, so that they are not able to do my job? Sounds pretty bleak. Continuing this to its logical conclusion, should I try to sabotage them too? :)
By the time cheaper juniors are able to do what I do they might demand the same salary I demand, or whatever salary I might be able to demand at the time.
Frankly even from a cynical perspective, this doesn't check out. Juniors usually don't try to own the same thing - I'm already there and at any given point could do it better, shared component ownership is rare, plus they'd rather own something new so they can get promoted. Plus juniors move around more. Moreover, while new juniors are relatively easy to replace or outsource, someone with tons of expertise in the area and experience of owning it and working thru others is harder. So, being a large area lead seems more secure than being a junior.
By the time cheaper juniors are able to do what I do they might demand the same salary I demand, or whatever salary I might be able to demand at the time.
Frankly even from a cynical perspective, this doesn't check out. Juniors usually don't try to own the same thing - I'm already there and at any given point could do it better, shared component ownership is rare, plus they'd rather own something new so they can get promoted. Plus juniors move around more. Moreover, while new juniors are relatively easy to replace or outsource, someone with tons of expertise in the area and experience of owning it and working thru others is harder. So, being a large area lead seems more secure than being a junior.
> Continuing this to its logical conclusion, should I try to sabotage them too?
Similarly, if you are not donating blood, the logical conclusion is to become a vampire. :)
If you want to help junior developers, there are many other ways to do that. For example, you could teach a programming course, make a paid video at Udemy, or write a book. If your goal is to help junior developers, skip the intermediary, be more efficient, own the copyright, and set your own working hours.
Similarly, if you are not donating blood, the logical conclusion is to become a vampire. :)
If you want to help junior developers, there are many other ways to do that. For example, you could teach a programming course, make a paid video at Udemy, or write a book. If your goal is to help junior developers, skip the intermediary, be more efficient, own the copyright, and set your own working hours.
My point was that not helping your coworkers succeed because you are afraid they'd take your job (unless that appears to be an explicit goal) is a very bleak mindset, and probably self-limiting too, as far as one's own career goes. My goal is to eat candy and poop diamonds, I don't have altruistic motives towards junior developers :)
[deleted]
Talented software engineers are generally tasked with every task.
I'd say this tracks my non faang experience.
I used to find it frustrating to have a team full of greenhorns but changed my tune quickly.
> Startups and consulting gigs probably better align with wanting to be hands on
Also tracks.
I used to find it frustrating to have a team full of greenhorns but changed my tune quickly.
1. They were eager as hell. It's refreshing to be surrounded by people like that.
2. You can get more done with them by training and helping mop up the occasional mistake than you can without them.
> Startups and consulting gigs probably better align with wanting to be hands on
Also tracks.
> * figuring out what motivate your juniors and trying to align that with what needs done
This is true, but be careful about taking this too far.
Young people arrive at the workforce with a wide range of expectations and motivations. Some of those are going to be unrealistic. You should always try to work with them to understand what drives them and help them find their fit.
The most frequent misaligned expectation I've seen in juniors is the desire to lead greenfield projects in year 1 of their career. It can be very disappointing to arrive at your dream job and learn that you have to work on someone else's code, and that you have to build a reputation before they'll hand you the fun greenfield work.
This is true, but be careful about taking this too far.
Young people arrive at the workforce with a wide range of expectations and motivations. Some of those are going to be unrealistic. You should always try to work with them to understand what drives them and help them find their fit.
The most frequent misaligned expectation I've seen in juniors is the desire to lead greenfield projects in year 1 of their career. It can be very disappointing to arrive at your dream job and learn that you have to work on someone else's code, and that you have to build a reputation before they'll hand you the fun greenfield work.
Literally just had this situation come up in a recent 1:1 with one of our junior devs.
He asked about being able to work on greenfield projects focusing on AWS technologies.
I had to go into a historical context data dump on the value of addressing technical debt (the project she is being assigned to), and how that frees us up to work on the cool and shiny projects.
I think it landed, but I could see some of the fire slightly snuffed out of him.
He asked about being able to work on greenfield projects focusing on AWS technologies.
I had to go into a historical context data dump on the value of addressing technical debt (the project she is being assigned to), and how that frees us up to work on the cool and shiny projects.
I think it landed, but I could see some of the fire slightly snuffed out of him.
I wish there was more focus on working with existing code in education, since it is by far most of the work in real projects, and also the hardest.
It's kind of hard to make "legacy" purposefully bad code that is useful for teaching assignments. Certainly a lot more work than drawing up a spec.
Changing existing bad code i an advanced topic.
Just working with adding features to decent existing code is all I ask.
Just working with adding features to decent existing code is all I ask.
> In your position, the expectation is that you are mostly a working through others and acting as a force multiplier of their work.
OP said that his role is senior developer. Developer. Not a manager. Not a team lead. But someone who wants to write code, preferably together with other experienced developers, and by doing so, enjoy the process of learning and understanding technology at a deeper level. Why, then, would one expect his responsibility to be motivating juniors, giving them work, or raising them to be leaders?
Also, if someone wants to write code, teamed up with other senior developers, where should one go?
OP said that his role is senior developer. Developer. Not a manager. Not a team lead. But someone who wants to write code, preferably together with other experienced developers, and by doing so, enjoy the process of learning and understanding technology at a deeper level. Why, then, would one expect his responsibility to be motivating juniors, giving them work, or raising them to be leaders?
Also, if someone wants to write code, teamed up with other senior developers, where should one go?
This is what the role looks like in the vast majority of bigger tech companies, for good reason. Tech companies biggest hurdle is steering the boat. To launch anything you need to coordinate, align, and get consensus, beyond just your own team. Can engineerings develop in a vacuum? Can they take even well defined tickets, and build an optimal solution without knowing the product direction and vision?
The manager is a people manager, not a product builder. Marketing, product, other engineering teams, all need to be aligned. As the most senior you're probably setting the high level architecture, so you're going to be the "API" or point of contact on which the other architects on other teams will need to communicate.
Selling that architecture to juniors involves all those things mentioned, and as the architect you're responsible and the best person suited to judging their work as aligning with the vision/architecture. Senior role is usually defined and evaluated in performance reviews for the impact that goes beyond the code.
I'm not explaining it super well, but its something you realize is a natural part of the role as an engineering leader. And that what a senior+ engineer is, a leader. Mid level engineer is a terminal role in a lot of companies for those who don't want the added responsibility.
To your other point, there do exists teams where its all seniors who mostly do IC work. These are usually high-value, high-risk, core product engineering R&D. Or some kind of DX (Developer Experience) team where you are building tooling for other engineers, but even these teams too often has juniors, as at the end of the day, they are just another type of platform team
The manager is a people manager, not a product builder. Marketing, product, other engineering teams, all need to be aligned. As the most senior you're probably setting the high level architecture, so you're going to be the "API" or point of contact on which the other architects on other teams will need to communicate.
Selling that architecture to juniors involves all those things mentioned, and as the architect you're responsible and the best person suited to judging their work as aligning with the vision/architecture. Senior role is usually defined and evaluated in performance reviews for the impact that goes beyond the code.
I'm not explaining it super well, but its something you realize is a natural part of the role as an engineering leader. And that what a senior+ engineer is, a leader. Mid level engineer is a terminal role in a lot of companies for those who don't want the added responsibility.
To your other point, there do exists teams where its all seniors who mostly do IC work. These are usually high-value, high-risk, core product engineering R&D. Or some kind of DX (Developer Experience) team where you are building tooling for other engineers, but even these teams too often has juniors, as at the end of the day, they are just another type of platform team
...Because OP is getting paid a big salary to do what the business requires, not what they wish their responsibility could be?
> Also, if someone wants to write code, in a team with other senior developers, where should one go?
> Startups and consulting gigs probably better align with wanting to be hands on keyboard, but at the price of a paycut.
> Also, if someone wants to write code, in a team with other senior developers, where should one go?
> Startups and consulting gigs probably better align with wanting to be hands on keyboard, but at the price of a paycut.
> ...Because OP is getting paid a big salary to do what the business requires, not what they wish their responsibility could be?
Is this what the business truly requires though? As a person grows his skill in software development domain, does the business really require him to transition from being an expert programmer to being an unskilled manager? Being a competent software developer doesn't qualify one for a big salary?
Isn't it what the Peter Principle was all about?
Is this what the business truly requires though? As a person grows his skill in software development domain, does the business really require him to transition from being an expert programmer to being an unskilled manager? Being a competent software developer doesn't qualify one for a big salary?
Isn't it what the Peter Principle was all about?
What the business truly requires is an abstract question. What the business expects of him, however, has been answered in this thread. The purpose of a system is what it does, etc.
> Also, if someone wants to write code, teamed up with other senior developers, where should one go?
Many startups are like this.
They're typically picky about letting new people in.
Many startups are like this.
They're typically picky about letting new people in.
Yes, and now his role is developing the technical talents of others so that they too can be senior developers. If you're in a large company that is 90% of what is expected out of senior technical people.
> OP said that his role is senior developer. Developer. Not a manager. Not a team lead. But someone who wants to write code, preferably together with other experienced developers, and by doing so, enjoy the process of learning and understanding technology at a deeper level. Why, then, would one expect his responsibility to be motivating juniors, giving them work, or raising them to be leaders?
It sounds like you and the OP want to be "just" an engineer (mid level ), which is a terminal level at these companies. You can stay there your entire career, make the maximum salary for that band, and continue to focus mostly on writing code.
Wanting the higher pay and title, but none of the responsibility isn't realistic. You have misunderstood what the senior / staff role is, not the company. The expectation is you lead, mentor, and do less coding.
Alternatively, become very, very deep at a niche field, like high performance computing, and go work for a trading firm if your goal is the same salary while focusing on writing code. Few others will pay you 500k+ to solve common distributed system problems and producing CRUD apps.
It sounds like you and the OP want to be "just" an engineer (mid level ), which is a terminal level at these companies. You can stay there your entire career, make the maximum salary for that band, and continue to focus mostly on writing code.
Wanting the higher pay and title, but none of the responsibility isn't realistic. You have misunderstood what the senior / staff role is, not the company. The expectation is you lead, mentor, and do less coding.
Alternatively, become very, very deep at a niche field, like high performance computing, and go work for a trading firm if your goal is the same salary while focusing on writing code. Few others will pay you 500k+ to solve common distributed system problems and producing CRUD apps.
This is the most honest answer and something I have seen a lot folks who want the higher pay of the higher roles but none of the responsibility.
> lot folks who want the higher pay of the higher roles but none of the responsibility
Isn't building a high-quality product with a sound architecture, while making correct technical decisions, and writing well-tested and properly documented code, all the while identifying and integrating the best practices that your field has developed so far responsibility enough?
Isn't building a high-quality product with a sound architecture, while making correct technical decisions, and writing well-tested and properly documented code, all the while identifying and integrating the best practices that your field has developed so far responsibility enough?
Not really, no. The value of your contribution over the person next to you is marginal at best after a certain point. Even if you are say 50% more efficient than the next engineer. You will still be less valuable than someone who operates as a force multiplier improving the efficiency of 8 engineers by 15%.
Now, don't get me wrong I love having doers on my team but when the rubber meets the road I'll reward the folks who lift all boats first.
Especially with the rate of turnover these days, having someone who can rapidly onboard and get engineers up and running can make huge difference and if you are working on basic B2B SAAS stuff on standard languages, there are tons of good mid-levels out there.
If you shift into niche languages or are doing something complex the equation is likely to change.
Now, don't get me wrong I love having doers on my team but when the rubber meets the road I'll reward the folks who lift all boats first.
Especially with the rate of turnover these days, having someone who can rapidly onboard and get engineers up and running can make huge difference and if you are working on basic B2B SAAS stuff on standard languages, there are tons of good mid-levels out there.
If you shift into niche languages or are doing something complex the equation is likely to change.
> The value of your contribution over the person next to you is marginal at best after a certain point. Even if you are say 50% more efficient than the next engineer. You will still be less valuable than someone who operates as a force multiplier improving the efficiency of 8 engineers by 15%.
If someone is 50% more efficient than someone else, I would naively think it makes sense to pay them 50% more... without requiring them to also become a part-time manager.
If it isn't so, then it naively seems to me that junior developers are overpaid, and senior developers are relatively underpaid. Improve your productivity by 100%, and get a 10% raise (or a 30% raise but you also get extra duties).
Some companies simply do not hire junior developers, which seems like they agree with me. And the companies that hire juniors, are probably doing it out of desperation (because seniors are not available at the moment), or because they expect that most of those juniors will forget to negotiate for a higher salary when their productivity multiplies a few years later. Would you hire junior developers if you knew with 100% certainty that after 1 year all of them will leave in order to get a market-level salary for their gained experience?
If someone is 50% more efficient than someone else, I would naively think it makes sense to pay them 50% more... without requiring them to also become a part-time manager.
If it isn't so, then it naively seems to me that junior developers are overpaid, and senior developers are relatively underpaid. Improve your productivity by 100%, and get a 10% raise (or a 30% raise but you also get extra duties).
Some companies simply do not hire junior developers, which seems like they agree with me. And the companies that hire juniors, are probably doing it out of desperation (because seniors are not available at the moment), or because they expect that most of those juniors will forget to negotiate for a higher salary when their productivity multiplies a few years later. Would you hire junior developers if you knew with 100% certainty that after 1 year all of them will leave in order to get a market-level salary for their gained experience?
>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.
100% and this is far from being a FAANG thing (never mind that FAANG doesn't even exist anymore). My experience is mostly in startup and PE based companies and it's like that there as well. The majority of my managers have been non-technical, corporate continues to shrink the management layer to "save money" (line managers with 20+ engineers), support roles like project managers in many places have been eliminated, and managers seem to spend the majority of their day dealing with comms so organizing and managing the doing aspects of doing work have fallen to me as a Principal, Staff, Lead engineer. My role these days seems to be to come in and bring organization to chaos, mentor / teach engineering (not how to code but how to be a professional engineer), be a tie breaker on big technical decisions, and set the vision and direction for my teams. Most folks I know who wanted to stay doers topped out a Senior or Engineer II and chose to stay there.
This is also likely to just increase or accelerate as the baby boomer generation (the largest working generation ever) who occupies a lot of leadership roles these days start to retire and leave a huge gap in qualified and ready candidates to fill the void. There just aren't enough of us so I expect we will see more and more folks press ganged into leadership that never really wanted that.
100% and this is far from being a FAANG thing (never mind that FAANG doesn't even exist anymore). My experience is mostly in startup and PE based companies and it's like that there as well. The majority of my managers have been non-technical, corporate continues to shrink the management layer to "save money" (line managers with 20+ engineers), support roles like project managers in many places have been eliminated, and managers seem to spend the majority of their day dealing with comms so organizing and managing the doing aspects of doing work have fallen to me as a Principal, Staff, Lead engineer. My role these days seems to be to come in and bring organization to chaos, mentor / teach engineering (not how to code but how to be a professional engineer), be a tie breaker on big technical decisions, and set the vision and direction for my teams. Most folks I know who wanted to stay doers topped out a Senior or Engineer II and chose to stay there.
This is also likely to just increase or accelerate as the baby boomer generation (the largest working generation ever) who occupies a lot of leadership roles these days start to retire and leave a huge gap in qualified and ready candidates to fill the void. There just aren't enough of us so I expect we will see more and more folks press ganged into leadership that never really wanted that.
I for one am excited about this potential transition from eager leaders to reluctant ones. Sure, there will be bumps. Difficulties.
It might yield something new. Perhaps more focus on getting things done rather than getting things.
It might yield something new. Perhaps more focus on getting things done rather than getting things.
Boomers already retired a while back, with even fewer exceptions after covid.
Baby Boomers: Baby boomers were born between 1946 and 1964. They're currently between 57-75 years old
They haven't. I'm GenX and all of my boomer parents still work and lots of my friends boomer parents. It's starting but it won't peak for about 5 years.
They haven't. I'm GenX and all of my boomer parents still work and lots of my friends boomer parents. It's starting but it won't peak for about 5 years.
1950 was over 70 years ago. That is the center and the vast majority of those folks are retired. The smokers/drinkers have passed away already. The stragglers are few and not a significant factor in the workforce any longer.
That seems like a fairly good example.
For better, or worse, many tech companies, these days, seem to be obsessed with hiring large armies of inexperienced developers.
I have always assumed that they rely on embedded process, to get these developers to work towards release-ready products, but they may also be relying on mentorship and training from senior developers (I like that, better).
In my previous position, we did some fairly advanced and unique stuff (image processing pipeline stuff, in C++). It was almost impossible to hire engineers that already knew it. We had to look for people that "had potential," and hope to train them into a workflow.
It also meant that each employee was a big investment in time, and encouraged us to keep them on board for many years.
Training (I've done a lot) is a big fat pain, and not for everyone; but I feel that it is well worth it, to learn to do it.
It makes you a "go to" person for problem-solving (which not everyone likes, but problem-solvers are extremely valuable). It also engenders trust, deference, and respect.
TL;DR, it's good for your own personal career, to become a good mentor.
For better, or worse, many tech companies, these days, seem to be obsessed with hiring large armies of inexperienced developers.
I have always assumed that they rely on embedded process, to get these developers to work towards release-ready products, but they may also be relying on mentorship and training from senior developers (I like that, better).
In my previous position, we did some fairly advanced and unique stuff (image processing pipeline stuff, in C++). It was almost impossible to hire engineers that already knew it. We had to look for people that "had potential," and hope to train them into a workflow.
It also meant that each employee was a big investment in time, and encouraged us to keep them on board for many years.
Training (I've done a lot) is a big fat pain, and not for everyone; but I feel that it is well worth it, to learn to do it.
It makes you a "go to" person for problem-solving (which not everyone likes, but problem-solvers are extremely valuable). It also engenders trust, deference, and respect.
TL;DR, it's good for your own personal career, to become a good mentor.
For better, or worse, many tech companies, these days, seem to be obsessed with hiring large armies of inexperienced developers.
I suspect that has been true in many tech companies over the past few years but will be much less true in those same companies over the next few years.
A culture where everyone with <10 YOE is job hopping every 18 months for a big compensation boost does not encourage either investment in training up those people by a company or development of deeper skills and experience by an individual.
If the recent trends in the tech employment market carry on this year I expect we'll see a lot more incentives for good people to stay with good employers for longer and a lot less willingness by employers to pay silly money for those with little experience and limited skills. Just like previous market swings we'll probably see less emphasis on hiring and more on stability and longevity of good working relationships.
I suspect that has been true in many tech companies over the past few years but will be much less true in those same companies over the next few years.
A culture where everyone with <10 YOE is job hopping every 18 months for a big compensation boost does not encourage either investment in training up those people by a company or development of deeper skills and experience by an individual.
If the recent trends in the tech employment market carry on this year I expect we'll see a lot more incentives for good people to stay with good employers for longer and a lot less willingness by employers to pay silly money for those with little experience and limited skills. Just like previous market swings we'll probably see less emphasis on hiring and more on stability and longevity of good working relationships.
Those bullet points are spot on. Once you reach a certain level of experience, by years and/or breadth of experience, you are far more effective and valuable as a source of advice and education than as a code slinger.
Small correction: Consulting gigs are not a paycut. They are a pay multiplier.
OP never said he was their manager. In fact, OP's manager probably doesn't want him to be mentoring all day long.
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.
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.
> 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.
so, you never work with issues with colleagues for > 5 minutes at a time? Is that normal? I understand you shouldn't do their work for them, but surely there's times when a longer coworking session is appropriate
so, you never work with issues with colleagues for > 5 minutes at a time? Is that normal? I understand you shouldn't do their work for them, but surely there's times when a longer coworking session is appropriate
That's a fair ways off what I actually said.
Pairing is fine, long sessions (1 to 3 hours) can be genuinely helpful and good experiences.
They are less helpful if your colleague requires that session to get anything done. If their answer to the question "Show me what you've got so far?" is "ummmmm" or otherwise blank... time for the link and a pat on the back.
If it's "I tried this and it didn't work" or "I have this thing on this branch but I'm stuck" or "This is close but I can't figure out this error" - sure, dig in.
Pairing is fine, long sessions (1 to 3 hours) can be genuinely helpful and good experiences.
They are less helpful if your colleague requires that session to get anything done. If their answer to the question "Show me what you've got so far?" is "ummmmm" or otherwise blank... time for the link and a pat on the back.
If it's "I tried this and it didn't work" or "I have this thing on this branch but I'm stuck" or "This is close but I can't figure out this error" - sure, dig in.
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
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
Is this first hand experience? And if this is the case in most org/teams or just AWS?
Yes, this is the model, even though people generally wont speak it out loud within the company.
This (experienced manager, many very-junior analysts) is also the model in consulting.
Matches my experience on both counts
That's also what you see at underfunded startups.
I've seen this approach in a non-amazon company
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.
Sorry it's hard to hear this, but you are definitely lacking some skillset of persuasion or communication. There are always "fights" in the beginning I guess, but if you are confident, know your shit, it should be very easy to convince less experienced people.
One thing you might not be aware of is "social capital", "setting expectations", "assertive communication" and things like that.
Sure, in an ideal world, wisdom should always win over loudness, but until that happens (never), you have to learn these soft skills to be the reasonable voice in a team.
I always found my voice in every team very early on, due to my knowledge, my high quality of work and being confident (in my abilities and my work.)
One thing you might not be aware of is "social capital", "setting expectations", "assertive communication" and things like that.
Sure, in an ideal world, wisdom should always win over loudness, but until that happens (never), you have to learn these soft skills to be the reasonable voice in a team.
I always found my voice in every team very early on, due to my knowledge, my high quality of work and being confident (in my abilities and my work.)
> if you are confident, know your shit, it should be very easy to convince less experienced people.
No, it isn't. I am fully aware that I am lacking some kind of ability to champion projects, explain things that seem obvious to me, and convince others, but I am also the absolute subject matter expert, know every piece of this shit and am completely confident in what I'm telling them. That's why it's infuriating to watch blatantly stupid projects with no basis in reality kick off then crash and explode in exactly the way I predicted. It is 100% a communications failure on my part. The confident salesman idiot will win every time.
No, it isn't. I am fully aware that I am lacking some kind of ability to champion projects, explain things that seem obvious to me, and convince others, but I am also the absolute subject matter expert, know every piece of this shit and am completely confident in what I'm telling them. That's why it's infuriating to watch blatantly stupid projects with no basis in reality kick off then crash and explode in exactly the way I predicted. It is 100% a communications failure on my part. The confident salesman idiot will win every time.
Sometimes you can be an excellent communicator and you're still just working with morons.
In my experience coming in as the new guy with X many more years of experience doesn't automatically mean you're going to be listened to no matter how "assertive" you are. Communicating assertively can easily cause others (especially newer devs) to be on the defensive. If a whole team has decided on a trajectory you're not likely to change things very quickly by just exuding confidence. You don't have much "social capital" on a brand new team until you've demonstrated your skillset.
Also I find the habit of passing judgment of a person on an internet forum extremely distasteful and pretty disingenuous - you don't know enough about this person from a two sentence forum comment to judge their communication/persuasion skillset. It does nothing to support your argument or do anything other than make you feel superior to that person.
Also I find the habit of passing judgment of a person on an internet forum extremely distasteful and pretty disingenuous - you don't know enough about this person from a two sentence forum comment to judge their communication/persuasion skillset. It does nothing to support your argument or do anything other than make you feel superior to that person.
Why think this by default? I am in a similar situation as OP, 20 years of experience as dev, team lead and engineering manager, yet because I didn't know the intricacies of our custom framework the second I walked in the door, many of my suggestions were dismissed upfront and, a year in, I feel it's an uphill battle to get my ideas treated with anything other than suspicion.
That suspicion is healthy. You don't know the technology being used, per your own admission.
Ah, if only I had a dollar for every project turned into a mess because some engineering manager (who probably coded in COBOL last) thought they knew what they were talking about and pushed down some crappy choice
Ah, if only I had a dollar for every project turned into a mess because some engineering manager (who probably coded in COBOL last) thought they knew what they were talking about and pushed down some crappy choice
Ok, but I'm an IC here.
> There are always "fights" in the beginning I guess, but if you are confident, know your shit, it should be very easy to convince less experienced people.
Why would anyone do that, though? This is management's job to help get value out of senior engineers. It'll be the company debt to pay this technical debt. You still get a salary at the end of the day.
Why would anyone do that, though? This is management's job to help get value out of senior engineers. It'll be the company debt to pay this technical debt. You still get a salary at the end of the day.
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.
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.
From personal experience, I got the impression that Amazon was not even that interested in hiring experienced developers. I think they decided that churning through early-career engineers was ultimately more effective for them.
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 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.
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.
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.
That was true of Netflix until about 2021, back when they still had a flat structure. Since then, they started hiring for levels below senior as well.
Sadly, there are no engineering postings on their jobs page right now, so all I have at the moment is secondary sources[0] and personal accounts.
0. https://blog.pragmaticengineer.com/netflix-levels/
Sadly, there are no engineering postings on their jobs page right now, so all I have at the moment is secondary sources[0] and personal accounts.
0. https://blog.pragmaticengineer.com/netflix-levels/
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.
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.
That's a very reasonable estimate for the drag a new person, not even just a junior, can put on a team! I like it!
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.)
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.
A lot of large companies do this. I think in the past 2 weeks I have had maybe 3-5 hours to work on my stuff. The rest is meetings and showing others how to do something.
Do you find that this creates a degree of background stress/anxiety? After many years of being a highly effective IC/consultant, I’m still trying to adapt to being primarily a manager with a software engineer title, and not sure how well that’s going. It can feel unsettling.
For me going from being 'the guy who does tons of stuff' to the 'guy who knows stuff' has had some upsides but some downsides. Upside is I get to share with others and get more people going and doing good stuff faster. As a group we are better off. But narrowly on me, however, that has come at a cost of my productivity is lower. I also have to manage expectations of what I can do now with managers. It does make me feel like I am not getting anything done too. But if I can unstick 4 other people I guess it is a win...?
I think many people find it hard to make the transition.
Logically if you can double the productivity of 10 freshers you can contribute more value than you can as a highly productive IC who is 10 times more productive than a fresher. Your instincts as an IC can have you feeling you are not productive at all though.
Logically if you can double the productivity of 10 freshers you can contribute more value than you can as a highly productive IC who is 10 times more productive than a fresher. Your instincts as an IC can have you feeling you are not productive at all though.
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.
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.
Do you have some examples of situations where it’s ok for them to make mistakes while figuring things out?
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
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
Also it sounds like there is a need to be more aggressive with managing your calendar. At some point you have to organize your time into blocks where you can actually do work and manage when you are in "teaching mode".
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.
As a senior dev theoretically on track for principal, I'm finding coding occupies maybe 10% of my time over a full year. The rest is largely in "leadership" meetings where we argue over details about goal language and trying to figure out how to blame project failures on "dependencies".
Not really what I went into this field for. I miss my halcyon days being a low rank engineer churning out project tasks, but I do get the need for technical people to be providing the right guidance to help herd the cats in management.
Not really what I went into this field for. I miss my halcyon days being a low rank engineer churning out project tasks, but I do get the need for technical people to be providing the right guidance to help herd the cats in management.
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.
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.
This plus do not get overly distracted by the ones who can’t figure it out on their own after some basic guidance. Identify the juniors who do well, and leverage them to help drive your / the org’s goals. They will get promoted and you will hit your goals faster. It’s a balance though because you have to carve out your own time too.
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.
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
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
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:
Which you pick depends on your situation. In some ways you can think of these as before and after your kids move out.
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.
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.
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).
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.
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.
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.
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?
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.
At my job, there are three levels above "senior" and senior is the lowest we typically hire. So the ridiculous irony is that "senior" here means noob. :D
> 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.
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.
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.
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.
[deleted]
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.
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.
Probably higher than his salary.
I think that was the assumption here, but ignore stock changes over 10 years. People hired 2-3 years ago were hired on a "high" and their total compensation this year likely is not as great.
(For some definition of Great, it's still way beyond the average for $population)
(For some definition of Great, it's still way beyond the average for $population)
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!
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
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.
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?
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.
[deleted]
> 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.
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.
Depends on the organisation, at my last job you could become a senior IC (which does not have any management or mentoring requirements) or you could become a ‘lead’ which is expected to coach the others in the team.
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.
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