How to develop new developers early in their career working remotely
Posted by Dull-Click-7283@reddit | ExperiencedDevs | View on Reddit | 137 comments
I manage a small staff of developers for a small consulting firm. I feel like as a company we are failing our fresher devs in developing their skills and I am looking for better ways/ideas. We are 100% remote. I feel like our Jr and above level devs do fine, but we really struggle with the freshers. My theory is all the Jr and above started their careers working in an office where they could work with someone on a daily basis. When we onboard, we do some initial remote sessions for peer coding, then tell them to reach out if they get stuck/have questions. If we don't hear from them in a day or couple days asking for help/review we then reach out to them, but it just does not seem to work. The skills you develop early in your career are very formative for the rest of your career and I feel like we are doing them a disservice more than I worry about their utilization numbers/profitability for the most part. I am curious if any one has had successful experiences doing this and tips and tricks I can use!
Efficient_Builder923@reddit
Give them clear tasks and goals to start with. Use tools like Zoom and Slack to stay connected and answer questions quickly. Pair programming and regular feedback can help them learn faster!
ezaquarii_com@reddit
Ok, so you have identified the problem: they get onboarding and are pretty much abandoned after that. Stop doing that.
Generally, if you don't see constant conflict between fresher spewing garbage and seniors pushing back - there is no upskilling. "No pain - no gain" gym rule applies equally.
Western_Objective209@reddit
I've seen polls on social media about whether someone received any mentoring when they started a new job. Something like 95% of devs responded that they have never had any mentoring.
My in office experience was I had a senior dev show me a project that he was handing off to me, gave me about a month where I could ask questions, and then he was too busy and I had to figure stuff out on my own.
I think my experience is not particularly uncommon
ultraDross@reddit
This has been mine too. I didn't even get a month. Basically just get shit done and ask if you need help. I was a junior in office too, so that didn't help. Second job (still a junior as I left the first after a few months) was a remote where the seniors were in a very different time zone to myself.
It was very sink or swim. This seems like the norm. For context, this was 6 years ago. I've worked in other industries before and the way we "train" staff in software development is pretty insane compared to pretty much any other industry.
samelaaaa@reddit
As someone who’s been fully remote for almost a decade now, I agree that this is the biggest issue with distributed teams.
I don’t have a solution. I think it’s not just about remote work though, it’s all wrapped up in the changing economics of running software teams. Training freshers to become net positive SWEs makes zero sense for a company to do, because it’s a huge tax on seniors’ time that could be spent actually delivering value for the company. There is no benefit, because as soon as the juniors are net positive they can command market rate, either at your company or more often someone else’s.
The remote vs office-based dynamics just make this more extreme. Training juniors is more efficient in office, but it costs a lot more to get an equivalently skilled senior to live near the office, come in daily and do that work. So unless you’re a massive company (maybe even then but those economics get more complex) the obvious thing to do is just hire experienced people to work on a distributed team and let other companies handle training.
charging_chinchilla@reddit
Remote is definitely a barrier to onboarding. People who pretend it isn't or that it can be overcome easily by "mentors" or better onboarding docs or whatever are generally not arguing in good faith.
I think it takes a certain amount of personal motivation from a remote employee to make it work. Similar to how during Covid, some kids did fine but others just muted their cameras/mics and goofed off all day. Some employees are self driven and curious enough that they will reach out with questions, dig into things on their own, and make connections with their coworkers so they know who they can reach out to. Remote onboarding works fine for those employees.
Western_Objective209@reddit
Most people get almost no onboarding in the office.
Norphesius@reddit
Its absolutely possible to get terrible, nonexistent onboarding while in office, but its easier for knowledge transfer to happen when you're stuck in a room with your team for 8 hours a day.
Western_Objective209@reddit
IDK when I see KT done in person it's almost always a disaster because people don't take very good notes. If the KT is done with documentation I've never seen it go poorly
charging_chinchilla@reddit
I think you are greatly underestimating how much onboarding happens organically in person. Coworkers talk to each other and help each other out, they overhear conversations and chime in, they spot when someone is getting visibly frustrated, etc. That's all part of onboarding and those interactions are what build relationships and help with knowledge sharing.
Western_Objective209@reddit
idk I just haven't seen it. I've worked half my career in office and half remote, and I have not seen people just getting visibly frustrated and then others fall over themselves to help, that just seems like something a C-suite thinks happens in offices
epelle9@reddit
What weird company culture, is all of the US this way?
In all the in person jobs I’ve had, people helped each other, socialize, laugh, etc.
Maybe a few times use earphones when no-one is talking, but people definitely have casual conversation, and don’t hesitate to ask for or give advice whenever they feel it would be helpful to do so.
Western_Objective209@reddit
So the majority of the time people are just socializing and only a few times people need to concentrate on actually doing work?
epelle9@reddit
Did I say the majority of time?
Western_Objective209@reddit
You made it sound like people focusing on their work was rare and that socializing was the norm. If that's not what you were saying, idk know what your criticism even is because I just said the majority of the time people concentrate on their work rather then socialize or help others
dub-dub-dub@reddit
do... do you not eat lunch?
Western_Objective209@reddit
Is it not obvious I was talking about work and not breaks?
dub-dub-dub@reddit
People don't eat lunch together when they work remotely. They do when they work "in person" as the comment you replied to characterized in-office work. What exactly is unclear here?
neuroDawn@reddit
I can’t get anyone to do lunch at work. F500 1200+ people on campus
vazura@reddit
You think anything is being done productive during lunch? Anytime I was in an office and went out to lunch with everyone we talked about nothing related to work.
dub-dub-dub@reddit
I have never known a new grad or intern to not ask questions during lunch or casually in the office.
thedifferenceisnt@reddit
Or casually on slack were they can get a written response with references.
dub-dub-dub@reddit
What’s your point? They could also pen me a letter with their question. Does that mean we should shut down slack?
Does the existence of one channel through which you can get help eliminate the value of all other potential channels?
vazura@reddit
Working remote is identical. Shoot a message in slack to the right channel. If it's something more technical just start call or schedule one. The tools are there for someone to utilize.
JeffMurdock_@reddit
Right, and the simple fact is that some people don’t utilize those tools to the fullest extent. If you’re having lunch together, you’re already face to face and the person you’re seeking advice from is actively not engaged in work. These are two barriers that exist in Slack, but don’t do in real life.
Western_Objective209@reddit
It's like 50/50 people eat together in office at best. A lot of people just eat at their desks, or eat alone. With that said, are you implying that all of these benefits are conferred through the act of eating lunch together?
TangerineSorry8463@reddit
I vowed to myself that when a new guy comes in, I'm going to give them the sort of onboarding I would have wanted to have.
thedifferenceisnt@reddit
How is it that they're arguing in bad faith exactly?
You go to the office and can chat with other devs sure. 90% of the time they're working or in meetings with headphones on.
Being in the office changes little here. It's more social and you can break the ice more easily but pairing on tasks works better in remote more often than looking over someone's shoulder.
charging_chinchilla@reddit
Remote work adds friction. Checking whether people are online, getting them into a VC, sharing your screen, "can you hear me?", etc. This is all stuff that gets in the way of getting help or a quick set of eyes on something.
When I say arguing in bad faith, I mean that people defending remote work are generally doing so because it's cushy and they don't want to give up that comfort. The things that are sacrificed are things that don't matter to them personally, but do to the business (e.g. I don't get bothered by the new hires for help anymore so I can focus on my stuff = great for me but not so great for the newbie).
thedifferenceisnt@reddit
Now this is a bad faith argument.
Can you hear me? Seriously?
How about cutting hours out of people's daily lives so corporate can prop up shitty real estate investments?
epelle9@reddit
Its often arguing in bad faith because while the reason they are arguing is because they save hours of commute and are more confortable, the arguments they give often talk about everyone being more productive and having less friction, without recognizing the areas where it does add friction.
Obviously not everyone argues in bad faith, and there are tons of arguments for remote work, but it often happens that those that argue against RTO fail to recognize any type of benefit whatsoever.
It sucks to be in office if you’re someone that works better from home or has a long commute, but that doesn’t mean that there are absolutely no benefits from in office work.
PragmaticBoredom@reddit
The issue I’ve found is that many of them know they can coast for a year or two and then jump for market rate before really maturing into the role. For someone who isn’t performing (and maybe has no desire to try) it’s easier to convince a new company to hire you into a more senior role when they don’t know any details of your work.
Sadly, this is becoming a celebrated strategy in some online forums, including /r/cscareerquestions and a lot of the career advice discords. They don’t say it directly, of course, but they celebrate a strategy of doing the bare minimum and then frequently job hopping for raises.
It’s been going on long enough that the mentoring group I’ve been mentoring in is starting to see boomerang alumni come back for advice on it. They spend the first 5-7 years of their career changing jobs every 12 months while dodging responsibility at each job. Then suddenly they have a “1 year of experience 7 different times” resume, no positive references from past managers, and they can’t get a job in this difficult market.
The insane job market of recent years really covered up a lot of people’s bad career development habits because anyone could get a job at any time. Now that the music has stopped, skills, references, and experiences suddenly matter again and a lot of people are caught out cold.
________ballz_______@reddit
Yes. Hiring juniors is a bad strategy. Hiring them remotely? Terrible. Just don’t hire them. Replace every 4 junior hires with a single mid/senior and enjoy the 10x throughout
JoeBidensLongFart@reddit
People will do what they're incentivized to do.
PragmaticBoredom@reddit
Some people will take short term incentives at the expense of long term career growth, then suffer the consequences 5-10 years later and complain about “the industry”
witchcapture@reddit
I swear, /r/cscareerquestions is an absolute scourge on this industry. Tragedy of the commons and all, I suppose.
sneakpeekbot@reddit
Here's a sneak peek of /r/cscareerquestions using the top posts of the year!
#1: Berkeley Computer Science professor says even his 4.0 GPA students are getting zero job offers, says job market is possibly irreversible
#2: [6 Month Update] Buddy of mine COMPLETELY lied in his job search and he ended up getting tons of inter views and almost tripling his salary ($85k -> $230k)
#3: Home Depot software devs to start having to spend 1 day per quarter working a full day in a retail store
^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^Contact ^^| ^^Info ^^| ^^Opt-out ^^| ^^GitHub
TangerineSorry8463@reddit
I don't support doing *the bare minimum*, but if you're giving me 3% raises when a job gives me a 30% raise, then it's on you.
Izacus@reddit
Sure, but then also don't come around whining that companies aren't spending senior engineering time, wages and other resources training you up when all they get from that is financial loss. Why burn money to train you up if there's no reciprocation? It's just easier to hire and skip all the timewaste then.
TangerineSorry8463@reddit
If they aren't spending money on my development, then that's even more reason to not stick with them
Izacus@reddit
Now you're just being deliberately obtuse and refusing to think.
TangerineSorry8463@reddit
Tell me where you work so I can avoid it.
Izacus@reddit
In places you want to work in. Im sorry if the reality of the market makes you all mad, but downvotes won't change how the market and businesses work no matter how much you insult me or smash that downvote button.
TangerineSorry8463@reddit
Given a clear question, Izacus gives a meandering condescending response.
Clearly staff engineer material!
Izacus@reddit
Thank you, others thought so too :D
PragmaticBoredom@reddit
The point I was making was that a job hop would grant that 30% raise even if you did the bare minimum. A lot of people noticed that and took the opportunity to do the bare minimum.
That strategy worked when the job market favored candidates. It came to an abrupt halt when the job market tightened and suddenly experience and knowledge mattered again.
Dx2TT@reddit
Yep. The problem is that "office culture" only works if everyone on the team is there are you can actually look at code and discuss things in person. If you go to an office to be on a video call all day its just as pointless.
The overemployed/remotework crowd just pretend that this problem doesn't exist, but being a junior and learning now is damn near impossible. Over the past 4ish years I can definitely say that all of juniors are just as shitty as they were 4 years ago and we have no idea how to solve it, primarily because they just don't care.
Western_Objective209@reddit
I've onboarded several juniors fully remote, and it just is not that hard. You tell them to ping you whenever they have issues, you do screenshares, give them small tasks that they should be able to solve, and answer questions in a timely manner.
When I first started, I had about a month of 1 on 1 time with a senior, and then they were too busy and I had to figure stuff out on my own. This was in office. I give more time to juniors remote then I ever got in the office
PragmaticBoredom@reddit
This works for great juniors. If you got those, you're lucky.
It's a wide spectrum, though. Telling juniors to ping you when they have issues will cause a large fraction of new grads to just shut down. They'll wait until tomorrow, wait until a scheduled 1:1, or just spin on the problem for 3 days because they're afraid to admit they're stuck.
This is why it's important to set tight boundaries and communicate expectations very clearly. With juniors, you might have to repeat those expectations and make it crystal clear when they're not being met. This part can be really hard for people who don't like difficult conversations, which is why we avoid putting juniors on teams that don't have strong, direct, and clear leadership
Radrezzz@reddit
But the same problems happen in office! And it still costs senior time to meet with and develop juniors either way. Remote screen share is superior to sitting next to each other on the same computer. We can easily shift back and forth between the information the senior has and where the junior is in solving the problem.
PragmaticBoredom@reddit
I say this as someone who is very pro-remote: The same problems are worse when remote. Remote does something to the lazy juniors that makes them think nobody is watching and therefore they can get away with more. They don’t pick up on social cues because they can’t see other people working. Nobody notices that they’re lost or sad or confused because they’re not interacting outside of meetings. A lot of them have been led to believe from TikTok and other sources that remote work is an opportunity to travel and do other things while pretending to work.
The list goes on and on and on. I’ve managed remote teams for years and anyone who says it’s the exact same as being in the office just isn’t being honest about the difficulties that come with remote.
verve_rat@reddit
I mean... that can be summarised as: you need competent seniors to mentor/lead.
PragmaticBoredom@reddit
Not really. Competent seniors can’t force people to care about their job. The problem isn’t going to make sense if you haven’t seen how much some juniors go out of their way to do as little work as possible. You can only mentor someone to improve so much before it’s better cost/benefit to just cut them and replace them with a new hire who actually cares.
mkdz@reddit
This is what we've seen at our group too. We have co-ops year-round that do stints of 6 months at a time. We're hybrid in office, but we highly highly recommend them come in person for at least the first 3-4 months because it's so much easier for them to ask questions and for us to mentor them. We've found when they're fully remote they shy away from asking questions.
samelaaaa@reddit
I’m part of that crowd and I can honestly say this problem “doesn’t exist” for me or the companies I work for — it doesn’t make sense to offer free apprenticeships so we don’t. But it’s a tragedy of the commons situation that is going to bite our industry in the ass in the not too distant future unless we can figure it out.
I wonder if we could learn something from the skilled trades, who have been doing apprenticeships for centuries. Do the experienced tradespeople gain anything from doing those, like contractual periods where the trainee can’t leave and works for less than market value? That sounds extremely distasteful to me but I really don’t have any good ideas for how to solve this.
PragmaticBoredom@reddit
From my limited experience with the trades, the apprentice period doesn’t even need to be contractual because the apprentices were really truly doing grunt work for a more or less fair price. If they left, you weren’t really losing out on training because you still got the grunt work out of them. (FYI, I was the young guy doing grunt work in this story).
SWE doesn’t have an analog these days because the learning curve is steep. There isn’t much easy grunt work that new people can take on, start with less than a day of training, and complete autonomously. We have to spend so much time getting fresh grads up the learning curve to where they can autonomously solve problems and run them through to production that they’re effectively a net negative for a long time.
roynoise@reddit
This sounds like a good solution actually.
Doing QA and Testing should be a normal path to SWE. (Obviously outside of just interviewing for SWE if you think you can pass).
I was fortunate enough to start with a consulting company that did apprenticeship with tiered pay raises after such and such amount of time.
Any of this works, and you appreciate it way more than thinking MANGINA should pay you $150k to sit on your hands for the first 18 months of your career while you figure out how to work. That's more a symptom of society's chronic discontent and sense of self entitlement though than a problem of our field specifically
Radrezzz@reddit
QA and testing these days is software development. Building automated systems implies writing software.
samelaaaa@reddit
Yeah this is a good point. I spent a summer at 18 putting in insulation, sweeping up the worksite and framing decks for $9/hr; that was a good deal for everyone involved. I can't think of *any* task in my day-to-day that I could efficiently delegate to someone with basically no experience.
ghostwail@reddit
That's the thing, the kind of grunt work that would be delegable, is often also scriptable.
PragmaticBoredom@reddit
This is the #1 problem I saw with juniors. They arrive on their first day filled with ideas about how work is a scam, they’re criminally underpaid, or that it’s their moral duty to do as little as possible. It’s nearly impossible to shake them free of this mindset after they’ve absorbed it for years from TikTok and Reddit and some random Discord where the chronically online edge lord moderators rant about work being evil 24/7. Sadly, the only way I’ve found to actually break people out of this mindset is the reality check of being fired for poor performance.
I have had a few excellent remote juniors, but they’ve all arrived with some form of remote collaboration experience: Working on open source projects, doing a game mod with a team of online friends, or other non-work remote collaboration. They know how it works and they’re motivated to succeed.
I have not had good luck with the juniors who want remote work for flexibility. The worst have been people who take a remote job and then are suddenly in different countries traveling the world while they “work”. It’s not impossible to make this work, but I think 9/10 people who try it are only interested in collecting paychecks doing as little work as they can get away with.
In recent years the work I’ve been doing has had a security/contractual requirement that work happen in the United States, which makes it easy to cut these people as soon as they slip up and forget to turn on their VPN.
Diligent-Jicama-7952@reddit
Its called screen sharing as much as you can. I have a standing 1 hr long working session with trainees where we take turns sharing screens on anything we're working on, it works well.
People don't have that kind of patience usually but i promise you it works.
SituationSoap@reddit
This has been true for decades now, though. It was much more true circa 2008-ish, and yet people managed to join companies and progress their careers during that time.
mwraaaaaah@reddit
It is especially more true now that there is a large supply of seniors looking for work, whereas historically finding seniors has been challenging.
SituationSoap@reddit
I pretty strongly disagree with this. There is not a larger supply of seniors, in 2024, compared to size of market, than there was in 2008 or 2009.
In 2009, it was common for 1/8th of every cohort of people in every industry to be unemployed and actively looking for work.
mwraaaaaah@reddit
sorry, my wording was not clear - i think it is more true vs decades past, but not during the great recession - that was definitely worse
JoeBidensLongFart@reddit
Many companies do this regardless of in-office vs remote. That's one reason why there are so many more job postings for experienced employees vs juniors. Most companies would rather pay a little more for someone else to train their employees rather than recruit low-paid juniors themselves and be responsible for training.
No_Mission_5694@reddit
Which companies handle training? What type, and where - name names!
3rdtryatremembering@reddit
I mean, devs love to clown on daily stand-up, but isn’t this one of the reasons they are great?
Taking 5 minutes to explain what I’m up to and any blockers I might have is a great low-stakes way to bring up any small issues i have before they become an actual struggle.
I guess it feels to me like leaving a fresher alone for days at a time just doesn’t help anyone.
Pleasant-Database970@reddit
nothing is great about daily standups.
subma-fuckin-rine@reddit
ive seen ppl giving updates as normal for a week in standup, finishing the week with "just wrapping things up" then you sync with them and they're at the same place they were 5 days ago at your last sync. people will find a way to screw with any system in place lol
3rdtryatremembering@reddit
I mean yea, if someone chooses to not communicate or be deceitful, there’s not much you can do. I was answering the question more for helping new engineers who want to actually learn and grow. Creating an environment where questions are asked constantly and not looked down on is the best you can do
milkcreambun@reddit
Even when that environment is created, it's still up to those new devs to decide to be accountable and ask questions. We might also assume they want to learn and grow, but they might also say that because that's what everyone wants to hear, and then we get the wrong impression of them. So many of them seem to want to cruise on by these days, eventually they just need to be PIP'd and then fired. There's only so much time that should be invested into them.
lab-gone-wrong@reddit
That's what PIP is for though
Western_Objective209@reddit
The problem is when people get blocked 20 min after stand up and just do nothing until the next day when they feel it's safe to bring up
lunacraz@reddit
how do normal people think this is the right way to work...?
No-Article-Particle@reddit
You obviously forgot how stressful and anxiety-inducing it is to join a new company as a junior software engineer.
Hell, here I am, a senior that's procrastinating on reddit because this research topic I'm on right now is just brutal in the context of the 25-year-old base of spaghetti and rigatoni code base that's held up by bubble gum, and the PM's hopes and dreams.
So yeah, I'd say it's fairly common for people (not only juniors) to have dead days, until they make a breakthrough in what they are working on.
lunacraz@reddit
i think this scenario of "I know how to do this but this work sucks and i am dragging ass" is way different than "I'm stuck I have no idea what to do but instead of asking someone for help i will just sit here"
Western_Objective209@reddit
I've seen it a lot, especially on big teams where there's a lot of new people and contractors constantly passing through
3rdtryatremembering@reddit
Yea that’s true. I think part of what makes a good standup is that it creates a conversational atmosphere within the team. It makes asking questions feel normal as opposed to something that is feared. So ideally, after a good standup, they would feel comfortable sending out a quick slack like - “oh hey team, something I didn’t get a chance to ask in standup…”
pheonixblade9@reddit
daily standups are great when they are used for their intended purpose, but every single time I've been involved in them, they turn into status reports for management and ad hoc design sessions.
gemengelage@reddit
I've worked with so many unexperienced or straight up underperforming developers who were unwilling and unable to bring up any problems in a daily because they didn't want to do it in front of the whole team.
njosnavel@reddit
This is a common problem in my experience and I try tackling it by vocalizing my own blockers during standup, hoping it'll help others break out of their shells. Knowing when to ask for help is a strength, not a weakness.
gemengelage@reddit
Absolutely. I just meant that I've encountered quite a few people who just can't be convinced. But at least I usually get them to be upfront with me in person, which honestly works for me.
njosnavel@reddit
Sorry, that last bit wasn't targeted at you but rather juniors in general 😅. I feel you.
vazura@reddit
That sounds more like a problem with the environment that's been created in the daily. Is it just devs there or is product, and management also joining these?
DivineMomentsOfWhoa@reddit
IME it’s a personality challenge and not organizational/process, though I do acknowledge that could be the case. I think some less experienced engineers have some complex in their heads that they will be seen as lesser if they don’t understand something or if they can’t grind it out on their own.
Definitely something that can be worked on with coaching but as with all mentorship, it requires a willing participant.
gemengelage@reddit
Absolutely not. I'm talking about one or two devs per team over the last decade. Different companies, different projects, different teams. There's always at least one person who is completely unable to say anything they perceive as self-incriminating in front of the team.
What the fuck kind of nightmarish horror ritual are you even talking about? I have legitimately never heard of such a bad implementation of a daily stand-up.
vazura@reddit
So you first say "so many", now it's one of two per team over the past decade.
So every single company you've had the exact standup style? I've experienced a bunch. When I say broken into teams I mean front end, back end, product etc. do their own stand-ups. Leads from each team can then connect in their own to discuss.
I have been in a company that put every single person in a giant standup and it took up to an hour every morning, despite us complaining about it, nothing changed.
There's also a problem where some stand-ups are just status updates, this is the wrong way to treat them. If you have nothing to report, or no blockers then you move on. Standup should be used for raising issues, otherwise you create an environment where people just say "I'm working on blah blah" for an entire week because they don't want to sound like they aren't doing anything.
gemengelage@reddit
I've worked in and with a lot of teams over the last decade. It racks up.
Not the exact same, but roughly in the same vein. I've never worked anywhere where frontend and backend were separate teams, partly because I wouldn't want to work there.
That sounds like a nice game of telephone. Why would anyone want that? Are the devs at that place so incompetent they can't be trusted to work with devs from other teams or are the team just super egoistic?
And giant standups with a whole department really sound like a headache and then some.
Both approaches just have so much overhead.
adambjorn@reddit
As someone who started my career in a remote roll a few years ago, this worked very well for me. When I first started I had questions pretty much daily and DSU was a great space to ask some questions, especially when it was a non-blocking question or I just didnt understand the why of something.
That being said if I felt that I was blocked on something I had no problem reaching out directly to the SME for whatever part of the product I was working on, so it does require some initiative from the freshers. My team has a very open and collaborative culture and this helped a ton.
I am also a career switcher and had some experience working remote in another industry, so I was already used to the remote format.
Colt2205@reddit
This is probably one of the bigger struggles I've seen with not just new devs but devs in general when they are hired into certain types of environments. Being hired into a big company that moves slowly on projects while also being new can create a lot of anxiety from feeling lost. That and people giving loose requests through unofficial channels and then suddenly going silent when there is a need for clarification on some detail, or someone has to do work to allow for testing and no one seems to answer back, can create pressure where someone becomes more worried about wasting their time then fixing problems.
My personal pet peve is the "we need a testing application so we can validate X is working", time gets spent building this application that likely has to be some kind of intranet hosted site, and they use it at most once per year. That one intranet hosted application built to run a simple check now costs time to maintain and possibly even redeploy, for something that someone could probably build a query that can be ran by support.
roger_ducky@reddit
Only thing I’ve found useful is to have someone proactively reaching out to people and encouraging them to ask questions when they have it. Once they’ve done it a few dozen times they’d start feeling more comfortable doing that.
ThigleBeagleMingle@reddit
I required all my directs to include me on code reviews. The deal was they didn’t need to wait for my approval or even fix my recommendations.
But if it was wrong next time id keep pointing WHY it was wrong. I welcomed open debate about performance issues to exception handling best practices.
I treated it like school with guided research projects. Ex: Should this feature use Kafka or Rabbit? Come back in a week and present your thoughts with timeboxed POC.
Roll forward a year and 3 x L1 and 2 x L3 qualified for promotion. I also got one senior on path to lead.
TLDR: Everyone wants a mentor that can teaches them how to build cool shit correctly. Do that and the rest follows suit
SnowdensOfYesteryear@reddit
Were you a manager at the time? My manager tries this and the team resents him for micromanaging (he stopped after receiving the feedback)
dwky@reddit
I managed our coop hires(aka interns) and every 4 months we have new coop students come in. In our company, our whole software team is fully remote and these coop students are also fully remote.
What’s worked for us is documentation and making yourself(and others on your team) available for pair programming sessions or calls. Basically trying to make it so it feels like you are all in an office and can turn around and ask each other questions and someone will answer or have a chat with you.
That amount of hands on usually takes about a month or so, depending on how fast the coop students pick things up. After that, the amount of hands on drops and the students are working more independently. Some students require more hands on help and assistance throughout the term, some less.
godwink2@reddit
I think the main thing is theres this fear of us saying that they need to improve and escalating their lack of performance and then them saying to non technical managers that they sucked because they didn’t get the support they needed. When we’ve said reach out if you need help. I have some (oddly same yoe as me) but not as good devs I am trying to guide them to improvement. Its my first time leading a team and its kind of a bummer. Can only imagine with fresh graduates
jamestakesflight@reddit
I have never onboarded a new eng fully remotely as a new engineer. My early career started with some ex pivotal labs guys and it was all day pairing.
It is extremely demanding in the way driving is, but there was some serious growth in those times.
Pairing tooling is great too. I, for one, love to use LiveShare as much as I can in VSCode.
This is a draconian approach, but extensive pairing with remote pairing tools is how I WOULD do it, not quite sure it would work.
llanginger@reddit
I’ve been remote my whole career and while I don’t think I have “the” answer I’ll share the way I see it.
IMO trust is the biggest factor in mentorship / collaborative work. If a dev doesn’t trust that they can be honest about what they struggle with, they’re most likely going to try to hide that from you / the team as much as possible. This makes a lot of intuitive sense to me - the job market fucking blows right now and they don’t have a history of success that they can leverage to find a new job (or leverage to self-soothe). For a lot of junior devs their current job probably feels like their one and only shot.
1:1s are, imo, the single most effective way to build that trust. I try to focus on being vulnerable in these meetings - I talk openly about how I learned (made mistakes) and I talk openly about it if there are tasks I’m -currently- struggling with.
Public shoutouts! When the members of your team make progress, call it out in as public a forum as is appropriate. This helps show that A; you’re aware of them and B; their achievements are theirs.
ivoryavoidance@reddit
Maybe like have some company internal projects, and create imaginary deadlines. So that they need to need to reach out. Like making them feel if it’s not done, then it’s going to have real impact.
Maybe fake a little bit of performance review. It sounds nefarious, but idk, if they are not listening when you treat them nicely, then kindof try to instil, some amount of fear and loss for the ones that are not driven.
demosthenesss@reddit
Well, are you really surprised if you place all the responsibility on the juniors for identifying when they need to reach out?
There are a variety of things your team can do:
anubus72@reddit
I generally agree with you, but self awareness and the ability to ask for help is a critical skill that everyone needs to know, and honestly is something people should’ve learned in college or internships already
demosthenesss@reddit
If the OP's expectation is everyone at their company has this level of self awareness they should not be hiring brand new grads.
d4n1-on-r3dd1t@reddit
Amen. I hate how hard these “devs” try to just not collaborate with the people they work with.
Many of these issues can just be solved by getting into a call with these junior devs and brainstorm together - not only it helps them go in the right direction faster, it also builds trust and positive experiences.
But no, let’s add all sorts of process shenanigans to avoid people from working together - or worse, force me to come to the office to do PRECISELY what i described on the paragraph above.
andymurd@reddit
Daily one-to-one sessions with a wide variety of different people in the business; some pair programming, some deep-diving into business analysis, some architectural stuff, some sales engineering stuff. Everyone should be focused on teaching the newbie, not getting more features out.
Eventually, the newbie will want to keep a mentor (or two), but should know know a bunch of peeps that can answer questions or have their back if they have a tricky situation.
Remote newbies (and office newbies) should also present something (anything) to the team/department/company after a couple of months to get them front and centre, used to speaking up. My $COMPANY has Friday afternoon presentations at 4.30pm wherein every new start must speak in their first two months. The rest of us get callec upon regularly. The topic is sometimes technical, often cultural or food-based. My favourite was learning about a dude's extensive hammer collection.
Izacus@reddit
That sounds like you mistook a school for a workplace and completely forgot that businesses aren't there to spend money to train people. Those are schools.
Sir_Edmund_Bumblebee@reddit
Not wanting to spend money on "training" your employees seems like a great way to create and maintain a terrible engineering culture.
Izacus@reddit
This is the reality in most of the market right now.
Western_Objective209@reddit
ngl this sounds like a nightmare
chefhj@reddit
I agree with everything here but just wanted to say a recurring ceremony at 430 on Friday is heinous.
requios@reddit
You must attend the 430 Friday meeting to learn about hammers
WolfNo680@reddit
This is kinda how my first job operated - first week the new engineer introduced themselves so that everyone knew who was talking. We also had a "first years" standing meeting where one of the founders would meet up with all the new devs for the first year on the job and just answer general questions and talk shop about things at the company - whether it's stuff you're currently working on, questions about concepts or processes, what-have-you.
We also had a yearly meetup where everyone was flown out to a location for a week and we got to actually see each other in person but I imagine for larger companies that might not be feasible.
Woodport@reddit
This and other communication/collaboration issues are really easy to resolve IMO. The answer is voice channels. Specifically I'm thinking of Discord voice channels because I don't know if teams/slack/etc have an equivalent. What you need is a central location where your team congregates when they're available at work, where you reduce the barriers to communication to the absolute minimum.
A voice channel is a place where your team members can hang out with their mics muted and work on their own tasks, but if anyone has a question they can immediately verbalize it to the whole team and get quick answers from whoever has the most expertise. This also works for partners who want to pop in and ask a question. Did a few people start a conversation and bother everyone? Take it offline/elsewhere. Need to focus? Deafen yourself in the channel so you can't hear anyone talking and they know you won't respond. If it's serious they can ping you in a text chat. Need to step away for lunch or whatever? Just leave the channel and rejoin later.
They key is to prevent it from turning into some kind of management spying technique. It's meant to emulate being in an office setting with your team. Sometimes people aren't even talking about work but just bringing up random things they saw in the news/online to decompress, and that's ok in a voice channel because anyone who isn't interested can just deafen themselves and keep working.
Abadabadon@reddit
Be more proactive.
AssignedClass@reddit
You HAVE to worry about this more. Take on the mindset of someone who wants to get real value from these freshers, but have the heart to actually be helpful rather than cruel.
The pressure just has to come from somewhere, and if the pressure doesn't come from the freshers themselves, it has to come from someone else, and by the sound of your post I'd rather the pressure come from someone like you rather than most managers.
No matter what though, it's just going to be a tricky problem to navigate and you're not going to be able to reach everyone. If you find you're having a hard time reaching these freshers, try asking if the more senior devs if their interested in doing "more involved / direct mentoring".
Also, I think it's a good idea to share these thoughts and sentiments with the freshers if you haven't already. Actually letting people know that they work at a place that cares about their career makes a big difference, but the challenge with that is authenticity.
ShadowPixel42@reddit
We don’t do full remote, but hybrid and I am mostly remote where I can be.
We have a graduate level developer, I spend a lot of time on calls with them and pair programming.
Basically when there is a chunk of work we can both attack, I’ll pair program with them to develop a “template” or pattern they can go away and follow to finish the work. This works really well.
Maybe once a fortnight we do an all day session as well where we brainstorm ideas/refactors and I also spend a chunk of time going over CS fundamentals they may be struggling with eg what an array is at a low level, bytes etc. because web is mostly high level stuff, it helps to understand the lower level details
Works really well, I’m constantly impressed by how well they are doing
Swoopwoop3202@reddit
designated onboarding buddy to ask questions to (someone that is nice/patient is crucial for this so they feel comfortable asking questions), daily check-ins for first couple weeks with onboarding buddy, and be explicit about social norms that they might feel awkward asking or bringing up
APurpleBurrito@reddit
Give them an assigned senior mentor and dont assign the senior any tickets for two weeks. Have mentor walk through architecture diagram. Show the new person how data flows through the system. Have clear onboarding docs for getting the dev environment set up. Make sure runbooks are up to date. Keep a queue of beginner friendly tasks. Make sure they are shipping something every day, preferably in different sections of the codebase. Make sure they get to do at least one release/migration in prod. Have clear goals for first month of work. Have them shadow on-call in the first month. Set up meetings with PMs, CTO, & CEO if possible or whatever executive feels appropriate for your org. Set up social calls with the rest of the team. Do lots of group chatting in slack.
bwainfweeze@reddit
Every time the new guy starts looking comfortable throw him a story that should make him slightly uncomfortable. Repeat until you ca. hand them something important.
freew1ll_@reddit
I work in a very similar environment, small team of maybe 5-6 devs (myself included) all working very independently, company recruits 2 new devs maybe 2x a year.
There are some things that my company does that seem to produce good results.
They are very particular about hiring. They put serious time and effort into recruiting. They found my resume in the search results on a job board, I had not applied to them directly. They have lots of sneaky tactics to sus out people's personality and how they react to certain situations in the hiring stage. Despite that, I only had a 30 min behavioral interview and a surprise technical interview (which was very simple and did not involve any leet code).
They run us through a training period. Take this list of online courses on our tech stack, finish each in this amount of time, make a short project after and present. People who can't get used to the deadlines or can't present well after a few tries are cut quickly.
They are not afraid to cut a resource that is not meeting their expectations.
Daily standup, run through what you're working on. Helps them ensure time is being allocated properly and progress is being made at an acceptable pace.
Those things helped me get up to speed quickly and grow a lot, but keep in mind I want out ASAP for reasons that are somewhat related. There are also important factors in software development that fall by the wayside at this company and it shows. That being said, I could not in good faith tell you that the company doesn't turn fresh college grads into billable resources quickly.
TheophileEscargot@reddit
The 15 Minute Rule has worked well for us. If a developer gets stuck, they start a time and spend at least 15 minutes trying to solve the problem themselves. They have to write down all the things they tried (e.g. Googling the error message). If they're still stuck after 15 minutes, they should ask for help.
We do the asks for help on the team chat where whoever is available helps out. If they're scared of showing weakness, maybe assign them a mentor whose job it is to help them.
maofan@reddit
You have to be intentional. As the team lead as I got new graduates into a team I'd spent an hour with them every single morning on teams. You may be able to distribute throughout your team depending on your seniors. It was a drain on my time, but it made a big difference. In that hour you can talk through concepts, pair program, explain different approaches. You can't rely on osmosis, which frankly was always a lazy way for managers to get their juniors up skilled.
wheretogo_whattodo@reddit
It’s tough and not worth the effort. All remote hires to my team need to be about senior level now.
EirikurErnir@reddit
I wouldn't say it's the remote work that's messing with the new people, it's the autonomy. Remote work can increase autonomy, but that just means you need to create workflows that don't rely on you looking them in the eye and seeing the despair.
A critical part I see missing in your story is that you rely on the new people's initiative to reach out. I'd replace that with an explicit expectation around how long they are allowed to be stuck, and a mechanism to hold them accountable.
Concrete example - if they are stuck for more than 20 minutes, they should reach out, including examples of their issue and a report of what they have tried. Additionally, check in in a daily standup, and reprimand them if it turns out they have not been meeting the expectations around how long they are allowed to go without asking for help.
External_Mushroom115@reddit
Is autonomy is a prerequisite for remote work to be successful?
The question is then: how do you become autonomous at work?
EirikurErnir@reddit
I think developers either need to be able to work autonomously or receive clear guidelines on how to work. More powerful developers need fewer guidelines, new graduates need more.
Remote work just affects the ways in which we can interact with the guidelines.
subma-fuckin-rine@reddit
thats one thing i noticed with newer devs, you give them some task and tell them to reach out with any questions or anything. they almost never do and spin their wheels or create junk. somehow its impossible to convey thats its ok to ask for help lol
Creativator@reddit
I take inspiration from other trades. For instance, in the old newspaper business, new journalists would be "assigned stories" to report on. Then the editor reviews the story, helps the journalist investigate, etc. You just need a daily touch point.
anonymous-111-222@reddit
I once worked at a company that did a weekly programming challenge/exercise every Friday afternoon. Two hours working on the programming exercise alone, following by a two hour group chat discussing how each person approached solving the problem. Participation in the programming portion was totally optional, but everybody participated in the group discussion. To upper management it probably sounded like throwing away a half day of everybody's productivity every week, but it really did wonders for educating and motivating developers, especially the younger/junior developers.
DecentGoogler@reddit
I’m actually giving a talk on this soon!
Short answer is mob programming. Have the Jrs pair up with another jr or a more senior engineer and trade off who’s dictating and who’s typing every 10 minutes or so.
This gives the junior time and space to ask questions as well as get to know other members of the team.
re0st92mg@reddit
How does it not work? What are the actual issues you are facing?
You don't really go into any of that in your post other than "it's not working". If this is how you communicate things, I can see why you're having issues.
Formally-Fresh@reddit
Have them send ya message end of day every day that explains what they spent their day on. You don’t want to micromanage but you don’t want them spinning their wheels too long. This seems to be a nice balance.
LogicRaven_@reddit
You would need an equivalent of this in the remote team. Pair programming, mob sessions, daily standups, design review talks, etc.
I also heard of a team that has a voice channel open during work. I don't think that would work for all teams, but you could discuss with the others.
That can be a rather higher barrier for an unsecure junior. Do they have a buddy/mentor who they could work with and who could check on them more often?
a_library_socialist@reddit
You're waiting for a problem to develop things.
Setup times - one on ones once a week, minimum. Education times as well for general concepts that aren't taught in school.
Few_Olive3658@reddit
I’m dealing with a similar situation at the moment, I have a developer who just graduated in the spring and joined my team less than 3 months ago.
I’ve done a couple things so far. When the fresher first started, I setup a bunch of meetings to walk through my teams processes. I also setup a few sessions to do some pair programming. In addition, my company had an in-person event at the office where my team is technically based at a month after they joined my team so I did some pair programming with them while on-site.
I also have a few minutes blocked off in the morning and the afternoon to discuss what they worked or will be working today and also discuss any questions they have. They're also free to message me if they have any questions that come up. At some point in the near future, I'll probably reduce the number of daily meetings down to 1.
So far, what I've done appears to be working. They've already started to become productive, started pushing code changes into Production, etc. They also said that the daily meetings were helpful for them.
TheRealStepBot@reddit
Had an intern this summer that was entirely remote and it was tough. Don’t think I have solutions other than I suppose something like, it takes a lot more active engagement than you think.
Additionally I’d say don’t bring them on board hoping they will be productive immediately, make the point their learning and if they succeed at delivering along the way that’s a nice plus.
But that’s easier said than done.
jhartikainen@reddit
I'm very curious about people's personal experiences with this as well. Although I worked some offices, majority of my skillset is entirely self-learned, from building stuff for fun, reading a lot of books, etc. - as a result, working more in a managerial role, I'm not sure if I have the full picture for those who might not have a similar background as I have, and who might want/need support from others on developing their skills.