THEY'RE TOO SLOW! - How Long Should It Take Junior Devs?

THEY'RE TOO SLOW! - How Long Should It Take Junior Devs?

• 2,418 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware developerssoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinovlogging lifevlog lifeengineering managermanagerleadershipmsftsoftware engineering managercareer switchrole changecareer changetechtech job

So just how long should it take a junior dev to ramp up?

You guessed it -- it depends.

Here are my thoughts on things that affect ramp-up time for juniors.

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

what is up I got to plug this camera in I can't see a thing um it's still Monday it is kind of late I'm leaving work a little later than normal um I'm just staying for a meeting after work it's freezing in here I'm in this damn X1 courtesy shuttle got a topic though um this is a good one that was submitted um and it's going to be about time for juniors to ramp up so um I've seen people talk about this stuff on social media different perspectives and stuff so I'll share mine and this is just a reminder to this is a submitted question so um if you're wondering about stuff in software engineering whether that's technical things a career related whatever it happens to be feel free to leave a comment about it um if you wanted to be anonymous I do get

anonymous questions coming in kind of hard to do that with a comment so just uh find me on social media look for Dev leader on basically any platform you want uh literally I'm on Tumblr and Pinterest I'm everywhere I try to be everywhere I don't have Snapchat I don't have Snapchat but everywhere else um look for Dev leader feel free to send me an anonymous or it's not going to be anonymous but I mean send me the message let me know want it to be anonymous and I'm happy to go over it um for background if you've never seen any of my stuff before so I have a channel called Dev leader on YouTube it's uh it's bigger than this one currently for now um but I I'm a software engineering manager at Microsoft I've been at Microsoft for about about four and a half

years now and prior to that I was at a digital forensics software company that was a startup That Grew into a uh pretty big company now not Microsoft size or anything like that but they uh they ipoed after I left unfortunately I mean good for them uh and then they got bought back to private for $2 billion so they did pretty well um so I do have experience in startups and big Tech so the question about how long it takes Juniors to ramp up and then additionally um the sort of follow-up extension of the question was like as a as a leader and I'll dive into this more as a leader like what can be done to sort of motivate uh juniors in their rampup process and I want to stress as I go through this like I'm got to be talking about this from

you know my perspective as an engineering manager but um leaders are not you know constrained to just managers uh truly anyone can be a leader it's uh just you know the actions we take and uh you know the the characteristics that we embody so uh I don't want to talk about this stuff and you're like well that's nice but like I am not a manager U no that's uh that's nonsense I I literally talked about this recently and wrote and did a live stream on like or is that live stream that's tonight that tonight I can't remember I can't remember what tonight's live stream is anyway um sorry I'm I'm losing my mind but uh I at least wrote about it uh and that's that Juniors can lead right so um I think that was last week's anyway um you know you don't have to

have a certain title anyone can do it it just looks different depending on your level of experience and your environment and stuff like that so okay how long does it take Juniors to ramp up well the answer is that it depends but that's the answer you knew was coming already because this is software engineer Ing and everything is it depends but let's try and uh qualify that a little bit and maybe try to quantify a little bit if we can too so to start off uh cuz I want to just give you a bunch of different perspectives cuz I think we got what's it look like a 50-minute drive home um we'll start with startups um and I'll add in a little bit of uh context for my background so when I was at a startup That Grew into this the you know midsize company

that was in person that was before the whole lockdown era and then when I moved to Microsoft that was actually during uh lockdown sort of period so everything I went from being in person everything to basically remote and kind of like hybrid now cuz I go into the office some days so that's going to have an effect here and I want to make sure that I call that out early because it will bias some of my uh things that I'm talking about here so at startup companies uh I think there's an expectation that people are basically hitting the ground running super fast and that's for a couple of reasons and I think one of the primary ones is that at startup companies startups don't have as much of like a safety net when it comes to hiring people and stuff like that sorry I got

to switch lanes here and I can't think in switch lanes apparently um cuz this X1 is absolute trash startups don't have the luxury of uh of taking big risks right everything is like we got to fight to stay alive we got to fight to survive so when they're bringing on people generally going through interview processes and stuff they're looking for people that can they can start right away that they can be productive right away and that's because they don't have resources or time to be able to train people for months and months and months and months to finally hopefully be productive because again every I talked about this earlier today on the drive in to work but like hiring people can be risky and it's risky because like interview processes aren't perfect yes we should constantly try to refine them we should make them more

