How to set junior employees up for success in remote • Hacker News Board

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

#341

Post by treis » Mon, Jun 27, 2022, 5:17 PM UTC

folkrav wrote: post #251

treis wrote: post #207

Earlier quoted context omitted.

You should still do it. Those people leaving and going to other companies is good for you individually as it builds your network.

Not everyone likes the mentoring and pedagogy aspects as much, and that's fine IMHO. I do like it despite turnover and "wasting" resources on some people, but I'm coming from an education/instruction background. I can see how some profiles would not be really interested in doing that.

The GP said they didn't like it but did it anyway. They stopped because the developers they mentored would leave when they got good. My point is that it's better from them individually to mentor someone and have them leave because it builds their network.

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

#342

Post by giantg2 » Mon, Jun 27, 2022, 5:32 PM UTC

prepend wrote: post #337

giantg2 wrote: post #250

Earlier quoted context omitted.

"Sounds like they should fix this with better laptop encryption." I'm not aware of any security experts that share this reasoning, if the information is truly sensitive and high value. "There’s many cheap methods to make source code on a stolen laptop useless." Such as?

I have a security clearance and follow protocols on my device to process sensitive data. Here’s something that came back fro Google, https://www.esd.whs.mil/Portals/54/Documents/DD/iss_process/... If my laptop is stolen and the thief doesn’t have my keys the data contained is worthless and isn’t a breach notification at all.

Where is that in that document?

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

#343

Post by ensignavenger » Mon, Jun 27, 2022, 5:48 PM UTC

tomtheelder wrote: post #264

ensignavenger wrote: post #94

Earlier quoted context omitted.

I wonder if it is really so much down to just personality, or if training, process changes, and better tools could largely ameliorate the differences? I have a hunch that as more work shifts remote, new ways of working will evolve.

I do think a lot of it is driven by personality types, but I would attribute that more to personal need for close contact and socialization. I will never thrive in a remote environment- not because I can't manage focus or work asynchronously or anything, but because it makes me extremely depressed. It's impossible to keep my productivity up as my mental state degrades.

I know this can be a real challenge for some. Do you think it would help to have a nearby a co-op work space type setting, where you would have others around and you could come and go as desired?

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

#344

Post by zeroego » Mon, Jun 27, 2022, 5:49 PM UTC

ChadNauseam wrote: post #310

zeroego wrote: post #164

Earlier quoted context omitted.

Hey there, just wanted to say as a remote junior dev who has been at it for about 10 months now, that I appreciate the article a lot. These 10 months have been the most difficult of my life, professionally speaking. I was assigned a mentor, but there were no training exercises, or "easy bug fixes / small wording changes to make, so they can focus on learning the workflows" quite the opposite actually, and no processe…

I’m a fellow remote juniorish dev (I just passed one year of working in the industry since graduating college). I relate to everything you wrote here.

It's rough out here! I'm still very grateful to be in this career and things are (slowly) getting better. If I ever end up in a senior position I will insist on better onboarding practices for junior devs if poor ones exist.

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

#345

Post by PeterStuer » Mon, Jun 27, 2022, 5:53 PM UTC

I'll restrict myself to the software/IT sector as that is where my expertise is most prominent.

Oboarding and successfully integrating juniors is fully dependent on having real seniors (not juniors that you sell as seniors) in the company and budgeting them substantial time (>25% minimum per trainee supervised) to support this process. This further assumes that you had a decent selective hiring process, as no training/onboarding will compensate for the senior's productive time for complete misses.

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

#346

Post by dang » Mon, Jun 27, 2022, 6:39 PM UTC

cmrdporcupine wrote: post #106

"I think anyone who can’t work well remote, on average, will not be your top performers anyway." Ah, there it is, the bountiful blind arrogance I have come to expect from threads like this on HN. It's like you didn't even read my post, just looked for the hook to drop in and proclaim your superiority.

Please don't swerve into off topic flamewar like this. I didn't read it closely, but the GP reads to me like normal internet conversation. That doesn't mean the comment is right, but there's plenty of room for an exchange of views here.

