If a junior engineer isn't pestering me with questions, I know they aren't learning much. Also they overhear stuff and get drawn into conversations. Or more senior engineers join in conversations between them and another senior.

All of this is a challenge over zoom.

As far as being a part of something that matters, if I'm going to do a job for 8 hours a day, I'd like for it be as fulfilling as possible. For me that means pressure, teamwork, and at least some in-person interaction. I realize not everyone is the same.

It depends and it’s a balance. Too many questions is a bad sign because it means they aren’t investing time into solving problems on their own (like math, try for 3 minutes give up and look at the back of the book).

The nice thing about Slack/Zoom combo is that if you have a highly self-directed engineer and a self-starter then they can spend time working until they truly feel stuck and then connect and share code snippets and do screen shares and calls. Instead of everything having to be a “stop the world” Q/A session you get a nice async communication channel that allows for various levels of triage.

That being said I certainly find in-person collaboration to be very valuable, but not so valuable as to drive a car and sit in an office where I can’t wear sweatpants or get up whenever I want to make an espresso or run an errand if I’m stuck on a problem for a bit.

In my experience, there’s no such thing as too many questions, so long as they’re of good quality.

The best intern I’ve ever had was would hit me every single morning with a laundry list of questions, but, crucially they were almost 100% things she didn’t yet have the tools or context to find out on her own.

By the end she was asking me questions I hadn’t even thought to ask

I think there is. Asking for things you can look up how to do on the Internet just isn’t a good question, for example. (Like something generic like how to install a package with NPM or something).

> Asking for things you can look up how to do on the Internet just isn’t a good question

That is becoming less true by the day, as forums, blogs, etc., are filled with AI-generated pablum or with simply incorrect content. You still need an expert to tell you right from wrong, and the best option is to have a senior person in your team be that expert.

Either way, you need to bother to try to look up stuff for 5 minutes and figure it out yourself, and for technical content that isn't really the case much. Otherwise you make your mentor annoyed because you didn't even bother to put in the minimum effort and your essentially disrespecting them which creates emotional fallout. Even the bad content gives you some context and will make your question asking work better.

This is a great guide to give to everyone: https://quick-answers.kronis.dev/

> That is becoming less true by the day, as forums, blogs, etc., are filled with AI-generated pablum or with simply incorrect content.

I’d contend if you can’t tell as a junior engineer that’s a problem.

Often the barrage of questions is a symptom of an inability to debug and investigate.

Sadly, it's common with folks who learned programming with rote (they expect every answer to be somewhere they can just memorize).

I think this attitude of making sure each junior engineer has someone senior answer every question as soon as it comes up is doing a disservice to our junior engineers. One of the most important qualities of a senior engineer is that they can independently solve an open ended problem, especially one they haven't solved before.

Being senior means you have learned how to learn. You don't get this skill by asking a bunch of questions, you get it by answering your own questions without having someone else to rely on. This is a skill we should foster in our junior engineers as early as possible, and being available as a shoulder to tap on every 15 minutes actively prevents that skill from developing.

I think it is perfectly resonable to mentor a junior developer using a single, daily video meeting of 30 minutes or 1 hour. This is a time they can use to ask questions about their previous day, bounce ideas, etc. If a question comes up later, they can spend the day trying to solve it and report on it in the next daily meeting.

The best thing you can do for your junior engineer is to find a stream of work which challenges them at the right level (not too much, but just enough), and let them go independently while keeping some guard rails. This should not require many hours of 1:1 face time.

I understand this approach might not work for some juniors who can only learn in a highly social context with a mentor in the room. But I think it can work for many juniors, and actually be beneficial in the long run.

> [junior engineers] overhear stuff and get drawn into conversations. Or more senior engineers join in conversations between them and another senior

Even on-prem before 2020, this happened most often in slack at least in the tech startups I was in(?)

This is like a high school or college classroom where no one asks any question...you know no one understands what is going on. What I would look for is juniors who can ask questions, take a morsel of feedback, run with it for a bit, and then ask another question. (But avoiding giving away solutions right away, since you want it to be a learning experience).