uh you know accurate for the person who's being tested we want to still make sure we're testing people um for the right things so that they're a good fit when they join but it feels like you know there's still a long way to go for a lot of companies to get that right and I'm not saying that I've seen it done perfectly not by any means but uh I think a lot of room to improve there so hiring people is risky startups need people to get going fast they just need it so they they're either inexperienced startups trying to hire people and they're rushing through it you know we'll take anyone for the right you know pay and we'll just try to make it work and that's like that's super risky other other startups I think with a bit more um I don't know what

the right word is I don't want to say smarter startups that's not fair um careful ones that aren't trying to rush have a bit more understanding of what's going on will do it more slowly and it's painful because sometimes at a startup you're like man we really need someone we really need someone but it's so much worse to bring someone on that's not a good fit try to spend time ramping them up and then be like nah this is not going to work so you really want to make sure you get it right so this is a very long-winded way I do this a lot if you haven't noticed uh of saying that startups have this expectation that their juniors are getting ramped up fast now you're probably wondering then okay well what does fast mean um again this is going to be a depends

on a lot of things um and to add some context here like let's think about what products and services are actually being built because if someone said well I don't know like in terms of shipping actual changes like depending on what you're building you might not even see things shipped for a while and that's because your release cycle is slower or something like that so then you might want to try and quantify it or qualify it a different way which is maybe like I don't know like how fast until you get your first pull request in get your first code review done until you've committed things to the mainline code well I mean this is hard to answer too because I've seen people that it's like as soon as your environment set up which you could potentially do in an hour or a couple of

hours maybe it takes you a day or two whatever but as soon as that's up someone might walk you through doing your first pull request and that's quick too like that takes an hour for you to kind of get code checked in and you know you do like a change a log line or something and great now you see how the tooling works so like that's also not really probably a fair way to answer getting ramped up so how do we want to qualify this I think it's probably like some amount of for a junior some amount of being able to work on changes where they can submit code yes they're going to need some guidance but kind of getting into this rhythm of like okay I can pick up uh some work to do and and make progress on it asking questions of course

it's going to be coming up but at least starting to feel like they're getting some momentum with it that's probably how I would like to look at things but I realized that's like a really I don't know like convoluted thing to try and measure cuz like that that's going to feel different for different people so my expectation like at a startup would be that this is probably going to take someone till they're building some amount of comfort I would say like within a month I would probably have that expectation the first week is going to be just getting familiar and trying to learn things second and third week is probably going to be you getting um you know some amount of exposure to like okay you're getting a poll request up you're getting feedback you're seeing how like The Styling and stuff works what the

team thinks about certain patterns all this kind of stuff you're still feeling out the product the service like still lots to learn obviously but I would say by the end of the first month at a startup ideally trying to get a little bit of comfort in the rhythm of things now again like you might be like oh crap like that's taken me months it's been 3 months and I still feel kind of weird I mean sure I'm not saying that it's bad I'm not saying that's wrong but I think that at a startup like I would probably hope to see someone getting that Rhythm after about a month if they can do it faster we put them on a project that's more straightforward they can do it within a week it's like cool I'm making small bug fixes I can start pushing up code for

features like great these are all awesome things but truthfully in about a month I would probably have that that hope that someone's able to do that um but what are things that can influence this right I want to talk about this before I switch over to like the big Tech perspective I also want to switch lanes here can I do this the answer is yes one more to go the problem is I have to get into this fast lane and this car is like oh you hear that yeah it's a machine all two cylinders this is a lawnmower um this is awful uh it's painful to drive this thing but anyway some factors that can influence that I think having like a really good onboarding buddy so if you're at a company and you're bringing on especially Juniors but really anyone to the team right

like having someone I know you might be like more senior you're like I don't need an onboarding buddy like that's so dumb seriously having someone that can give you some guidance when you're just new to a team regardless of your level can be really helpful because there's so many things that you just should not have to spend time trying to sort out right you don't know where resources are you're having weird build issues build issues you might want to spend a little bit of time trying to debug just so you're like getting exposed to things but man like having someone sit around for like a week on build issues like no thanks we got better things to do especially at a startup um so onboarding buddy I think that's critical um it's also about if you're curious about this like it's a good opportunity for

