Ask HN: What tips do you have for interns?
What are things that you strongly dislike about interns or something that you wish you would be able to tell an intern you know? I currently am an intern and want to have the best experience that I can, as well as give my employer/co-workers the smallest headache possible. I want to be an asset not a burden. (If it helps, I'm currently working as a Mobile Development Intern)
14 comments
I'm an intern right now and these are some things I'm trying to do:
1) Work - we're young right now and don't have too many commitments so why not put in some extra time to excel at your main project and even take up some side projects. It's okay to stay in the office later than most other older engineers.
2) Networking/Side projects - talk to other people in the firms, see what they're working on and offer help if needed. These might be the same people/team that may hire you for full-time one day
3) Learn - Pick at people's brains, I know at my firm most people are willing to take some time to help me. Anything that can be found on stackoverflow or a book just use that but it may help to go over some design/implementation stuff with other more experienced engineers.
4) Software - Learn from the design and testing flows of the company. Try to separate yourself from the way you write software in class or for yourself and understand the way software is developed at a production level, from test-driven development to properly deploying your software.
1) Work - we're young right now and don't have too many commitments so why not put in some extra time to excel at your main project and even take up some side projects. It's okay to stay in the office later than most other older engineers.
2) Networking/Side projects - talk to other people in the firms, see what they're working on and offer help if needed. These might be the same people/team that may hire you for full-time one day
3) Learn - Pick at people's brains, I know at my firm most people are willing to take some time to help me. Anything that can be found on stackoverflow or a book just use that but it may help to go over some design/implementation stuff with other more experienced engineers.
4) Software - Learn from the design and testing flows of the company. Try to separate yourself from the way you write software in class or for yourself and understand the way software is developed at a production level, from test-driven development to properly deploying your software.
All really useful information, do you ever get imposter syndrome? If so, what helps you overcome it?
Every day man. I tend to try to work more because I feel weird about being compensated for the work that I do. I guess just keep working hard and challenging yourself every day, and do as much as possible.
Glad to know that someone else feels exactly the same as I do with work. You're not alone on this one.
Easy to list train wrecks and how to avoid them. Harder to list advice that isn't related to train wrecks.
The worst intern-specific train wrecks I've seen involve the intern's keeper(s) not having an accurate view of the interns abilities.
The worst young-person-specific train wrecks I've seen involve young office employees having an incorrectly high assessment of their office culture knowledge. Nothing I've seen on TV and movies about office culture is useful or enlightening. Culture, as in local traditions for interpersonal relations and local shared group priorities.
The worst intern-specific train wrecks I've seen involve the intern's keeper(s) not having an accurate view of the interns abilities.
The worst young-person-specific train wrecks I've seen involve young office employees having an incorrectly high assessment of their office culture knowledge. Nothing I've seen on TV and movies about office culture is useful or enlightening. Culture, as in local traditions for interpersonal relations and local shared group priorities.
[deleted]
Do you have a more specific example of the young person specific train wreck? What about the incorrect high assessment (in your opinion) caused the train wreck?
Uhh not in public. I did a lot of dumb young-person-train-wreck myself as a youth. As analogy it all boils down to things like how we relate to fellow students (or work alone) in school is mostly not how we communicate with adults at the office.
"This is bullshit" in the source code comments makes your TA laugh and is appropriate at school, but at work the execs and customers who get source access don't think its funny especially if you make fun of the customer. Some of the most trivial basic management skills that often aren't applied in school at all, but are applied at work, like compliment in public and blame in private. At school in algo class culturally all that matters is getting the best O(n) behavior because thats kind of the point of the class, possibly work culture is not so interested especially if there is a basic physics reason or financial regulation reason n can never exceed 3. (edited to emphasize its not that these specific examples were right or wrong, but that it wasn't "gotten" that they were wrong at that work team, but the new guy genuinely, incorrectly, thought it was a cultural fit)
Its not so much being right or wrong in an absolute sense the problem is thinking they know the culture better than they do leading to innocent inaccurate behavior decisions.
"This is bullshit" in the source code comments makes your TA laugh and is appropriate at school, but at work the execs and customers who get source access don't think its funny especially if you make fun of the customer. Some of the most trivial basic management skills that often aren't applied in school at all, but are applied at work, like compliment in public and blame in private. At school in algo class culturally all that matters is getting the best O(n) behavior because thats kind of the point of the class, possibly work culture is not so interested especially if there is a basic physics reason or financial regulation reason n can never exceed 3. (edited to emphasize its not that these specific examples were right or wrong, but that it wasn't "gotten" that they were wrong at that work team, but the new guy genuinely, incorrectly, thought it was a cultural fit)
Its not so much being right or wrong in an absolute sense the problem is thinking they know the culture better than they do leading to innocent inaccurate behavior decisions.
Volunteer for challenging work that is not slated for you, when possible.
Keep an open mind and be humble when viewing the work of your more experienced colleagues. You will see things that will seem downright silly to you, but you have to consider that there was probably a very good reason for why something was done the way it was.
Keep an open mind and be humble when viewing the work of your more experienced colleagues. You will see things that will seem downright silly to you, but you have to consider that there was probably a very good reason for why something was done the way it was.
Sometimes not even challenging work, but sometimes menial work that is below others.
Every internship I have had, I was with a team that tried to give me the best experience I could, and never gave me boring or menial tasks just because I was the intern. In fact they actively avoided doing so and did these things themselves.
On my first internship there was a task that came in. As part of a security audit, we had to verify that all ssh keys that had access to sensitive infrastructure. That had to be done by hand, by running around and finding these people and checking their keys manually, which was nearly a days work. I volunteered to do it, as really that's the sort of stuff that I should be doing as it would be wasteful for the others to be spending their time on it.
Things like that got me a lot of respect. As an intern, you need to make the lives of those you work with easier. If this means occasionally taking some menial work or writing scripts to automate their tasks.
Every internship I have had, I was with a team that tried to give me the best experience I could, and never gave me boring or menial tasks just because I was the intern. In fact they actively avoided doing so and did these things themselves.
On my first internship there was a task that came in. As part of a security audit, we had to verify that all ssh keys that had access to sensitive infrastructure. That had to be done by hand, by running around and finding these people and checking their keys manually, which was nearly a days work. I volunteered to do it, as really that's the sort of stuff that I should be doing as it would be wasteful for the others to be spending their time on it.
Things like that got me a lot of respect. As an intern, you need to make the lives of those you work with easier. If this means occasionally taking some menial work or writing scripts to automate their tasks.
When taking on a challenging task like this, what is a good way to ask questions of your colleagues without seeming annoying?
You might find that with the right approach, people will be glad to help you, especially if you are taking work off of their overloaded plates. Alternately, you might also find that there are some grumpy people who you will be forced to work with or get answers from in order for you to succeed.
My strategy is to ask informed questions. Do your best to understand the problem, the motivations, the context, and the available solutions before you start asking questions. Group all of your questions together as best you can and ask them at the same time. Asking questions randomly and repeatedly will probably annoy someone who is trying to concentrate on a task. You might even find that you think of the answers while waiting for the right time to ask.
If it is clear that you are giving it your all, and not wasting their time, then people will be much more inclined to help you.
Some examples:
Bad question: How do I do {X}?
Good question: I've learned how to do {X}, but should I instead do {Y}?
Bad question: Have you seen {X feature, code, etc}? Why would someone do something so dumb?
Good question: I understand what {X} is doing, but it's not clear to me why we did it that way. Is there a requirement that I am missing?
My strategy is to ask informed questions. Do your best to understand the problem, the motivations, the context, and the available solutions before you start asking questions. Group all of your questions together as best you can and ask them at the same time. Asking questions randomly and repeatedly will probably annoy someone who is trying to concentrate on a task. You might even find that you think of the answers while waiting for the right time to ask.
If it is clear that you are giving it your all, and not wasting their time, then people will be much more inclined to help you.
Some examples:
Bad question: How do I do {X}?
Good question: I've learned how to do {X}, but should I instead do {Y}?
Bad question: Have you seen {X feature, code, etc}? Why would someone do something so dumb?
Good question: I understand what {X} is doing, but it's not clear to me why we did it that way. Is there a requirement that I am missing?
"Strongly dislike", it's not like any rational person waits in the wings with mallet to abuse someone for being new. :) If you do face a culture of blame (like playing an online game) your office culture probably is a bad fit. Never work with assholes. It's never worth it.
Study their workflow and design process well. Learn DVCS (git, hg) very well and the best practices that come with it (especially branching).
Once you have branching down, you can create your own branches without affecting their work.
Never use --force.
That makes is basically impossible for you to be a headache.
Use local databases only for testing/dev. Make sure you have a development server ready that's ok to wipe at will (so other devs don't cry about it).
Study their workflow and design process well. Learn DVCS (git, hg) very well and the best practices that come with it (especially branching).
Once you have branching down, you can create your own branches without affecting their work.
Never use --force.
That makes is basically impossible for you to be a headache.
Use local databases only for testing/dev. Make sure you have a development server ready that's ok to wipe at will (so other devs don't cry about it).
I meant it more in a way of things that people think but don't say, not actual abuse. My office is really a great one, but everyone has thoughts to themselves and I want to hear what those thoughts might be.