[nycbug-talk] Thoughts on Creating Internship Programs?
lists at eitanadler.com
Sat Aug 20 21:43:07 EDT 2011
This is what I'm looking for in an internship program:
1. Something useful to the company - that they will be using long after I'm gone
2. Something with my name that I completed from start to completion. I
don't want to be a "small cog in a large wheel"
3. Useful skills - I should be learning something marketable that I
would not easily be able to learn on my own and that has a use in
4. Less important - but still a plus - it should be visible to the
world as opposed to an internal only setup.
5. Regarding root: I've had different internships which treated me
differently. Sometimes I've been an "untrusted random user" and
sometimes I've had root on every machine. I don't expect root access.
6. Payment - don't do an unpaid internship program in the tech field.
Some good project ideas for an SA intern:
- migrate firewall with pf instead of ipfw (obviously, this should be
done on a test network)
- create puppet master configuration to automate what was previously
- create script to automate virtual machine creation so that the devs
don't have to test on production machines (this one I've done)
- nagios/monitoring setup/cleanup or collectd etc
Some bad projects:
- Document current network setup (this isn't very fun) [and why don't
you have this done already? :-p]
- Research and document alternative software choices (unless the
intern is also making the decision on which one to use)
- The intern should be learning useful skills, not only the "fun"
skills. This means that s/he should be documenting everything they are
doing and provide a sound rationale for their decisions. On the other
hand it should be *only* a documentation job.
Overall you have to remember that an internship is for the intern, not
the company. While the company is hopefully going to gain something
from the internship as well, the intern should not walk away feeling
like it was a waste of his/her time.
On Fri, Aug 19, 2011 at 9:42 PM, Marc Spitzer <mspitzer at gmail.com> wrote:
> Well I think projects need to fit the following criteria:
> 1: read only, as much as possible
> 2: not root, as much as possible
> 3: genuinely useful
> 4: neato shiny output, kids like this shit
> 5: kept away from anything that can have mission or business critical
> put next to it
> 6: if possible they should be able to keep a copy of the work to show
> future employers
> 7: well defined, small and incremental.
> one of the problems with SA tasks is that they are all about good
> judgement and good judgement is all about making mistakes at your
> previous jobs. And interns not having previous jobs are just waiting
> to get some experience.
> Some of the things that come to mind are:
> 1: system/network audit/reporting scripts, you can have lots of fun with SNMP
> 2: nagios/monitoring setup/cleanup or collectd etc
> 3: event correlation/log analysis
> 4: system documentation, as mentioned elsewhere
> 5: cable tester
> 6: and make sure he measures the impedance mismatch on your virtual circuits
> 7: basic capacity planning comes to mind, if it is not there, with reports
> I would not do backups as when you need them you do not get a do over.
> On Fri, Aug 19, 2011 at 11:43 AM, Isaac Levy <ike at blackskyresearch.net> wrote:
>> Hi All,
>> So I was inspired a while back by an internship program at my old company, (but not in the tech groups- in Business/Product development). Essentially, the project pulled candidates from local schools, gave them well-defined projects to complete during their term, and the results were really excellent- the energy and ideas that the interns brought was amazing.
>> With that, I'm trying to think of how to create a similar program, in a Systems-Engineering (SysAdmin) group. Aside from the idea of bringing people in to push projects through, I love the idea of all the fresh energy- and the temporal nature of having 'guests' working on deck- it's selfish really, I want the fresh eyes and ideas on deck.
>> However, I'd really love to hear people's thoughts on:
>> SA Interns (contrary to other types of groups), have some obvious issues:
>> - Liability carried at the Systems Admin/Engineer station
>> (obviously can't walk the interns/temps in and hand them root or privileged sys internals, in spirit)
>> - Stringent Requirements of Systems Engineering
>> when Sys tools break, (N) developers to the (N)th business peoples wail, (at high cost to the business)
>> - Overall Systems Complexity
>> Without a terrific amount of oversight, (or extremely well defined projects), there is risk that SA interns could leave behind well intentioned, yet structurally inappropriate implementations- (e.g. wow, where did this ldap store come from, and why does the website now stop functioning when we turn it off?) This could be quite damaging...
>> Problem is, these are all valuable 'real-world' components of Systems Engineering / Systems Administration- (or any tech team responsible for operations and maintenance). It's of little use to me to bring on an intern, (or any SA IHMO), and just turn them into gruntwork-slaves, even though we all know how much grunt-work is involved in any job or task...
>> IDEAS FOR INTERNS, SysAdmin / Systems Engineering
>> - Working in-house on Open Source/Public projects which directly benefit the company, (ala Google summer of code type attitude)?
>> (but then what's compelling to bring an Intern in-house?)
>> - Working on one or two extremely well-defined projects?
>> (but then what value do they take that's different than the structure of a classroom?)
>> - Work on redundancy oriented projects, e.g. DB Replication and failover, other systems replication and failover, writing overall "Systems Regressions Testing" tools?
>> Hrm. Would love to hear what people think- I'm now really serious about trying to create a program.
>> talk mailing list
>> talk at lists.nycbug.org
> Freedom is nothing but a chance to be better.
> --Albert Camus
> The problem with socialism is that eventually you run out
> of other people's money.
> --Margaret Thatcher
> talk mailing list
> talk at lists.nycbug.org
More information about the talk