helping people with um a little bit of leadership and mentorship because you can take someone again doesn't matter if they're Junior 2 but you can look for people that are interested in this or need this to kind of help round out some some skills or things that they should need to focus on for their next level and and getting them to help be someone's onboarding buddy helps everyone out and you can really make it a positive experience for both people participating in it so I do highly recommend that um but I think that that can dramatically uh reduce the amount of time until someone's feeling productive so um I wanted to see I want to I want to see if there's a better way that I can explain like that ramp up time too cuz again like even throwing one month out there I'm like

yeah but that's going to depend on so much too um I would say maybe this is some extra context to add if you're a month into things at a startup and you're like I don't even know what our product does or I have no idea a who to even talk to about things I would say like those are the the things that I would want you to go address before a month right like you should know you don't have to know everything about your product or service but you should know what's up with it you should have an idea of like what it's doing and I assume the team isn't so big that you haven't met the people on the team and have some idea where they're focused and this is another reason why having an onb boing buddy my God traffic this person's just

not even driving um having an onboarding buddy can really help with that because they might have their areas of expertise and they can tell you who else on the team does and kind of get you steered right so if you don't have an onboarding buddy you can imagine that this kind of stuff can take a lot longer right so at a really small company so say there's like one other developer and they're busy and you just join this company and this second Dev and and you're like okay like how do I know like where anything is and it's like that person's not helping you on board it's going to take a lot longer without a doubt so it's kind of weird right like the environment that you're put into can make a dramatic difference okay so it's roughly kind of what I'm thinking for startups

please I know there's going to be at least someone who hears everything I just said and they're like that's bul crap like it's either way faster way slower I mean okay you try you try quantifying it go ahead um that's my opinion now I want to talk about big Tech at least my experience so far and I want to talk about this remote thing as well and I still have to get through like ways to encourage people because I think that was a big part of uh you know as Leaders what can we do to to help and I oh my God buddy just get get out of this Lane get out of it you're literally stupid this person's driving in two lanes with their signal on like my God just get out okay um the thing I wanted to to bring up before this

absolute idiot um was doing what he was doing is let's talk about the remote side of things a little bit because I think this is applicable to both startups and big Tech big companies whatever um because there's going to be startups that are fully remote and there's going to be startups in person there's big Tech where there's a lot of in person and there's big Tech that's remote so my experience has been that onboarding people that are fully remote is statistically significantly slower like a lot slower and it's not for every single person but I think for the majority of people and I even feel like this includes me I feel like I am included in this in terms of being slower I feel like it's a lot slower um and that's for a handful of different reasons but part of it is that there's

this layer of like isolation that gets put in sorry I'm like I got a burp or something I'm getting like heartburn out of nowhere um I haven't had too much to eat today but there's this layer of isolation that I think ends up slowing people down and I think it really depends on your personality type and how you interact but if you are someone who's maybe more introverted like I'm naturally more introverted I feel like I'm more quiet um if you're this kind of way you may find that like you have a really difficult time reaching out to people asking for help getting unblocked and I am this way I am very much this way so I'm not trying to describe other people and saying like oh they're bad that's why they're onboarding slow I think it's just part of like you know a lot

of it is like personality type and the environment that you're put into this way so I've also noticed too as some one you know managing teams that it's almost like it does literally doesn't matter how many times you say please ask for help if you're feeling blocked on anything I've tried so many different ways to explain this trying to let people know you're never going to bother other people on the team they want to help you I've had those people tell the new hires that they want to help it's like it doesn't matter how much I put into it uh there are certain personality types and I'm grouping them as person personality types cuz I don't know the answer here that um that have a really difficult time reaching out and they struggle to on board they just go so much slower and that's something

that I I'm really trying to pay attention to because there are also other people that are the exact opposite where they're like I recognize that I am isolated and that means I have to go sort of like above and beyond to reach out frequently uh like over communicate on things and they like they compensate in all the right ways and then they're able to you know ask questions all the time because they do get it like yeah everyone does want to help like I'm not going to hold back and then they onboard very effectively so I don't know what the answer is here but I wanted to mention that I have found that remote onboarding can be very very difficult um maybe I'll sprinkle a few of these in so I don't just have like a how can we make this better all at the

