As an Intern: Why should we keep you?
I believe you are not “less valuable” just because you don’t have much experience in the field (yet). Everybody provides different values to the team.
The one thing you can always do is save people’s time. During my internship, I follow these two principles:
- Do not waste people’s time. Save people’s time if I can.
- Deliver work that’s valuable even after I left the company.
Here are a list of things I did besides coding:
- Check before I go. Stop if I am not sure
- Talk in bullet points
- Do what I think would be nice “if someone did this”
- Make the most out of my problems
Check before I go. Stop if I am not sure
Never have assumptions. You never know what you don’t know until you ask.
When I got a new ticket, I will clear any questions I have with the ticket reporter:
Hi <reporter>, I am working on <ticket with links>. I noticed there's a similar feature to this: <feature>. They both seem to be doing <function> to me. May I ask what's the difference, please?
Before I start coding, I will list my building steps and verify them with a senior developer:
Hi <senior developer>. I am working on a ticket about <the problem with links>. My thoughts are: 1. <implement something> in <module> 2. <change something> in <file name> Is there anything I missed here? What do you think?
When I am stuck, I make sure I tried before asking for help:
Hi <senior developer>, I am working <the problem with links>. I am not sure how to <things I am stuck on>. I have tried: - <A> by <doing what> - <B> by <doing what> Can you give me a pointer for this?
Whenever I talk to someone, I make sure that I:
- Ask for pointers, not answer.
- Describe the feature at a very high level. Digging into the files is your job, that’s why the ticket is there.
- Elaborate when needed to save people from clicking.
- Break lines so it’s easier to read even on a smaller screen.
- when asking more than one questions, numbered them so people can reply with “1: I think…” instead of repeating your words.
Talk in bullet points
Since we are working remotely, we use text for communication. I am not a fan of reading myself, so I try to use the least amount of sentences and talk in bullet points.
I edit my message before sending them. If more discussion is required, I ask for a quick call and send a “call summary” afterwards so we both know we are on the same page.
Do what I think would be nice “if someone did this”
I leave a “ticket summary” on every ticket I have worked on. Each summary consists of a video demo (instead of using a looping GIF so people can pause it), what this ticket does (new functionality or fixes an issue), what and where I changed in the codebase.
The benefits of doing this are:
- The business team can see what the end result is like.
- My work is now “faults traceable”. If something breaks, everybody knows where and how to fix it even after I left the company.
- Developer who is more experienced can drop their feedback whereas developer who is less experienced can see how the problem is solved.
Make the most out of my problems
I keep a document with issues I faced along with the solutions. I share it with my peers so that senior developers don’t have to answer the question over and over again.
I ask questions in both channels and through DMs (we use Slack). I make sure I mark the question as “solved” and append the answer. Therefore, my colleagues know the issue is solved and others can search through the chat further down the line. I also created a “seen but not sure” emoji to inform my peer that I am not ignoring them. I am clueless too.
I received a returning offer after my internship, so I guess they worked?