Please don't make junior developers feel they're a burden.
Have you ever googled "how to mentor junior developers"? It's quite mind-blowing how many articles, talks and panels are on this topic. And yet still junior developers are not feeling welcomed in their companies.
Yup, you guessed it, we also have something to add (based on our own experience):

1. Asking for help is not easy. Please don't blow juniors off by telling them to read docs when they ask a question. Always assume they've read it and did a sprint to solve the problem. They ask you, because they see you as a mentor and really need your help. If you can, spend more time with them and guide through the entire problem solving process.

2. Please don't think "I learnt it this way so you should too". If you're in charge of teaching a junior developer, don't expect them to be a carbon copy of yourself. Because even though in your opinion your approach is more "pro", they might not be there yet to use it properly. And last, but not least:

3. Of course, juniors will compare themselves with seniors on their team. And there'll be moments they feel so guilty and so afraid that they cost the company too much, that they need training, and supervision, or are between projects and are not bringing in any money, and they'll fear that their company regrets hiring them. Make sure they don't feel like a burden. As juniors, we often
have this misconception what is expected from us.

Dear tech companies, please set very clear expectations and tell your juniors you're happy. Don't get us wrong here. We don't expect unicorns, roses and pats on the back from companies. We do understand- this is business, and at the end of the day we all are here to make money. To do so, companies need to make smart investments. Junior dev with a great assistance, planned support, and a clear training program will become a great asset. It really is as simple as that.

I'm a junior dev working with some very proprietary applications. The point is, I can't Google for code solutions at all.

The seniors are all very put upon and too busy to offer much actual help unless it's urgent.

I beg for assistance until I'm blue in the face and eventually stumble my way to something resembling the solution.

I get one of them to review my code, and while they do I point out all the places I STILL need help.

They don't answer any of those questions but damned if they don't have opinions on how my comments should be formatted.

Aaauuuuggghhhh

DataDevNerd (ofc down to hardware bits)
Briefly blending amoung holiday tech consumers at Micro Center waiting for key-holder assistance @SSDs.

Rando: "they finally have a sale on *X, rebranded, price++* for my *ref'd only by part names* setup! What are you getting?"

Me: "replacement SSD, laptop's finally failing"

Rando: "Yeah, I totally get you, I hate that. How old is it? Hopefully you got a couple years outta it?"

Me: "over 7yrs old."
Rando: "Wow! Mustve not used it too much, still that's pretty long."

Me: "Actually, it's been my primary device, heavily used, as I'm a dev. I just know what/when to use SSD vs the HDD."

Rando: "Duuude, that's awesome!...wait...why haven't you just bought a new laptop yet?"

Me: "I'm not for hardware abuse or burning money"

I was quickly reminded why I tend to avoid typical consumer tech stores.

- have/share an agenda as soon as possible
- each talking point should identify a problem. Make a list of strategic questions answers to which would make it perfectly clear what and by whom has to be done to resolve them.
- plan meeting duration according to the list of questions. Make sure you meeting room reservation gives you enough time
- take notes
- be prepared for a need for another meeting(s), if during that meeting it comes clear that:
> more/other people need to be engaged
> some things are not clear and need more investigation before going further
> you have run out of time
> there are other problems tgat need to be worked out and it might cobsume too much time to do this in a current meeting
- do not turn the meeting into a chat. It's counter-productive, tiring to the listeners and a waste of time
- do not try to cover many topics. The less, the better. Unless they are very tightly coupled.
- do not invite people you do not need or there is a very slim chance you will need.
- only schedule meetings when the situation needs to be DISCUSSED among multiple parties
- that being said, do not schedule meetings when it's more convenient to communicate otherwise, like email, chat, etc.
- after the meeting make a summary and send it our to all the participants. They might reply and clarify if you have misunderstood smth or missed some important point.
- during the meeting assign tasks to each other. Verbally. Make notes. After the meeting reflect them in jira, rally, wtv.
- while assigning tasks nake sure the assignees have no blockers to work on them and make sure they understand what, when and how should be done. Some tasks might be dependedt on each other, work the sequence out.
- while assigning tasks ask "for ETAs. They might be as silly as 1-hour-to-2-weeks, but they still let you know what to expect.
- offer your assistance to the task assignees if they need any while working on their tasks

- work on your language, grammar, syntax, etc. Reading texts with typos/mistakes is repelling

- be a leader, an authority everyone is looking up to. Not a boss.
- avoid saying NOs. Be more of a "do we really need this; can we do this some other way/time; I can't promise anythibg but I'll see what I can do about it" kind of person.

Just remembered that I still had a foobar invite link in my email inbox 😋

The challenges are odd though, first challenge was super easy (basically an idiot check), but while I was able to convert 3 cans of energy drink into a functional solution in half an hour, the verification utility is not very verbose at all. So in Python 3.7.3 in my Debian box it worked just fine, yet the testing suite in Foobar was failing the whole time. After sending an email to my friend that gave the link (several years ago now, sorry about that! 😅) asking if he knew the problem, I found out that Google is still using Python 2.7.13 for some reason. Even Debian's Python is newer, at 2.7.16. To be fair it does still default to Python 2 too. But why.. why on Earth would you use Python 2.7 in a developer oriented set of challenges from a massive company, in 2020 when Python 2 has already been dead for almost a whole year?

But hey now that it's clear that it's Python 2.7, at least the next challenges should be a bit easier. Kind of my first time developing in SnekLang regardless actually, while the language doesn't have everything I'd expect (such as integer square root, at least not in Debian or the foobar challenge's interpreter), its math expressions are a lot cleaner than bash's (either expr or bc). So far I kinda like the language. 2-headed snake though and there's so much garbage for this language online, a lot more than there is for bash. I hate that. Half the stuff flat out doesn't work because it was written by someone who requires assistance to breathe.

Meh, here's to hoping that the next challenges will be smooth sailing :) after all most of the time spent on the first one (17.5 hours) was bottling up a solution for half an hour, tearing my hair out for a few hours on why Google's bloody verification tool wouldn't accept my functioning code (I wrote it for Python 3, assuming that that's what Google would be using), and 10 hours of sleep because no Google, I'm not scrubbing toilets for 48 hours. It's fair to warn people but no, I'm not gonna work for you as a cleaning lady! 😅

Other than the issues that the environment has, it's very fun to solve the challenges though. Fuck the theoretical questions with the whiteboard, all hiring processes should be like this!

When you're working in visual studio and trying to look through the suggested uses of an object and fucking shit keeps popping up all over the screen to tell what type things are and shit and you're just like "get the fuck out of the way I can't see shit you useless cunt fuck."

Visual studio buddy. You're killing me.