Interns in SRE and FLOSS

In addition to the usual disclaimer, that what I’m posting here is my opinions and my opinions only, not those of my employers, teammates, or anyone else, I want to start with an additional disclaimer: I’m neither an intern, a hiring manager, or a business owner. This means that I’m talking from my limited personal experience that might not match someone else’s. I have no definite answers, I just happen to have opinions.

Also, the important acknowledgement: this post comes from a short chat on Twitter with Micah. If you don’t know her, and you’re reading my blog, what are you doing? Go and watcher her videos!

You might remember a long time ago I wrote (complaining) of how people were viewing Google Summer of Code as a way to get cash rather than a way to find and nurture new contributors for the project. As hindsight is 2020 (or at least 2019 soon), I can definitely see how my complaint sounded not just negative, but outright insulting for many. I would probably be more mellow about it nowadays, but from the point of view of an organisation I stand from my original idea.

If anything I have solidified my idea further with the past five and a half years working for a big company with interns around me almost all the time. I even hosted two trainees for the Summer Trainee Engineering Program a few years ago, and I was excitedly impressed with their skill — which admittedly is something they shared with nearly all the interns I’ve ever interacted with.

I have not hosted interns since, but not because of bad experiences. It had more to do with me changing team much more often than the average Google engineer — not always by my request. That’s a topic for another day. Most of the teams I have been in, including now, had at least an intern working for them. For some teams, I’ve been involved in brainstorming to find ideas for interns to work on the next year.

Due to my “team migration”, and the fact that I insist on not moving to the USA, I often end up in those brainstorms with new intern hosts. And because of that I have over time noticed a few trends and patterns.

The one that luckily appears to be actively suppressed by managers and previous hosts is that of thinking of interns as the go-to option to work on tasks that we would define “grungy” — that’s a terrible experience for interns, and it shouldn’t be ever encouraged. Indeed, my first manager made it clear that if you come up with a grungy task to be worked on, what you want is a new hire, not an intern.

Why? There are multiple reasons for that. Start with the limited time an intern has, to complete a project: even if the grungy task is useful to learn how a certain system works, does an intern really need to get comfortable with it that way? For a new hire, instead, time is much less limited, so giving them a bit more boring tasks while they go through whatever other training they need to go through is fine.

But that’s only part of the reason. The much more important part is understanding where the value of an intern is for the organisation. And that is not in their output!

As I said at the start, I’m not a hiring manager and I’m not a business person, but I used to have my own company, and have been working in a big org for long enough that I can tell a few patterns here and there. So for a start, it becomes obvious that an intern’s output (as in the code they write, the services they implement, the designs they write) are not their strongest value proposition, from the organisation point of view: while usually interns are paid less than the full-time engineers, hosting an intern takes a lot of time away from the intern host, which means the cost of the intern is not just how much they get paid, but also a part of what the host get paid (it’s not by chance that Google Summer of Code reimburses the hosting project and not just the student).

Also, given interns need to be trained, and they will likely have less experience in the environment they would be working, it’s usually the case that letting a full-time engineer provide the same output would take significantly less time (and thus, less money).

So no, the output is not the value of an intern. Instead an internship is an opportunity both for the organisation and for the interns themselves. For the organisation, it’s almost like an extended interview: they get to gauge the interns’ abilities over a period of time, and not just with nearly-trick questions that can be learnt by heart — it includes a lot more than just their coding skills, but also their “culture fit” (I don’t like this concept), and their ability to work in a team — and I can tell you that myself, at the age of most of the interns I worked with, I would have been a terrible team player!

And let’s not forget that if the intern is hired afterwards, it’s a streamlined training schedule, since they already know their way around the company.

For the intern, it’s the experience of working in a team, and figuring out if it’s what they want to do. I know of one brilliant intern (who I still miss having around, because they were quite the friendly company to sit behind, as well as a skilled engineer) who decided that Dublin was not for them, after all.

This has another side effect for the hosting teams, that I think really needs to be considered. An internship is a teaching opportunity, so whatever project is provided to an intern should be meaningful to them. It should be realistic, it shouldn’t be just a toy idea. At the same time, there’s usually the intention to have an intern work on something of value for the team. This is great in the general sense, but it goes down to two further problems.

The first is that if you really need something, assigning it as a task to an intern is a big risk: they may not deliver, or underdeliver. If you need something, you should really assign it to an engineer; as I said it would also be cheaper.

The second is that the intern is usually still learning. Their code quality is likely to not be at the level you want your production code to be. And that’s okay. Any improvement in the code quality of the intern over their internship is of value for them, so helping them to improve is good… but it might not be the primary target.

