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
This is more like going to people's homes and collecting their ballots than anything you've posted. You've eliminated all nuance in your replies.
If you think you see a fire in a crowded building and you say something, even if there isn't a fire, it's way different than going into a building and causing chaos because you want to cause chaos
After reading, I wouldn't necessarily say he's 'gaming' the interview. It sounds like this guy really expanded his programming knowledge, wrote a ton of code, and learned to solve a wide array of problems.
If anything, it's a guide on how to learn everything you'd need to know to be a junior developer.
Until you want to undo something! Nano is definitely more user-friendly though. Some of the engineers I work with still don't know basic vim shortcuts, like 'w' and 'b'
It just takes a while to be faster in the terminal than with the gui, and most people won't switch from the thing they're used to until they see significant advantages.
I remember when I first started using the terminal, it was slow and confusing. You had to read the man pages for every little thing. Discovering the command you want is tough, I'd be screwed without the internet.
Now I hate when I need to take my hands of the keyboard to use the mouse. What a waste of time!
Bash scripts are great if they're yours. My current project has ~20 large bash scripts that do all sorts of different things. They were all written by people who haven't worked on the project for two years. Anyone who needs to make changes there spends far too long trying to figure out what's going on. The scripts could have been written in the same language as the project, and it wouldn't take a whole day to make changes to them.
I think they wrote in Bash to avoid the interpreter startup time. But the scripts are run very infrequently and most of them start/stop long-running services.
That being said, getting a bash script to do the right thing is very satisfying!
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