Live data from Hacker News

How to set junior employees up for success in remote

slite.com

351–360 of 370 posts

Re: How to set junior employees up for success in remote

#351

Earlier quoted context omitted.

Interesting. This aligns with my past experience as well. If I may ask, are you / is the company working on rectifying this, and if so, how? What we did was that we made our internal docs and agreed that whenever we were blocked by something, once we learned it, we would document it. It was a mixed success though because we never had time to work on the docs properly, and the veterans didn't touch it, so I'm curious…

Yeah we're trying to do the same, document things organically as we learn them on an internal Confluence. It helps, but we're piecing together fragments of knowledge without context, so information density is low outside of specific tasks. It's enough to solve the same problem again, but not enough to gain much holistic knowledge of the software. And same as your situation most of the veterans don't bother with it (t…

I hear you! Thanks for sharing.

Re: How to set junior employees up for success in remote

#352

Earlier quoted context omitted.

I think anyone who can’t work well remote, on average, will not be your top performers anyway. What I mean by that — as a manager and one of the senior engineers, I had insight across our organization to projects and employee performance. Those who thrived being remote were those who already were the top performers. Those who were followers; who lacked discipline, failed faster and more obviously. Most software engin…

Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality. I hold myself to high standards and have been described as a top performer by every manager I've ever had. I am disciplined and work extra hours as needed to ship. I am constantly thinking about the product and the engineering challenges we face outside of working hours. But sometimes things take lon…

> Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality.

Couldn’t be further from the truth. I ran an applied research team for years. We had hundreds of patents, multiple publications, a growing open source project, multiple presentations a year, delivered a couple of the highest priority projects, and were consultants company wide for deep learning.

I was always fine with delays, but you had to discuss them and collaborate. Come to the team, explain, then we could prioritize accordingly (5 min). It’s not a big deal, but always required high communication. That’s difficult in a remote environment, but that’s why you have regular meetings & have to be more strict than normal about planning.

Perhaps it wouldn’t be an environment for you, that’s fair. But a project isn’t about you, it’s about a deliverable; often a team effort. If 10 min of communication a day is too much, idk then.

Re: How to set junior employees up for success in remote

#353

(quoting book) Amanda Nock, a tech leader and devops expert who posts frequently to Twitter, offered this in response when I posted on Twitter about how to hire good people remotely, “When I hire remotely, I ask about their online friends.” Nock doesn’t need the details of anyone’s online friendships, but she needs to know that the person has developed a serious friendship online; otherwise that person probably doesn…

Life and friendship happen in the real world and taking away the physical side will result in something incomplete.

I suppose many don’t feel satisfied by such restricted relationships and will only bother with the real thing. I know I’m like that.

Zero connection between that and WFH ability. It’s all about communication and emotional intelligence. A great communicator will be able to apply their skills even in the stunted context of video and text chat.

As for asking about friends, if it’s not outright illegal to ask about friends, it’s certainly in poor taste. Another half-asses innovation from the SV-like mindset.

Re: How to set junior employees up for success in remote

#354
post #282
post #151

Earlier quoted context omitted.

> I think anyone who can’t work well remote, on average, will not be your top performers anyway. I don’t think that’s the case at all. One could say a similar thing in that it enables the worst employees who can drag down so-called top performers. But I don’t like any of these framings. I personally prefer working in the office. I’m more productive, focused, and able to check in with someone or go grab them and show…

> I’m more productive, focused, and able to check in with someone or go grab them and show them an issue I’m having. I think there's an important distinction here. It may be more productive for you but not necessarily for the team . You grabbing another employee may increase your productivity but subvert theirs. Anecdotally, my personal productivity goes way up when I work remote because I don't have all the "drive-b…

I don't think that's a distinction, and it definitely isn't one way because the you here will also be interrupting the team. All this gets into team dynamics, which can't possibly be whittled down to such small interactions.

Then there's this somewhat weird obsession with people supposedly being unable to perform their job without 8 hours of uninterrupted solo time. The work day isn't supposed to just be each person working solo trying to accomplish as much as possible. Interacting with the team is being productive. Extremes in either direction are likely not productive.

Re: How to set junior employees up for success in remote

#355
post #354
post #282

Earlier quoted context omitted.

> I’m more productive, focused, and able to check in with someone or go grab them and show them an issue I’m having. I think there's an important distinction here. It may be more productive for you but not necessarily for the team . You grabbing another employee may increase your productivity but subvert theirs. Anecdotally, my personal productivity goes way up when I work remote because I don't have all the "drive-b…

I don't think that's a distinction, and it definitely isn't one way because the you here will also be interrupting the team. All this gets into team dynamics, which can't possibly be whittled down to such small interactions. Then there's this somewhat weird obsession with people supposedly being unable to perform their job without 8 hours of uninterrupted solo time. The work day isn't supposed to just be each person…

I agree that team interaction can be productive. (I might even be a bit cynical in saying that most team interaction is not, but that might be a digression). I think the distinction is in how the work culture manages those interactions. My previous job wanted open-door policies; what that turned into was a poorly managed ad-hoc set of interactions. Open door interaction tended to foster unproductive venting and it can become like corralling cats to refocus that energy into solving problems. That may be fine for a supervisor; it's probably not the best use of time for front line production person.

I think I may disagree about the "somewhat weird obsession" with uninterrupted work. (I'm assuming your '8 hours' was hyperbole). The research seems pretty clear that interruptions are more detrimental to highly focused work. I don't think it's unreasonable to expect certain blocks of uninterrupted time if the type of work requires it, but that shouldn't be conflated to someone expected to simply be left alone all day.

Re: How to set junior employees up for success in remote

#356
post #7

For junior engineers it's really easy to fall into the trap of trying to solve everything themselves instead of asking for help when they are remote. I say this as somebody who has spent the last five years working remote team-based gigs.

I think successful remote work has to take the position that asking for help 1:1 is bad, actually. * If you go through the process of figuring it out, you gain a durable understanding of the subject matter which you can use to solve other problems. * If either you (after your investigation) or the subject matter expert (on request) produces documentation of the subject, other people in the future can use this artifac…

I don't know what universe you're from. Communication kills productivity? The opposite is true. Getting feedback early and often is a productivity booster. Sure, sometimes it's better to ask in a public channel instead of 1:1, but to state that it is actually bad is absolutely false.

Re: How to set junior employees up for success in remote

#357

Earlier quoted context omitted.

> Since this is Google, I think this just means that they don’t trust employees Since this is google, the repo is hundreds of terabytes. Not only that, having lots of copies hanging around on laptops is a big risk, even with encryption. Considering that google's likely threat model involves state actors, not having code on laptops is a reasonable mitigation. But I suspect the biggest issue is that most of the tooling…

As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with. State actors have security clearances for employees with equipment that allows them to contain state secrets on devices. This is a solved problem and Google not allowing any on device source code is not a security issue, it’s a control issue.

> As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with.

Unless you are very special/lucky then your code will need all sorts of the repo to work.

One of the joys of working at a big tech company with a single repo is just how much shit is pulled in by your dependencies.

my code shouldn't need a custom C++ library that does BLAS 0.15% more efficiently than the opensource lib, its just moving data from one bucket to another. However, it does because of a massive chain of dependencies.

> State actors have security clearances for employees with equipment that allows them to contain state secrets on devices

What level of secret? and how many secrets? all of them? No. Security services don't generally allow people to store secrets on mobile devices, because they get lost a lot. They certainly don't allow all secrets ever stored in the DB to be carted around on >70k employee's laptops (of which at least 1 a day is stolen, most often in sleep so the disk encryption key still accessible)

Thats not to say that low-side devices don't ever contain secrets. They clearly do, but they are supposedly risk managed to limit the blast radius. ie, they need to have a good reason to have that secret, a time till destruction, and clear paper trail to see where and when that secret went.

Thats not really scalable to a repo with > 5 million files.

Re: How to set junior employees up for success in remote

#358
post #51

Earlier quoted context omitted.

True, but there have been plenty of cases where juniors languishing in an office with little guidance. And remote you can still ask them how they're doing by chat. It's true that the barrier is a bit higher remote, but it's not unsurpassable.

In office, there's watercooler chat that can lead to debugging session. In remote there isn't. That being said, with the former culture, it's harder to ask question online and asynchronously, since usually they prefer and wait to have in face session instead.

The equivalent in remote is a chat/thread turn into a call with a screen share. Managers and seniors encourage juniors to ask questions or just “speak” their minds. There are multiple touchpoints for that to happen, dailies, 1:1’s, spontaneous check-ins b/c people care. In a culture where remote work habits are good, these will be imparted on new-joiners, especially less experienced ones.

Re: How to set junior employees up for success in remote

#359

Earlier quoted context omitted.

It's really this simple. Junior employees need to be more actively managed than senior employees. They literally do not know what they're doing, that's what makes them junior. Remote or local, they need more oversight to help them learn and become productive.

Can you give me advice on how to provide oversight in a way that's not demoralizing, infuriating, patronizing? I found working with juniors _fun_ and rewarding in person. Remote i have hated it and don't think I've been good at it

One thing that has worked for me in the past is to do some regularly scheduled pair programming. When I'm driving I narrate my thought process and encourage questions. They get to see things and when I make a little typo and they can catch it, not only does it save me a few seconds but it makes them feel GREAT that they helped the senior dev. Making this highly interactive and the senior driving FIRST makes it still "fun" when the junior is in the driver's seat.

One of the biggest skills you're helping a junior to learn is how to break apart a big task into small, workable components. Maybe they are assigned a user story, but that user story is going to need multiple functions written, or something like that. So you might start with pseudo-coding or creating the interfaces together, talk high level about how a particular method should work, and then let them do that part by themself. "Let me know if you get stuck or done with that and then let's do a little informal code review."

Beyond that it's the normal management stuff of compliment sandwich on negative feedback, etc. The normal things you do to build and maintain rapport with coworkers.

Re: How to set junior employees up for success in remote

#360
post #356

Earlier quoted context omitted.

I think successful remote work has to take the position that asking for help 1:1 is bad, actually. * If you go through the process of figuring it out, you gain a durable understanding of the subject matter which you can use to solve other problems. * If either you (after your investigation) or the subject matter expert (on request) produces documentation of the subject, other people in the future can use this artifac…

I don't know what universe you're from. Communication kills productivity? The opposite is true. Getting feedback early and often is a productivity booster. Sure, sometimes it's better to ask in a public channel instead of 1:1, but to state that it is actually bad is absolutely false.

“Work is work” [0]. As an organization scales, an increasing fraction of employee time is spent on communication instead of work, leading at best to diminishing returns on headcount and sometimes to total gridlock. To the extent that an organization wants to derive marginal productivity from marginal headcount, it needs to find ways to get employees to talk to each other less.

[0] https://codahale.com/work-is-work/

Post reply on HN