Learning experiences in the TNT internship that I plan to transfer to my courses

This week, we are working on our team project, a web application to enable college students to access health information and costs. While working on hooking up the redux to implement a cost filter for the project, I appreciate the willingness of instructors and fellow interns to help when I reached out to them, asking for help regarding redux.

It has always seemed wrong to be a Computer Scientist and reach out to someone, be it a peer or professor asking for help. One answer I am always afraid of is "Google it." The uncertainty of whether my question will attain a "Google it" answer always stopped me from asking for help.  

 Although Google might have answers, the explanations I got from peers or instructors at my internship are detailed and made me understand how to approach a similar bug in the future. A detailed answer is much better than a mere copy and paste of a stack overflow solution. Moreover, from my internship, I have learned that people would love to help out. Additionally, it derails a project's progress to spend an hour resolving a CSS style, yet a teammate can reach out and help devise solutions to the bug in less time. 

After this internship, I will feel confident to reach out for help. Reaching out to ask for help during the internship has equipped me with effective communication skills because I have learned how to ask the right questions and developing clarifying follow up questions to enable the responder to know how to help. Effective communication is a crucial skill that I will apply in my different projects in and out of class after the TNT program.

A Stated internship goal that I achieved this week

One of my stated goals for the internship was developing my interviewing skills, both behavioral and technical.

One crucial aspect of the TNT internship program is the mentorship that connects New Technologists to software engineers at Microsoft to discuss with different topics aimed at fulfilling our internship goals. During my first meeting with my mentor, I explained how I felt so uncomfortable with behavioral interviews. Although I had experiences to use for the behavioral session of the interview, my mentor and I used the mentorship sessions to practice sample behavioral interview questions to support my confidence in expressing my experiences. My mentor discussed the use of the STAR method to use in behavioral interviews and how to use it to stay organized during behavioral interviews.

STAR is an acronym for Situation, Task, Action, and Result of the experience. This method is widely used in behavioral interviews for interviewees to express their experiences to recruiters in an organized way. It highlights the experience, the role the interviewee had in the experience, and the result of working on that specified task.

To better prepare for the interview process's technical aspect, this week's Pizza and Personal development was focused on technical interviewing, where we had a university Recruiter at Microsoft give us a sample technical interview session. This session included building algorithms to solve different questions and test cases for the solutions. This session much prepared me for the next technical interviews. 

For the remaining parts of the internship, I hope to continue networking with other software engineers at Microsoft to learn more about the recruiting process and better prepare for behavioral and technical interviews. 

Lessons from a coffee chat with Mr. Harry Ferguson

Today I had a coffee chat with the Principal Manager of SharePoint's Cost of Goods team, Mr. Harry Ferguson, after an introduction email from my mentor. The meeting's primary goal was to discuss what COGs or Core is and the different fields in Microsoft beyond software development pursued with a computer science major. 

We discussed the roles of server management at Microsoft, like analyzing the different server requests made, optimizing the server resources available to support these requests, and prioritizing tasks according to the performance required and the cost of providing those services. 

Furthermore, we talked about the roles of managers versus the roles of engineers, where Mr. Harry talked about how the manager's role is more of providing direction for the people, shielding the team managed, driving meetings, and understanding enough with less information but being able to make a decision. 

Additionally, I asked Mr. Harry, as a manager who has spent decades of years in the workplace whether it is better to immediately pursue higher education after school, before starting a career, or earlier on in the career journey or pursuing the workforce directly. 

As we discussed the appropriate time to pursue higher education, Mr. Harry elaborated on how the time required for higher education, if spent in the workforce, can yield career growth than if spent at school. "Afterall, the workplace knows that what is taught is different from what is required at work!" Mr.Harry exclaimed. From work experience, Mr. Harry elaborated on how, if  I am not interested in pursuing academia or Research, then seven years spent pursuing a Ph. D. degree will not contribute to my career path.   

Unit testing with Jest

Today in class, we discussed unit testing in great detail. Unit testing is an automated testing technique to check how different units like methods of classwork with different inputs. One remarkable importance of unit testing to new developers is the confidence to update code after proving that the small units pass all the tests. 

During my Software design and Implementation course, we talked about unit testing with Python; we wrote different test cases in a file that imported the file to be tested. However, one thing that shocked me as we discussed unit testing today is the fact that test cases are written before a developer begins coding. I have always thought that tests are written after coding the different functions to ensure that the units under test run as expected. Although this was not far from the reason why tests are written before the code, the aim of writing tests before coding is to enable the developer plan for the different boundary conditions included in the test cases before, they write the code. 

To unit test our ReactJS projects, we used Jest, which is a command-line JavaScript unit testing framework by Facebook. With Jest, each file.tsx had a corresponding file.test.tsx that contained all the test cases for the application. A fascinating feature of Jest is the ability to unit test the UI through the command line by enabling the creation of a Document. This is an excellent feature in web development because it eliminates manual testing of different buttons' actions.

How my CS work has influenced my internship experience

