So I just found out that I'll be hosting a high school student who is interested in software tomorrow. I take this stuff rather seriously - I remember being that age, being told to suddenly make decisions that will literally shape the rest of my life without any experience to judge those decisions, unsure of who's advice I should take or disregard. I had a hard time and I went into it knowing exactly what I wanted to do.

Anyway, they will be here for the first half of the day. I'm assuming the questionnaire they bring will take all of 10 minutes, and I'm struggling a little bit on how to show them what I do without going "ok just sit here and watch while I type colorful text". I'd really like to involve them or keep them engaged, but for a job like software engineering I cant exactly hand them the wheel if they (understandably) have no idea what they are looking at.

Does anyone have any tips on keeping them engaged? Activities? Something "fun" without seeming lame? Is just thoroughly explaining what I'm working on enough?

My background: BS. in Computer Engineering. A little over 4 years in the field as a software engineer. I'm at my second company and only started here a couple of months ago - I've had a couple of bug fixes on our main code base (which is rather big), and started and completed a small project.

About tomorrow: My schedule is open (no meetings or anything). Also I most likely wont be able to involve anyone else on the team. Our next major release is literally happening today or tomorrow so I'd rather not take away anyone's time.

  • This seems fairly on-topic to me.... – Matt Krause Jun 19 '18 at 19:09

Give them a short explanation of the company, industry, products and your roll.

Of course you can let them touch code, just not something on production.

Walk them through, creating a source control branch so they can't hurt anything (Assuming you have no intention of merging this.). Tell them about the benefits of source control.

Talk to them about the code. A programmer spends a lot of time reading this stuff. See what they are able to decipher. Pick something simple and let them make a change. Compile it (They may not work with compiled languages.). Show them some unit tests. Whatever you do.

Don't forget communications, meetings, documents, bug-tracking, etc.

The skill level could be just about anywhere. Expose them to as much as you can. Recommend resources. Tell them to create a StackOverflow account. Get on GitHub. I think the goal should be not just for this person to have a perfect understanding of what a programmer does, but leave with some direction and tools to continue to learn about programming. It's not up to you to show them how hard it is (it is hard - right now) or to go out of your way to show them the "fun" side of the job nor are you there to "weed out" poor candidates.

Think more about being a facilitator.

  • 2
    Don't surprised if the kid wants you to explain pointers. – user8365 May 23 '16 at 17:54
  • Could be worse, instead of pointers you could get a troublemaker who's been reading programming blogs/redit for a while asking you to translate "a monad is a monoid in the category of endofunctors" into English. – Dan is Fiddling by Firelight May 23 '16 at 22:35
  • 2
    One sentence stood out that helped me - "Expose them to as much as you can". I was initially afraid of overwhelming them with information, but I took your advice and I think it went really well. – plast1k May 24 '16 at 16:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.