Because of that, my usual statement during the brainstorms is “Do you have two weeks to put the finishing polish on your intern’s work, after they are gone?” — because if not, the code is unlikely to be made into production. There are plenty of things that need to be done after a project is “complete” to make it long-lasting, whether they are integration testing and releasing, or “dotting the is and crossing the ts” on the code.

And when you don’t do those things, you end up with “mostly done” code, that feels unowned (because the original author left by that point), and that can’t be easily integrated into production. I have deleted those kind of projects from codebases (not just at Google) too many times already.

So yes, please, if you have a chance, take interns. Mentor them, teach them, show them around on what their opportunities could be. Make sure that they find a connection with the people as well as the code. Make sure that they learn things like “Asking your colleagues when you’re not sure is okay”. But don’t expect that getting an intern to work on something means that they’ll finish off a polished product or service that can be used without a further investment of time. And the same applies to GSoC students.

Summer of Code: is it all about the money?

This is the text of a mail I sent earlier today to gentoo-dev mailing list:

I know this is going to stir up quite some discussion, but I do think
it’s worth trying requesting it at least.

In the past two years we had quite a few applications from students that
were already full-fledged Gentoo developers. I sincerely would like that
this year we put as a rule that Gentoo developers cannot partecipate in
Summer of Code as students for Gentoo.

I’m not asking to penalise Gentoo developers are students. But I
sincerely think the main goal of Summer of Code is to allow new people
to enter the scene of Free Software, to understand how Free Software
projects work and so on. Gentoo Developers are already pretty well
“inside” this world.

I think it should be a self-made decision to abstain from applying as a
student for what you already partecipate in, but as such concerns don’t
seem to be widespread (at least as the last two years shown), I’m asking
for a formal decision to all the developers. If that is requested, I’m
even willing to bring this in front of the council.

Gentoo’s ranks are quite reduced nowadays, and a few persons have shown
conerns about our current recruiting methods being able to judge clearly
technical and social skills, as well as the time one is ready to pour
into the project. I think SoC could be used as a pretty good recruiting
method: as you are going to work quite a bit with the student, you can
easily judge availability and technical and social skills. Leaving SoC
applications open to developers means wasting this opportunity.

There are many other organisations partecipating, I think it would be
quite feasible for Gentoo developers wanting to be a student SoC to
choose another one, in which they are not involved already. Yes it’s
easier for them to do something for Gentoo as they are already
contributing, but that is not the point of Summer of Code, the point is
to introduce new people into projects, not giving money to people to do
what they already do.

And just to take a stance, even if this request is to be rejected, I’m
not going to mentor a student that is already a Gentoo developer, for
sure.

So to be clear, I’m not trying to look down to anybody, I don’t even
want to stop people from being paid for their work. I just wish that we
can focus this opportunity to improve the Gentoo project as a whole.

I knew it wasn’t going to be accepted unanimously, but I sincerely thought it was more based on personal views rather than focusing on the “who get the money” idea.

And this makes me wonder, is it all about the money?

When I heard about Summer of Code the first time, I was still a student myself, but I didn’t even consider it, because I was already a free software developer. Not successful (I don’t consider myself successful even now), but a free software developer nonetheless.

I think Summer of Code is of great value for students with no real-world development experience. During the summer, when they have no classes to study for, they can find a job, not much for the money, but more to get some real world experience. Rather than going in a software company that is half empty because of summer, needing someone to keep track of the simple bugs that come during the time, they can enter the Free Software scene, mentored by already active Free Software developers.

I think the choice should be already appealing on its own, the money would just be an extra incentive so that, for instance, the parents can’t say they are not doing anything to bring back at least some money.

I sincerely can’t see how does it make any sense to rely on this money for who needs it, and would otherwise need to move some time from Gentoo to a day job. Don’t get me wrong, I do feel very much empathy for those who has to use spend more time on the day job rather than Gentoo, I am one of them, but we’re talking about students here.

If one can afford to be a student nine months an year without having a job, it’s not for the three months during the summer that he has to focus more on the day job than on Gentoo. Either one can afford to study and work (not paid) on Gentoo all year long, or has to be doing a dayjob the rest of the year too, thus is more free during summer. I can’t understand how it can be possible that “magically” by giving someone €3000 (which is not much a big sum for most people, I’d say), they can stop needing a dayjob for three months, focus more on Gentoo, and then resume the school.

It might work as “extra” money, and it might be quite appealing. But then, can one just make a little more effort, take a pause from Gentoo if he needs to, and choose a different project to be a student of during Summer of Code? Learning to work in a different environment, which is one of the goals of SoC after all.

Or is it just a matter of getting money easily, doing something you would have done already?