end but uh I think something that helps here is if there is the opportunity for some amount of inperson onsite like even just getting to meet team members in person can make such a big difference um and you might think like oh that's again maybe it sounds like bull crap like what is that actually going to change I seen multiple times now where uh not even just for me interacting with others but how I've seen teammates of mine meet each other for the first time and what ends up happening is like when you're working remotely doesn't matter if it's video calls or whatever but if you're working remotely we seem to kind of create this like persona for other people I guess and I think everyone does this to some degree but what happens is when you meet people in person like you kind of

crush whatever imaginary Persona you made up for other people and I have not seen it be a negative thing it's every single time it's been very very positive where people are like oh this person actually really does want to help they are actually super nice they are actually very inviting I got to see it first hand now I know then they go back to working remotely and they have this like renewed like feeling of like hey like I can reach out to so and so so I do highly recommend this I don't have like data to back this up you're literally listening to a dude stuck in traffic in a courtesy shuttle rant about software engineering so something I recommend for sure um but yeah it's like you have to think about onboarding resources and stuff to make accessible for people that are remote Because

unless you're carving out tons of meetings and stuff like I don't know there's there's this feeling of being in an office and like people can tell when you're stuck on stuff or you can easily turn to someone and be like hey man like I'm stuck on this I can't find uh you know that resource for setting up my machine or I have codes not building you just have a look at this quick I feel like so many of those little things really helps speed people up so that's probably the the Spiel on remote versus in person but let's talk about big Tech so again my big Tech experience has been remote for onboarding um for basically every new person I've brought on for myself across two teams uh it's it's all been remote or like the overwhelming majority has been remote even if there is

some hybrid overwhelming is remote and and um so I have noticed that it's slower um but the other thing that I wanted to call out is that I I find and you could you could observe this at startups too so I'm not saying it's impossible but I feel like startups are everything's like go go go fast fast fast and big Tech is slower it's slower things generally move slower again someone's going to listen to this and say that's just not true yes there are teams in big Tech that move very fast they are very Nimble it's it's a real thing uh cop just did a u-turn on the highway and is chasing someone down what's up with that so again I'm trying to generalize here and I realize that when I make generalizations someone's going to disagree that's okay but if in general things are

moving slower in big Tech that also means your ramp up is like going to go slower um to give you an example when I was trying to quantify and qualify a little bit earlier about getting your PLL requests in seeing changes get deployed I literally worked on a deployment team before my current team and we literally have things in place on purpose to slow down how changes roll out across machines in the world so it might take you significantly longer to finish one thing than anywhere else uh and not because your change was so complicated but you're not going to get the full end to-end development life cycle experience until it's done all the way and that could take a lot longer than you might expect I'm not going to get into details about it but it's on purpose so does that mean that like

you can't do other stuff at the same time no you're going to be doing other stuff at at the same time because while your changes are rolling out it's not like you just sit at your desk and say well I got to keep hitting refresh and looking for for problems no you're going to start on the next thing right and then you might have to Conta switch because you did catch an issue with your change rolling it whatever it happens to be but I think because there is this slower moving process generally at least where I am uh maybe other companies have much faster end to end like deployment cycles and stuff like that totally fine but I've noticed takes longer uh for ramp up but the other thing I wanted to call out too is that this is was going on a bit of

a tangent there but that it can happen at startups when you have people that are really experienced okay um so what's a good word for them uh like a historian so someone's a historian on the team because they've been around for a long time they know how everything works and if they don't know they could spend the shortest amount of time compared to anyone else on the team debug it figure it out like these are the historians they know what's up one of the challenges is that like when you have historians like this if they're always stepping in to fight fires right if they're always stepping in to do stuff then like some of this experience does not get shared actively with other team members now as a manager and back to this idea of leaders and stuff right like something that we can do

is try to recommend that even when there are fires that need to be put out like yeah you might want to have someone who's the absolute expert go fix it but try to bring along someone that's newer try to bring them along so they can see what's up so they can get the exposure because if you don't it propagates this problem that like you're going to keep having these historians or these experts in these areas keep being the only person that can look at this stuff and I actually feel like that perpetuated some of the onboarding time uh for the teams that I've been on whereas at a startup it was like you don't got a choice man like stuff's broken you got to go look these features have to get finished there's a tight deadline you got to go do it someone's got to