Instances like this are where the following guideline comes in handy – if you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html, we'd appreciate it:

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

The strongest plausible interpretation is obviously that the GP was making their own point about remote work based on their own experiences and not proclaiming personal superiority over you.

We detached this subthread from https://news.ycombinator.com/item?id=31894409.

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

#347

Post by dang » Mon, Jun 27, 2022, 6:43 PM UTC

Icathian wrote: post #2

While I can understand some of the arguments made about juniors getting some extra benefit from having everything close to hand, the sheer pace of the hit pieces against remote the last month or so is hilarious and very telling.

It's just a popular topic that people have lots of different views about and are eager to discuss all the time.

Randomness frequently generates uniform subsequences that feel like they can't possibly be random.

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

#348

Post by [deleted] » Mon, Jun 27, 2022, 6:45 PM UTC

cmrdporcupine wrote: post #106

"I think anyone who can’t work well remote, on average, will not be your top performers anyway." Ah, there it is, the bountiful blind arrogance I have come to expect from threads like this on HN. It's like you didn't even read my post, just looked for the hook to drop in and proclaim your superiority.

[deleted]

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

#349

Post by spoonjim » Mon, Jun 27, 2022, 6:49 PM UTC

lettergram wrote: post #101

cmrdporcupine wrote: post #46

This is not a surprise to me. I think it also applies to some people who are senior and new on a project or team. Or people with a more synchronous working style. I think remote has been toxic to productivity in all sorts of companies and for all sorts of people. I think there's in general a "personality type" that does really well with remote in a certain kind of job and thrives with fairly asynchronous disconnected…

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…

"Get better people" is not a talent strategy at scale unless you are also going to "pay them a lot more" which means that your corporate strategy also needs to include "make a ton of fucking money." Nice if you can pull it off, but the rest of the world needs to manage their companies too.

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

#350

Post by lettergram » Mon, Jun 27, 2022, 6:56 PM UTC

jmyeet wrote: post #327

lettergram wrote: post #323

Earlier quoted context omitted.

It’s not hard to implement a system which measures success. For one, we ensure everyone commits and delivers and holds others accountable for failures. What you’re describing is not a measurement of performance, I see your point though. I too very much disdain “team bonding”. But the point is to get to know and respect each other. By doing so you’re more likely to hold yourself accountable. In terms of performance th…

> It’s not hard to implement a system which measures success. So if I were looking to join your team and you said this it would be a huge red flag. Why? Because it's not easy or everyone would've done it already. The fact that you think it's easy really would be a cause for concern. > For one, we ensure everyone commits and delivers ... First sentence in and you've already added a qualitative factor. For a given task…

You’re correct nothings perfect, but these systems are really easy to develop. That said and as I already stated, most people are mediocre. Same goes for management. I see lots of talk and little delivery. It’s the whole reason YC invests in founders that “get something shipped” is a thing. People don’t move fast, they talk, they mess around, they don’t commit and deliver. Same for managers as engineers.

Further and to clarify, I said it’s fine if you can’t complete a task due to some unknown. Vocalize it to the team and update accordingly. It won’t be held against you if you if you collaborate to get it resolved. If that happens every time, there may be an issue, but typically people learn to investigate before committing.

Expecting people do what they commit is the only way to drive people to success. As I said, there are two factors, how much you commit to and how much you deliver on commitments. If people want to move up they have to commit to more AND deliver more over a 6-12 month period. Failure to deliver on a regular basis means you should commit to less. In either case, it’s easy to measure objective results.

Comments like these are red flags for me, because pushing back on estimates or communication is not going to go well. Your job is to produce results, if you fail, but ask for assistance that’s one thing. We can plan around that. If you fail and don’t request assistance that’s another. It’s about promoting solid engineering and development, keeping delivery timelines, etc. This worked on the remote places I’ve worked, might not be a great fit for you idk.

In terms of bugs, that’s more of an engineering culture. We always had strict and thorough PR reviews. High test coverage, formatted code with comments and two reviews from at level or more senior engineers.