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
[ 3.0 ms ] story [ 187 ms ] threadLogically 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.
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.
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.
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.
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
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/
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
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.
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.
* 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.
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.
Just working with adding features to decent existing code is all I ask.
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.
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?
> 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.
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?
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
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.
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?
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.
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?
Many startups are like this.
They're typically picky about letting new people in.
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
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
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.
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.
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
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.
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.
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.
"Hey, there seem to be a lot of juniors. How do you want me to approach this?"
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.
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.
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.
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.
It might yield something new. Perhaps more focus on getting things done rather than getting things.
I used to find it frustrating to have a team full of greenhorns but changed my tune quickly.
In the end it was great but an entirely different role than what it said on the tin.> Startups and consulting gigs probably better align with wanting to be hands on
Also tracks.
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.
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
I have no experience at all with these companies, but isn't this one of the main reasons they hire someone like you?
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.
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
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.
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.
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.)
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.
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.)
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.
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.
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
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.