do it it's got to get done right again you might be hearing that and going oh that sounds like a crappy startup I don't want be there but like this is pretty typical startup life so I think that the nature of how we work in startups versus big Tech changes the expectation around rampup time so um in big Tech I was when I was hired on my first manager at Microsoft said to me and I mean I'm at a manager level I at principal level so I'm not a junior at a tech company but he said for me in my role he said I would expect it takes you a year to be comfortable in your role a full 12 months to be comfortable and was he right I mean like I don't think he was too far off I don't know when it happened

but I think like in my second year was when I I started to feel confident about things I was talking about so it did take quite a long time um does that mean that I wasn't doing anything for the first year no like was still getting stuff done but like in terms of building confidence it took me a long time and if I reflect on you know uh especially Juniors that I've had on teams um I feel like they've been able to be relatively quickly slower than what I would say at startups by by weeks slower um able to kind of make progress getting features and stuff delivered and I'm not don't take that the wrong way I'm not saying oh it's because they're worse at onboarding or they're not smart or anything like that nothing of the sort right I'm actually attributing a lot

of it to like the environment so please don't interpret that as I'm saying oh I I only had dumb people on my teams or something not nothing like that brilliant people um but getting them ramped up to that same level definitely like weeks longer at a minimum and again I think the people that really were shining through in terms of rampup time were the ones that were like hey look like it's a huge company there's tons of stuff going on like instead of just sitting back and being overwhelmed by it they were just jumping in and being like cool huge company I don't know who to talk to hey can anyone tell me who the right team is for this who can I reach out to hey like hey whoever is listening on our team in our team chat I'm seeing this issue when I

go to build can someone help me like ra away kind of thing just getting themselves unblocked I got to pass this guy cuz this is getting like dangerously slow um they're going below the speed limit in the fast lane like an absolute tool bag um so slower yes but I think for for good reason um and it's kind of like the environment they're in but the people that seem to excel are are always the ones that are unblocking themselves they're being very active about unblocking themselves so um I kind of gave that 12mon marker for myself to be productive um truly that's what it felt like again context a lot of Legacy code in the area I was working in uh like almost a completely new team I had a couple of people that were more senior but almost a completely new team working for

me um actually what's interesting too is like just for context when I switched teams so I switched teams earlier this year I felt I felt confident a few months in it probably took me about 4 months to feel confident so that's some some contrast I want to offer is like yeah 12 months new and this is in the same area of Microsoft but at a different team just for context so when I have new hires come on oh says it's cold thank you for the warning that it's cold I am well aware um I probably expect a couple months there's some people that I get on projects right away that are smaller more scoped and they happen to be very proactive and stuff and you know within weeks they're doing great right they're I I trust that they know how to iterate they're asking questions

and stuff great great great okay cool uh other people again I'm not blaming them they might be working in a more ambiguous area uh and their personality type is they're not reaching out as much and that could be 1 month could be 2 3 months before they start hitting their stride so um definitely longer in big Tech is what I've been noticing um but it's not because like the caliber of people or something is off so now what can we do what can we do to try and encourage people um number one is I've already said it but like that remote remote work thing finding ways to to truly get people to believe that they can reach out for help they it's an expectation that they should be asking for help to get unblocked finding ways to build that into the culture maybe you have

onboarding buddies or more Senior People actively doing some of that work reaching out to the new hire and saying hey like let's just get on a call and go through stuff like kind of almost like a forcing function to get them to talk that's something I noticed with some of the interns and we had over the years was like at at Microsoft um it's like oh no like not blocked not blocked and then you would just like get on a call with them and they're like actually like I need help with this and it's like oh well how long you been working on well it's been a couple days and I'm like well sounds like you're BL on that like you've been looking you've been staring at your screen for a few days now unable to make progress you're blocked on it that's okay like

no one's going to be mad at you for for not knowing the answer but like we need to know if you're stuck so creating a forcing function that actually gets people on to calls or to you know to walk through things so that they they feel comfortable they can I think is super helpful but it takes a little bit of of uh proving you need to build some momentum with it so they know and they believe that it's real so they can reach out for help I think that's one I talked about the onboarding Buddy thing I cannot recommend that enough uh definitely try to set up onboarding buddies um I think clear expectations right um personally I don't think it's necessarily fair for me to just have like a blanket statement for people that start working for me to be like I expect within

