Reflections, lessons, and challenges from my Summer 2021 Internship
I completed my second Microsoft internship as a Software Engineering (SWE) intern. I wrote a reflection piece for last year’s Explore internship and thought writing one for this year would be fun too.
Like last year (see link below), I will be mainly self-reflecting so my experiences might not apply broadly. I tried to summarize my discoveries and challenges here but I learned so much so it may get a little in-depth :-)
Some highlights were…
- My intern project! I designed and built a Dossier, or customer report, a new feature for the product my team works on. This empowered Microsoft executives (including the CEO) with key data to understand customers in a single page and initiate informed conversations for growth.
- Hosted a workshop for Hackathon week! The organization my team is on has majority engineers and data scientists so I hosted a design thinking workshop for non-designers. It had visibility of 1300+ so it was cool to be able to present about the intersection of something I’m passionate about.
What changed between this and last internship
- Last internship: I spent a lot of time broadening myself: setting up coffee chats, attending intern events, learning how to communicate, and digging into a tech stack I had never been exposed to.
- During the school year: I changed my major to Cognitive Science: Human-Computer Interaction (HCI) and learned a lot about human and community-driven design through research and school projects.
- This internship: I returned to the same team as last year and they paired me with a design-driven development project knowing my major change. I iterated between (1) feature decision-making, (2) UX design, and(3) turning it into code all with engineers and program managers (PM).
Words of wisdom along the way
I always take notes during meetings. Here are some key quotes that I thought offered ideas I hadn’t heard or thought about before:
“A document is never a one-person thing. If one person writes it, it’s an opinion.”
“Before you agree to an ask, always get more information. When you agree, hold people accountable to engage and give feedback.”
“Nobody should go to a meeting by themselves. Always have a second set of ears from your team to listen.”
“Know a lot of things and be humble.”
My discoveries
My manager gave me a lot of project autonomy and flexibility which was empowering and made me feel more like a full-time software engineer.
However, this internship also challenged me deeply in ways I didn’t expect. The following topics are unique experiences I will reflect on:
- Maneuvering variable user experience based on stakeholder
- Balancing excitement, expectations, and timeline
- Discarding the design process
- Becoming a better designer through development
Maneuvering variable user experience based on stakeholder
Background: My summer project was a new feature on an existing product so I was working with a team to dial down on requirements.
Conflict: Key info was missing before requirements could even be made — stakeholders. Because there was context disbursement from meetings held before I arrived, my two directing project sources gave me different circumstances of who the stakeholder was so it was unclear to me who the target was.
Conflict context: On one hand, the personas created by one of my sources were Microsoft executives. On the other hand, the focus groups conducted before I arrived and the interviews I was directed to facilitate were of Microsoft employees.
In seeking out the stakeholder, I consulted my two directing project sources. They all held different roles. One of the the interesting parts of my project was seeing the dynamics and priorities of these roles.
- Project source #1: My mentor and manager had business goals that aligned to the employee stakeholders used the tool by submitting tickets and supporting customer representatives. They posed questions like, “how will this feature change the workload of the platform support team?When choosing items to include, is it better to gave 4 well-scoped out items or 6 less-flushed out items? If the target audience is executives, is it responsible to prioritize support for 1% of the users when 99% others still use it?”
- Project source #2: My PM and skip-level manager had business goals that aligned to the executive stakeholders that conversed with high-profile customer executives. They posed questions like, “when executives view this feature, what story will they be able to extract? Will this summarize the information on the platform so they can see everything in one page? Will executives be able to drive a meeting with a customer using just this feature?”
Process: A 12-week timeline to design and build the feature didn’t allow time to wait for responses to come to me so I jumped into designing initial prototypes and scheduling preliminary interviews which prompted the stakeholder question to be addressed.
I sent emails requesting for interviews with the top 100 monthly users of the platform before and throughout building the feature. Many were excited to chat with me about the tool. However, when requesting to interview executives, they had full schedules and I was only able to speak with representatives of theirs.
Resolution: Through weekly discussion I initiated, I flushed out that I was building for executives on a platform with majority non-executive employees who would still be able to use this feature once shipped.
Conclusion: While only executives could use the feature as a whole since they were the target audience, at the end of usability testing I discovered at least 1 item of the feature was useful to the 20 non-executive employees tested. One of the devs on my team helped me recognize this work was the foundation of a long-living feature that would continue to be iterated on.
I’m satisfied my project met the needs of who I discovered to be the key stakeholder while still having the potential to simplify workflows of tens of thousands of non-executive employees.
Balancing excitement, expectations, and timeline
Background: I wanted to exceed expectations while not overpromising what I would deliver. As I made progress on the project, enthusiasm and visibility for the feature grew among the leadership team which was exciting.
Conflict: Because of new visibility during the second half of the internship, there was pressure to add deliverables which would conflict with timelines at a point when core requirements were already discussed and confirmed.
Process: Before giving estimated development timelines, I set aside time to sandbox the codebase to get a more accurate idea of how long it would take to complete items. Based on the first half of the internship, my estimates were usually true to how long it would take me to finish.
When new requests started coming in, including some that were contradictory to the current ones, I felt like I was spearheading design, development, meetings, and prioritization more than the project team contributing to a collaborative discussion about items aligning with time left.
I expressed my reservations about too many new requests. My mentor helped me frame discussion for reeling excitement into focusing on the larger MVP picture and asking for justification of additions rather than just agreeing and therefore overpromising. My manager helped delegate design and PM tasks so I could focus on coding rather than juggling multiple.
Resolution: As a result of communicating concerns and discussing items instead of overpromising, I was able to meet the MVP and some stretch goals.
Conclusion: As an intern, I wanted to fulfill every request to make everyone proud, which put pressure on the timeline. My mentor and manager set good examples of how to negotiate new items and initiate discussions but I still have a lot to learn.
In retrospect, I would have had the parties with new or contradicotry requests to decide among each other instead of being the one balancing and trying to meet both needs. I also would have been more blunt in what timelines could be met and backed it up with reasoning from user interviews rather than changing requirements just because someone higher up asked.
Discarding the design process
Background: In school I learned that usually the design process goes somewhat like:
empathize → define → ideate → prototype → test → build
Conflict: I was both designing and coding the project so my timelines ran in parallel. There was no sequence of the design process — it meshed together.
Conflict context: On the same day, I could be designing based on surveys, receiving feedback at a meeting, conducting a user interview, and pair-coding to get help through a new concept. I had coffee chats with designers and asked if they ever actually do user interviews, prototypes, testing, and truly found the right problem before handoff like idealized in school but they all reflected they aren’t given enough time. As someone needing time for both design and development, I felt that.
Process: It was difficult to test since low-fidelity sketches didn’t convey or seem “real” enough to garner feedback from the teammates and users I was working with. Yet with only survey data and without a base design to view, project team conversations would digress or not lead to a conclusion.
High-fidelity prototypes moved the process forward to be able to have development specifications but also lead to nit-picking due to the look of “completeness” but with slight errors since it was still a rough design.
Going into interviews, I had a framework of questions to ask and prototypes to introduce. However, because the tool was a living platform, many users that had been trying to contact the team understandably came to meetings with their own idea of what could be improved rather than the new feature.
Resolution: Interviewing, prototyping, and testing was more challenging with rapid deadlines and iteration than what I learned in school but as I got practice transitioning requests and interviews to a design, I was able to fulfill all the aspects of the design process. At first, it required skipping steps just to get to a stable place between design and development timelines but I learned the steps I’ve been taught in school are important but can be interchanged.
Conclusion: Listening to product frustrations helped me understand what needed to go into the project, even if it didn’t translate directly. I felt like a true designer navigating the real world, non-idealized design process.
Becoming a better designer through development
Background: My project was front-end heavy so I would spend a while waiting for code to compile just to see a visual change.
Conflict: Compilation usually took about a minute: too short to move to a new major task but too long to do nothing.
Conflict context: The time I spent waiting for code to compile added up so I had to find something to do. During these pockets of time, I did top-of-mind project actions like, considered how data could be displayed, performed short queries to see what data was available, or determined how difficult it was to fetch a new stream or port one from a different team’s data.
Process: Usually, prototypes made for the project would be created based on needs found in surveys and interviews that used data of the existing UI only. However, since I had access to the code and database, I could view all data coming into the platform rather than only what was displayed. I was able to cut out the usual design → development middleman of asking then checking to see what data is available by simply inputting the data into my code and sandbox whether it could be useful or bring it up in discussion.
Resolution: I turned weeks of waiting to see visual changes compile into time to let code, data, and design ideas marinate in my head. The thought process felt far more thorough when it was lengthened from a few days of prototyping to iterative weeks of tightroping between two contexts of design into code.
Conclusion: It felt empowering finding new potential ways to display or data to add that couldn’t be discovered by only making basic prototypes and viewing the existing platform. I’ve met designers that know how to code, developers that understand design, and heard about the intersection but never really experienced the perspective and fluidity between them. However, the difficult part was being able to gauge how much time each took since I was a one-person-band working on both.
What was difficult
- Pair-coding was extremely slow via screen-sharing
Technical difficulties seem to be a hallmark of remote work/learning but getting code help was infinitely more difficult when screen-sharing. It would make my computer extremely slow and remote-control would make other devices keyboard settings everyone’s keyboard settings when pair-coding. The only solution was patience which wasn’t easy with a tight schedule.
2. Time-zone differences and language barriers
The platform my project was on was used by people all over the world, often in opposite timezones or languages other than English. Scheduling and conducting interviews was different than what I was used to since I would convert the time and wake up 4 AM — 6 AM to meet by the end of people’s work days. Real-time translators were sometimes needed too. These added an interesting layer of consideration to interviews and interface wording.
3. I didn’t always feel supported
My project combined many aspects of the existing platform, so to best represent those aspects, I would arrange meetings with owners of different features. Even when I would adjust to their time-schedule as much as possible, they were still busy people.
At one point during a meeting when trying to explain what I needed, I was cut off and told to stop talking. While this blunt instance only happened once and a lot of others were really supportive of my work, I didn’t want to add pressure to other’s day so I was worried it would happen again. I asked for advice on how to respond to the situation in the future and thought this was a polite but informative way to handle it:
“When I expressed enthusiasm for the project, your mode of communication was not inclusive. I acknowledge you are busy so if this project is you’re okay to contribute to, let me know.”
What went well
- Took action on constructive feedback every week
Every week through both last and this internship, I would specifically ask for what I could improve on. I feel good that I continued to consistently look for improvements and week after week was able to explain what actions I took to work on my weaknesses to my mentor and manager during 1:1s .
2. Didn’t overcommit to meetings, therefore avoided context switching
Last internship I went to a lot of meetings since I wanted to know the ins and outs of everything happening in the team as well as ended up over-decision making on that project. This time around, I prioritized meetings toward the afternoon after morning focus time so I got a lot more done around my productive hours which worked out really well.
3. Asked difficult questions and continued to politely follow up until I got sufficient answers
Last internship I faced difficulty not getting responses after one message. In fear of “bothering” someone, I wouldn’t send a follow up even if they responded but didn’t give an adequate answer. This would lead to tasks not being completed from lack of info. Through this internship, I understood that I was there to do a project and without answer to the questions or info I needed, I would not be able to do my work as well as possible! It was a win-win learning to follow up.
That’s a wrap!
My reflection doesn’t apply broadly to everyone but I really learned a lot and had a lot to think about. The internship taught me a lot about projects, collaborating with full-time employees, and honed my design and development skills further. I’m glad I was able to overlap a lot of the skills I’ve worked on through my classes into a real project.
My senior year
On a personal note, spending time on experiences is really important and if you can make time to go outside and appreciate a sunset, it’s really nice. Before I graduate I look forward to exploring San Diego, fostering kittens, and taking some recreation classes like surfing and archery. Here’s a reminder to take care of yourself through pictures and music that make me feel alive:
Runaway by Yetep, True Feeling by Galantis, and Look at the Sky by Porter Robinson
I appreciate
I am grateful for my mentor Michael, my manager Jason, my former mentor Vivien, my team members Ore and Minjing, and the designers and UCSD alumni that made time to chat with me.
While I learned a lot from the internship, I continue to acknowledge how grateful I am to have this experience and that I didn’t achieve this alone — my friends and family have been amazing and I recognize there are some parts of my life that I cannot control that have nonetheless helped me get where I am today. If you are a UCSD student or have any questions, my inbox is open. I also created an in-depth guide for UCSD students new to design.
