What did I learn/do differently this internship?

I spent the summer in the San Francisco Bay area, Sunnyvale to be precise. I was interning at Mercedes Benz R&D and had a significantly different(good different) internship experience!

What did I do differently/What did I learn?

1. Turned on extrovert mode: An internship or experience can become incredibly more fun if one can relate to other people in the same endeavour. I was marginally more successful at this since I took a voluntary effort to talk and I must say it paid off very well. I once used to be the person that would work hard at their desk, expecting the work to speak for itself. However, it seems like a great deal of perspective and ownership comes from feeling part of the team. To this end, I made a point to break ice, and my favourite lines were ‘We haven’t met’, with an anticipatory tone. Jokes work well too. Trying this was much fun, at the cafeteria, before meetings, at the pool table, at lunch, etc. I made it a point to sit with different sets of people and talk to different sets of people.
2. Ask questions wrapped as conversation: Asking questions can be very rewarding. The perspective you get from speaking with people who have experience in the industry cannot be obtained by reading about the same on the internet. If you get a chance to intern, make sure you talk to different department heads and engineers about what they’re doing, how they’re approaching problems and what their major challenges are.
3. REQUIREMENTS!: Matching requirements and expectations can make or break a project: As an engineer you’re always developing products that somebody uses, be it another team in your organisation or the end customer. It is important to match expectations with your customer and constantly engage with them to understand their priorities and how your product fits in the context of the whole project and how it serves them. This helps you in making decisions better, and moving towards building something useful rather than something that other teams have little clue about or cannot use.
4. Reading papers: My area of interest is machine learning which is a constantly evolving field with bubbling research. It is important to keep track of the state of the art, new ideas and methods so that you can implement them in your project when required. Recommend reading a paper a week. Settling in a new industry and gaining a high level understanding of your problem statement is sped up by reading papers.
5. Handling code reviews: Code is read and used more often than it is written, hence it is important to be optimal and clean to the last bit. Handling code reviews was a major task in my internship experience, and if I expect a task to take 1 day to implement, I alloted it at least 3 days until merging into production code. This helped me plan and anticipate better. Handling code reviews was a major learning experience since it forces you to produce the most optimal implementation of code unlike in university where a working version is good enough.
6. C++ is king: A lot of software in industry is written in C++ and even if you’re a machine learning developer in love with Python, driving your projects to deployment requires solid software development skills. Having a full stack skills helps one be more independent(since one can handle a project to delivery) and fast(between prototyping and deployment)
7. Technical responsibility can be nerve-wracking: I worked in predicting intents for self driving cars using deep learning methods. In college if you get a low error percentage, you have a beer and publish a paper and have little stakes. But in industry, when your car is going to be on the road interacting with real people, that small error becomes becomes consequential. The possibility that people may be hurt because you didn’t try out something, or spent more time at it, or were suboptimal is a lot of responsibility.
8. Adaptability of machine learning methods: Accountability is a major factor that limits the use of ML methods in real world applications. For example, a heuristic planner can be easily tested and one can deterministically point out which line of code causes the bug. In that sense, the iteration and bug fixing cycle for heuristic planners is shorter and deterministic. However, with an ML system, one cannot point out what the cause of error is, for example, ‘this neuron is causing us to detect the light incorrectly so lets change its activation’. This means that developers cannot do much about the errors of a deep learning based system, the least they can do is retrain with more data and hope that that mis-detection does not happen again.
9. It’s important to have fun outside work as well as love what you do at work, obviously. Need to strike a good balance to remain sane for the long haul. Travelling or sports with your team mates helps you get to know them beyond their personas at the office.
10. Negotiating and asking/collaborating: I had taken a negotiation class in spring which taught me that you need to ask in order to get. This was good advice, I asked more often and was able to balance relationship and objective during each negotiation.
11. Being professional, aka retiring the ripped jeans, tardiness, pranks and cuss words :|
12. Look for chances to collaborate: People like being helped. So try and be resourceful, ask for work, offer to help set up their computers, fill in for an absence or take on new tasks!
13. There is going to be dead work: Some of your work can be a drudge. The best way I learnt to handle this was to power through it so that I can get to the more interesting bits. It’s going to be comfortable to lose yourself in a mountain of drudgery(especially if you’re in ML aka pre-processing) but fight it.