X number weeks that you're productive because like I was kind of hinting at I think that's going to happen on a case-by casee basis um terms of the project they're working on and stuff in terms of the complexity all these things uh sometimes uh again for context in big Tech we might hire people um I I said at startups it's like kind of want to get people that can hit the ground running at in Microsoft I think out of the two teams I've been on when had people hired around the same time I started think I've had one maybe two people that actively programmed in C prior so that's another Factor here I kind of glossed over it so I apologize but um some of these people don't even know the programming language they're using yes that's going to take them longer and we can

do that in big Tech because we have the resources to be able to do it if it's great if they already know the language of course but I already just explained we clearly were not hiring people just because they know C because you don't need to they have other software development experiences they're going to learn CP will help them learn I used to run weekly learning sessions for c for people on my team and all levels were invited right like just help people on forward get them get them learning they're going to be working in code they're going to learn it it's fine but that will prolong um how long it takes to get comfortable as you might expect so um yeah definitely creating learning resources for people uh like I said in this example don't don't know the language cool we'll do some type

of learning sessions where people can get that opportunity um what else I think I was I might have switched gears too fast on myself there but I don't like telling people expect to be ramped up this fast I wanted to go back to this thought um I think something I've learned is that I for myself at least and maybe this is still helpful for you to understand for you is I've been pretty lenient on people's initial ramp up tasks in terms of time I'm like look they're just learning I don't want to rush them I don't want to create like an artificial pressure kind of thing but I think sometimes this backfires for me and it's actually helpful and they would appreciate it if I gave them some idea of like let's time box this right like here's your first work item I actually expect

that you have this up for code review by the end of the week not because it's the most critical thing and like the world's going to fall apart if you don't get it done but I'm setting like some idea for you so you know if you're like getting close to the end of the week and you're like oh man I've been stuck on this stuff like yeah it might be a a good sign that we got to shift gears a little bit S I got to back this thing up it's just awful okay um oh my God look at this TT who's whose car is that wow I like my TT I miss it um what was I saying I don't even know what I was saying now um it's been a long day I'm my wrap it up there I got to get on

this live stream soon and I got to figure out what I'm talking about so um overall ramp up times are going to vary significantly for people your environment's going to make a big difference um I think being trying to be clear about expectations in terms of time boxing things making sure people know they can ask for help these are all critical but trying to say like you better expect in like a week two weeks a month whatever that you should be productive it's just going to be very Case by case I think so um I hope that helps I don't know if that's exactly the guidance someone was looking for on this but those are my opinions on it and uh if you're someone who is on boarding um I I mean it seriously like you're not even on my team and I want you

to know that literally your team wants to be able to help you because the sooner that you are productive in doing stuff the sooner they get help like even selfishly if they're being selfish they want to help you because it's going to help them when you're productive so please keep that in mind reach out when you're blocked um I I don't have a better way to say that to people I just I really want you to believe it um you'll notice if you start asking for help you start getting unblocked your momentum your pacing will absolutely pick up and I hope if there's any if you stuck around this long I hope if there's anything that you listen to on this if you take that to heart and you start doing it and you go oh like yeah I am feeling more productive I hope

that you remember this moment and I hope that it rang true come back and leave a comment if that's the case otherwise I'll see you next time take care

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

How long does it typically take junior developers to ramp up at startup companies?
At startups, I generally expect junior developers to build some comfort and start contributing within about a month. The first week is usually spent getting familiar with the environment, and by the second and third weeks, they should be submitting pull requests and getting feedback. Having an onboarding buddy can significantly speed up this process by helping new hires navigate resources and build momentum.
Why is onboarding junior developers slower in big tech companies compared to startups?
In big tech, onboarding tends to be slower because processes and deployments move at a slower pace by design, often to ensure quality and stability. It can take several months to a year to feel fully comfortable in a role due to the complexity and size of the organization. Additionally, remote onboarding adds challenges such as isolation and difficulty reaching out for help, which can further slow ramp-up time.
What strategies can leaders use to help junior developers ramp up more effectively?
I recommend setting up onboarding buddies who can guide new hires through the initial period and help them get unblocked quickly. Encouraging a culture where juniors feel comfortable asking for help is critical, especially in remote environments, so creating forcing functions like scheduled check-ins or calls can help. Also, setting clear expectations and understanding that ramp-up time varies depending on the project and individual circumstances is important.