Hacker News Reader

I experienced this when we brought on junior members and an intern right as COVID hit. The short answer is that you do it like anything else you do remotely.

Zoom, chat, email, regular check-ins. They join the standups and team calls, learn who to reach out to for help, are assigned a buddy, etc.

There can be benefits in terms of teambuilding and camaraderie in a collocated environment, but I don’t think there’s anything fundamentally different about a newer employee. Their lack of experience will be more about what they don’t know about the company, and not a lack of ability to collaborate remotely, a skill that they have most likely learned by now. And if they can’t collaborate remotely, they may not be a good fit for a remote company.

>a skill that they have most likely learned by now. And if they can’t collaborate remotely, they may not be a good fit for a remote company.

Those are both good points.

To the first, you really can't look at it through a "when I was a boy" lens. A lot of things are different with respect to communications today, especially those who went through school during the pandemic. Even outside of work, although I certainly still get together with people, I find that a lot of the time, we're quicker to setup a zoom call rather than go to someone's house or travel to some meeting.

And, it's a bit harsh, but you're also right with your second point. Maybe (assuming the company has decent practices) if remote doesn't work for them as an intern or other new hire, they may not be a good fit if that's also going to be the primary mode of work going forward.

> And if they can’t collaborate remotely, they may not be a good fit for a remote company.

I work for a REMOTE first company and we had a junior developer that was struggling with not being in the office. The good news is that they were able to move to another company with a local office. The bad news is we didn't see that they were struggling until it was too late. Maybe if we were in the office we might have been able to reach out and help sooner.

I feel like employee happiness and job satisfaction is harder to manage remotely. Or it just might be that this employee wouldn't have worked out anyway. Who knows.

> I feel like employee happiness and job satisfaction is harder to manage remotely. Or it just might be that this employee wouldn't have worked out anyway. Who knows.

It is, but there are mitigations. The big one is that you have to ask. You can't bump into an employee and have a chat on the way to lunch or in an elevator and get a candid take on X or Y. You gotta ask directly, and often take the temperature a few times.

Experienced employees will vent or direct complaints -- squeaky wheels, grease, etc. -- but the noobs may not know how to complain, or if they should feel invalidated, dumb, etc. Hard to know what condition your condition is in.

Not sure about intern, but I've onboarded a lot of new people and I love it. I just take 1-3 hours a day and have them share their screen and work on their task.

Once they're comfortable, the sessions turn from a pairing session to a planning session that doesn't last as long, and with a few 10 minute checkins.

Eventually the person ramps up. You just need management to carve out time for this so you aren't overloaded, and you need to make it clear that the person isn't interrupting you, it is part of your job to help them, even being proactive and asking people if they want an extra pair of eyes for those who don't feel comfortable asking for help when they need it

Yes, and it’s honestly more comfortable to share screens over Zoom than it is to try squeezing next to them at their desk in an office.

or using their disgusting equipment. I would absolutely refuse to use some coworkers keyboards or mice...

Prior to remote, many companies got by without much thought about the onboarding process. Basically, they stuck a new person in an office and assumed it would work out. With remote, companies have to be deliberate in their process. I have found this to be a good thing.

This x1000. If you think that you're going to do exactly what you were doing before remote work and it's going to work you're going to have a bad time.

The way you work has to evolve and you need to put more effort in initially depending on the area.

> Basically, they stuck a new person in an office and assumed it would work out.

That still doesn't work and never works. Right might have amplified it but no difference. In places without onboarding and training lots of people are still confused.

> Ok, I'll bite the bullet: how do you train interns and/or junior employees in a fully remote environment?

What about interns/juniors needing training can't be solved "asynchronously" via Slack/Teams/Zoom/email/video call + screenshare?

In my first programming job I learnt Vim , simply because I saw other people doing it and thought it looked cool. I feel doing the same remotely would be tricky. Even if I learnt of it, how would I ever quit Vim and switch back to Slack?

I imagine that there would be less of a chance of you learning Vim and sticking with something more common like VSCode. And if VSCode meets your needs, then it doesn’t seem like a problem that needs a solution.

