西窗月

Intern Life in the Bay Area

I worked in the bay area for a cloud database team in the last 12 weeks. It is my first time to work in
a real industry company. Life is quite different from grad student’s life at school. Just leave some brief notes here.

meetings

Scrum meeting: The team usually has a scrum meeting every morning 9:30am. Every one will call in the Chime meeting. The team members usually mention three simple things: what’s your progress yesterday, what you plan to do today, and anything you need help from the manager or other team members. Just several sentences is enough. This helps the manager keeps track of your progress, and can help if you need. If something worths a longer talk, the manager will talk to you later in the day.

(Since it’s pretty early in the morning, most people are still on the highway, and it’s kind of dangerous to meet and drive at the same time, the manager change the time to 10am later.)

I like this scrum meeting, it’s not like a formal meeting that you need to prepare for a long time, but you can get real-time feedback and make the goals very clear every day.

1 on 1: As an intern, the manager pretty much does not count on you for anything. You need to schedule a 1-on-1 meeting with the manager. At first, I was too shy or scared to schedule a meeting with the manager. However, I do find it’s pretty chill. Just send a calendar invitation. The manager actually like motivated persons. We have 4 to 5 talks during my 12-week internship, and we talked a lot besides the internship work.

On call

On call is the thing most engineers complain about. Since AWS does not have a dedicated team for on-call, the team who develops the code owns the code - all the team members will on call intern. If it’s a small team like 5-7 members, you will have this every one or two weeks.

I learned that they do have on-call team in Ireland or somewhere else to mitigate the workload.

The on call was divided into two levels, primary on call and secondary on call. Primary-on-call is responsible for a whole day, 8 am to 8 am the next day. If they can not solve the ticket in 20 minutes, they pass it to secondary-on-calls. So the primary-on-call needs to solve many common problems or easy problems, with the help of knowledge base or on-call wiki.

Secondary-on-call duration is for one whole week - they need to solve some problems that primary-on-call can not solve in a short time. They usually need more investigation.

Overall, the on-call workload is pretty high. That is not the fun part. I asked my mentor if they have some tools to help them with the on-call work, since most time the diagnosis rely on coredump and gdb. The mentor told me they were trying to automate some solutions from the wiki, but they still need much human effort.

Design

My project was not very well designed in the beginning. So I need to work with the mentor and PE in our team to define the work until the third week of the internship. Later, I spend tons of time writing the docs about the design and start the implementation around the sixth week. Since the software I worked on is still close-source, I don’t think I should touch the details of the code. However, I feel that the overall design is made by higher-level engineers (like Principle Engineer) or the managers, while the micro design for the implementation is determined by the SDEs. The scope for the SDEs are still very limited.

Bay area fun

TODO: I will probably write more things about travels in the bay area when I’ve got more time. Most pics are on the instagram.