For the engineering curriculum this week, we worked on developing the UI design and enabling navigation for a web application that enabled community members to borrow and lend different items among themselves. In a team of five, we planned out the agile development process for developing the web application like splitting the different roles, creating a GitHub project for the web application, using the Kanban board to track our progress, and working through the project from planning to developing the UI using React JS. 

This process related to the Group project experience I had in the Android Development course I took last semester, where we worked on an Android Application from sprint planning to implementation. As taken last week, the steps taken during the Android class involved thinking of the different engineering roles expected, prioritizing these roles so that we begin with the roles with the highest priority, set up a GitHub project with a Kanban board for tracking progress, and then collaborating on developing the project. This class greatly prepared me for this experience.

Additionally, the different class projects done during Software Design and Implementation and Data structures also taught me how to navigate team dynamics. Good pair programming skills, like writing proper commit messages and working on different GitHub branches instead of the main or master branch, we practiced in these courses is what I am applying in my internship. Soft skills like asking my teammates questions when not sure about something, live sharing code, and resolving merge conflict have also contributed to my internship experience.

How my perception of Project Management work has changed since I started my internship

    At the start of the internship, I was confused about what to expect from the Project Management curriculum because it was a Computer Science field that was new to me. Although I had worked on a couple of individual and group projects, I had never gone through a detailed product life cycle.  From defining a problem statement, developing personas for the problem statement, conducting user ability studies, brainstorming viable solutions to the problem identified, developing product walkthroughs, and then developing a minimum viable product. At the start of the internship, I wondered why we had to go through this entire process, yet we could spend more time thinking about developing a web application.

     However, with time I am appreciating the efforts we put in to the project Management curriculum 

because it is useless to develop a product for a target audience that you have not analyzed to know what product would best solve the challenges they are facing. The daily meetings with our team PM coaches also greatly helped elaborate on how the different PM steps we were taking would relate to the final project. This week as we worked on our product specification, which is a combination of all our findings throughout the project management phase, I was why we were developing our web application and what engineering requirements we needed to implement our solution.

    It has been a journey, from not knowing much about Project management and agile development to appreciating the impact of spending time in the project Management phase before engineering a product. The more quality time we invested in the project management phase, the more relevant the engineering solution is to the problem being addressed.

How I am meeting my internship goals

    Beyond improving my technical skills through web development using ReactJS, my major goal for the New Technologist internship is mentorship. This mentorship includes networking with both engineering and non-engineering staff at Microsoft, knowing the day-to-day activities of a software engineer, and the mission of the Company. 

    Last week, I had a meeting with one of my Project Management coach, who has worked in both engineering and Project Management, to discuss her experience of Project or product managers at Microsoft and how entry-level Software engineering positions at Microsoft are.

During my 1:1 sync with my mentor, I requested my mentor to make introductions to some of my mentor’s networks working with Cloud, Microservices, Mobile, and Web development at Microsoft. These meetings will be a time to not only ask about what roles they do but also know the day to day activities in these roles. Furthermore, they will be an opportunity to learn about the work culture at Microsoft.

    Additionally, during the Pizza and Personal Development session today, we had the Corporate Vice President of Substrate Platform share the work culture at Microsoft and how the various internship projects we are working on fit in Microsoft’s mission: to empower every person on the planet to achieve more.

    Although I would have easily and traditionally achieved my goal above had the internship been in person, I am working around my virtual internship office to reap the same results. These meetings have been an opportunity to achieve my mentorship goal. Part of my technical development included developing a web application using ReactJS and Typescript, which I hope to meet in the next weeks of the internship.

An incident that caused you to question your previously held assumptions

“To join the work industry, I need to discover a specific field I am interested in,” I always thought.

I questioned this assumption on Friday during a Pizza and PD session. Pizza and Personal development (Pizza and PD) is a one-hour meeting held every Friday where TNT interns meet with Microsoft staff to share their personal experiences and development tips with the interns.

This Friday, we had a diverse group of Microsoft staff, ranging from the Chief Information Security Officer to Senior data Analysts and Project managers.

In response to one of the questions, most of the panelists explained that although they have worked at Microsoft for more than a decade, they are still discovering their passions and the different ways in which they can make an impact. I wondered what kept them motivated to work if they are still finding their passion. The panelists talked about how the ability to try out different challenges, and the people they work with are their greatest motivation to work at Microsoft.

As a rising sophomore, I have taken a handful of Computer Science classes to declare and commit to a specific career field currently. And maybe the expectation that I will know this field when I am a senior might also be incorrect. Being passionate about a continually changing field like Computer Science should be an indication that my passions will change frequently. 

During this Pizza and PD, I question whether I am required to have a specific field in figured out before joining the work industry, as I have always known, or adopt a growth mindset and look for people that will support my growth.

Ways my team is keeping track during the internship

During the internship, we work in teams of five, and we accomplish 80% of all tasks in these groups. 

On the first day of our team meeting, we wrote team rules of engagement and pinned them at the top of our Microsoft Teams files. These rules outlined our goals, reactions to stress, and ways to speak about team conflicts.