FWIW, I’m saying this as an enthusiastic Vim user. But I’d be able to do what I need to with VSCode just the same.

Couldn't you see this just the same when screen-sharing over Zoom?

Yes, I think you could. However this type of interaction (screen sharing) is generally scheduled (stand up, all-staff, etc.) while most institutional learning is done off the cuff. For example, when I was a younger programmer I spent quite a bit of time outside with an older programmer. He would go outside to smoke and I would go outside to take a break. We talked a lot and I learned a ton of stuff on those smoke breaks.

At another job, long ago, we had a free soda machine on the first floor. So, every day around 2:00 several of us would get together, walk downstairs, grab a soda and talk about stuff. It was a great bonding experience and allowed us to become much closer as a team.

We've been trying to recreate these "water cooler" experiences with Zoom and screen sharing but haven't had much success. Everything feels forced. We have a daily "hangout" meeting; no one is forced to attend and most people don't. I've been trying to get management to have a 2-day on-site event every quarter but it hasn't worked out. We used to do a quarterly on-site event in the before times (pre COVID) but not anymore. Ironically, before COVID most of our employees were local and in-office and we still had on-site events for everyone.

yeah zoom based hangouts are usually pretty cringe and I don't enjoy most myself. have felt similarly to you that on sites are really the only consistent way this kind of stuff happens, but it's been hard in my company to motivate management to pay for those

Perspective from someone who entered the workforce during COVID, I found being onboarded remotely was just fine. My team lead is 27, and the rest of us are under 25. We bond and engage socially in our Slack channels just fine. We meet once a week, but banter less than over text.

I don’t mean this in a flippant way - for better or worse, social media has transformed the way this generation communicates. Online slang is an adaptation that evolved as a means to capture the full range of human expression in character limited unicode strings. Group chats are the atomic unit of social networks in the digital age.

I wouldn’t be surprised if there’s a generational divide when it comes to how efficient remote work and learning is, and the success will vary from team to team depending on its composition. The latter is self evident enough, but still useful to keep in mind.

Personally, I find there’s an argument to be made that water cooler experiences are forced, since it’s synchronous communication that makes it less possible for a party to politely disengage midway through if that’s what they wish.

I trained all my new team members remotely by:

1. Checking in on them often to make sure they weren't blocked.

2. Screensharing or pair programming (one on one) to teach them necessary skills.

3. Making it 100% clear that they could reach out to me or another senior team member at any time for help - if we're too busy we'll just respond later.

Works quite well as long as your senior engineers aren't overworked and can actually dedicate some time to bringing juniors up to speed.

Thank god someone feels the same. No one cares when I put this argument forward against remote work especially for me as a junior/beginner dev

People may care. But, if the company policy is that people can work remotely when they want to, asking others to commute into an office on a regular basis is a pretty high bar.

I've got 13 years of experience, and I really worry about new people starting remotely today.

I'm not saying I would have failed completely if I started out in a fully remote environment, but I am very confident that I would not have leaned nearly as fast or as much or as deeply. I bet I would be multiple years behind in my career at least.

I get that some companies or teams or individuals seem to think they have figured this out (seeing some responses here). I hope some among them are writing books (or detailed blog series) specifically on this topic.

Sounds like a good argument for apprenticeship-style training. The trades do it fairly well, and I reckon you could probably skill up a number of IT folks and jr coders with a similar approach.

I have brought up a dozen or so freshies over the last thre years, with mixed results. My approach has changed since the beginning. Initially I would spend a lot of time; casual chats 1-1 and with teams to establish personal bonds, long sessions going over documents, the domain, active support and coaching over progressively harder tasks. This was not successful at all. Now, I just drop them off a cliff. Within the fist week, I have a short chat to get a feel, and throw them a non priority not too difficult task with no deadline. The ticket contains barely enough information. I add them to a few chats, point them to the docs home page and say goodbye. Based on the turnaround time and the quality of the work submitted abd how they go about seeking help I get a REALLY good gauge about their aptitude and attitued. They are either active about doing the task or they putter around and come up with excuses. Don't care much about code quality unless it's actually horrendous. This is great at catching ppl that faked their was through the interviews, the leetcode monkeys and other less desirable traits. Based on this the next task either involves a lot of collab or little to none. As and Bs get a difficult independant task, C's get an easy to medium task that needs a lot of interaction. In both cases they are "prod" issues that, the importance of the delivery and the deadline are stressed, they have to do an internal and external demo at the end. Team members are on standby for support or takeover if absolutely needed. This approach is WAY more sucessful. And stressful as well for the newb, but trial by fire seems to be the best way to get people integrated and being productive. Everything is learning on the fly, domain, process, culture, tools, everything. Compalined about not enough docs? Ok you go make the docs? Didn't like some part of the process? You make sure it changes. Didn't get enpugh support? You schedule the support call.

The biggest learning for me was that the amount of time spent coaching was inversely related to the "success rate". For those who genuinely wish to learn whatever the approach is makes little to no difference, for the others it makes a massive difference. Some hate it initially, but the consensus is that they all appreciate being a valuable contributor. Noone wants to be stuck in the back cleaning up docs or writing sorry tests for so done else's shitty code or doing wild goose chases or ,"ramping up" for months.

We have a strong team/collab culture. Everyone is "nice" the worst thats going to happen is that people leave you on read. My advice to all is to not worry about "bothering" people. Bother as many people as possible, ask all the dumb questions. You DM 10 people or post in a GC with 50ppl the same question in a minute. If I don't have the time I won't respond, but someone else will. If you need I'll stay on a call with you for hours while I do my work. So I actually think the amount of support available remotely is much more than the office, if you get over your hangups.

Struggling and being lost, wasting hours or days on the dumbest issue are all part of the process and there's no way around it, so the sooner you get comfortable with it the better. We work in domains where Google runs out of answers very quickly, the SR guys are still figuring things out and half the time noone knows what in world is happening right now. Getting on your own two feet is your responsibility.

Just wanted to say thanks for posting this.

It makes a lot of sense to me, and resonates with the experience I've had both as a noob to programming (or to a new role) and as a person responsible for onboarding.

A controlled trial by fire with asking for help if stuck encouraged.

Thanks a lot for this. I'll definitely try to imitate this for my next intern.

    The biggest learning for me was that the amount of time spent coaching was inversely related to the "success rate". For those who genuinely wish to learn whatever the approach is makes little to no difference, for the others it makes a massive difference.

This is an interesting point. It might be due to extrinsic vs. intrinsic motivation. Does anyone know a good way to measure people's motivation? I guess there should be a set of multiple choice questions that could be asked to evaluate someone's source of motivation, then tailor training to their needs.

Best I found was the giving the first task without a deadline, they claw their way through it and get it done asap or you get a series of excuses for a week, or somewhere between the two.if they ask you when or with what quality it needs to be done,it right off the bat it's good sign.

I'm sure people will pipe up to say worked fine for me/us but it's definitely one of the specific issues (i.e. not generic culture, energy, etc.) that I've seen raised. I'm sure there are all manner of best practices--some of which a lot of companies don't follow in-person either. But, at the end of the day (absent any in-person time), you probably need to work harder and accept both inefficiency and that it just won't work for some people.

I'd just add that socially I would have found it really difficult to graduate from school and worked from my apartment indefinitely.

Focus on Screen sharing, huddle/discord (something that lets you talk but lets you off the "meeting mode") or actual days in office if possible

Remotely it takes more intentional effort. I think a hybrid model for juniors is best. If fully remote is the only option then you really need to be proactive about supporting the junior. I don't think a on site model for mentoring translates directly to a remote model. You really need to plan communication.

I haven't got the sense that industry does a whole lot of training. Generally speaking they want you to do that on your own time at your own cost. Sure I've seen places that had interns but they were mostly used as cheap labor as opposed to a desire to train anyone.

When COVID started we hired a few people from college. It was a bit harder but not significantly so. They simply stayed active on chat and video calls, otherwise their biggest problem was the lack of a good spot in their place for WFH.

Hire good people. And good people want to work remote.

Video calls with screen sharing a couple of hours a day. Just as good as face-to-face