The rules of engagement have helped us proceed through both the Software engineering and the Project Management aspects of the internship. Furthermore, understanding how each team member responds to stress has been a crucial tool to use, especially when working on potential stress causers like decision making between two ideas that the different team members like. 

Additionally, we set up a GroupMe chat outside the internship to communicate quickly and have a less formal way to talk about the challenges we are facing, share some fun memories as a team, get re-energized, and work better. Through this chat, we reach out for help concerning the internship assignments, code bugs, or something that was not clear in the classes so that we all keep on track. 

I have found using this chat more convenient whenever I need help to debug my code or resolve GitHub merge conflicts compared to sending an email.

Furthermore, we have the support of our team’s coaches with whom we meet daily to discuss the progress of our project. During these meetings, we receive tips on time management and handling team dynamics, which has helped us discuss ways to keep our team on track during the program.

As a team, we also set time blocks to accomplish different tasks and take breaks from work. Setting the deadlines to accomplish certain tasks has greatly enforced our focus, and planning for break time has eliminated burnout. 

To say that we are always on track as a team would be a lie. There are days when we were behind the schedule of the Project Management curriculum. However, talking to our coaches and time management tips are given helped us catch up with the rest of the program activities.

Differences between my internship and class projects

As I continue with the internship's engineering projects, I am noticing how understanding code written by someone else is critical in software engineering. Unlike most of my Computer Science classes where I write code from scratch, I am working with already written code at my internship.

This difference is because the objectives of classwork are to understand and apply concepts and, hence, requires the development of a project from scratch, unlike an internship, whose objectives go beyond individual application of coding concepts to how well one can collaborate on a team project and resolve merge conflicts. 

Additionally, in the industry, software engineers' roles are to maintain software that is already in use and does not require building from scratch but instead updating existing features, so we must learn such skills in an internship.

During this week's conversation with my mentor, we discussed the importance of proper code documentation for future software engineers who will need to understand my code to update certain features of the project I work on. Furthermore, my mentor told me about something called "being on call" which refers to a software engineer providing technical support for 24 hours, and the ability to understand code and debug it is an essential skill for this time.

Whenever I worked on my projects in classes, I never paid so much attention to code documentation like comments or commit messages like I am during my internship projects. I appreciate the fact that the code's quality is determined not only by its ability to run without breaking but also how adequately documented it is.

MY BIGGEST CHALLENGE AT TNT PROGRAM

In the second week of the TNT program, we learned React and Typescript. Although the engineering work still requires some time to comprehend, my biggest challenge with the internship will be the Program Management curriculum. 

The Project Management Curriculum is a 3-week course explaining the roles of project managers and the phases of design thinking. It comprises of individual and Team assignments ranging from developing a problem statement to identifying a viable solution. Our daily PM sessions include an hour of individual study of the curriculum, followed by an hour of discussion with our PM coaches about these aspects.

However, the PM curriculum is still a challenge because the concepts are utterly new to me.

 The only previous experiences that I closely relate to the PM curriculum are the individual and team project planning sessions we have during CSC courses at Berea. I am applying the communication skills from these experiences to the PM curriculum.

As we dive deeper into the program, I appreciate how vital it is to understand the product lifecycle. As a Computer Science student, it is easy to rush to the prototyping and testing phases of design thinking and neglect other crucial phases of product development like empathizing, generating, and ideating.

My strategy to overcome the curriculum's alienness is to utilize the team sessions with our PM coaches to understand the different aspects of the curriculum that I do not understand when I read alone. Additionally, I will seek clarity from my teammates about aspects of the team PM assignments that I do not understand.

Git and Github

In class today, we talked about git and github. I always find it hard to distinguish git from GitHub clearly, but for the first part of class, we used git without GitHub and then incorporated GitHub later, which made the difference very clear. 

As we studied in CSC 226: Software Design and Implementation, git is a distributed version control software that makes copies of the project directories at different timestamps, compares them to the initial directories, and saves the changes. Unlike centralized version control systems, git eliminates having one central point of error because it is distributed. The distributed version control system enables each user who clones the project files to have a copy of the entire project.

Whereas git is the actual version control system, GitHub is a website service that provides remote storage of the local versions of the repository.

Additionally, I learned how to write good commit messages. When I used git in CSC courses, my commit messages are always in the past tense, such as “Added file2 to repository”. However, a good commit should be in the imperative mood; that is, it should be able to answer “If applied, this commit will….” My previous commit message would translate to “Add file 2 repository” When I read this, I wondered why the imperative mood was preferred to the indicative way because at the point of writing the commit message, I have “added” the file. This is best justified when we make a pull request on GitHub, the commit is never “merge changes requested” but rather “merge changes request” hence git uses the imperative mood whenever it creates a commit on my behalf, so should I in my commit messages.

BIBLIOGRAPHY

Chris.beams.io. 2020. How To Write A Git Commit Message. https://chris.beams.io/posts/git-commit Accessed 2 July 2020.