Ever since I was a kid, I loved puzzles. Little did I know it would turn into a love for computer science. This summer, I was lucky enough to experience new puzzles and challenges in computer science through my internship at Bullhorn.
Bullhorn is a company that focuses on creating software that helps to improve the staffing industry. See Marcos Ramos’ blog for more details on Bullhorn as a company.
Throughout my time at Bullhorn, I worked as a software engineering intern on the Builders Team. The Builders Team was made up of interns and software engineers new to the company. Our team was overseen by Rohit Mahatma, our manager, and the intern manager, scrum master, and technical lead, Adam Crowe. Adam oversaw my onboarding, often checking in to see how I was adjusting. We then had weekly meetings where we would check in and I could address any questions or concerns I had about my ticket. There were five other interns, one of them being Marcos Ramos—my Rivers classmate—and the rest were either in college or had just graduated. I would often collaborate with them when working on similar tickets, getting insight on what it's like as a computer science major in college. On top of this, our team had two quality assurance specialists who helped with test plans and ensured our tickets met company standards.
My first week at Bullhorn was all focused on onboarding. After I was able to get my computer setup, I started to get to know more about Bullhorn as a company. This consisted of daily Zoom meetings where we heard from different departments explaining what their job was and what they do. By the end of the week, I felt comfortable saying that I knew what Bullhorn did as a company and that I understood their company values. Additionally, I started attending the Builders daily “stand-up” meetings and getting to know all my teammates.
For the next two weeks, new members of the Builders team worked on learning paths in Udemy that taught us the coding languages and frameworks that Bullhorn uses. With these courses, I learned how to code in Java and Typescript, as well as how to test my code in Protractor, Webdriver IO, Selenium, and TestNG. In addition, I became familiar with the Angular coding framework and how Bullhorn approaches automation testing. When I began working on tickets later on I often reviewed these courses when I needed a refresher on a coding language, framework, etc. However, some of the most valuable learning paths weren’t about coding but how to be the most productive when working from home or an in-depth explanation of the Scrum framework, which is a framework that emphasizes teamwork and flexibility in responding to changes.
Once all the learning paths were complete, it was time for tickets. Every two weeks, at the beginning of each “sprint”, the Builders Team would be assigned tickets that addressed product bugs or other tasks, such as automation testing, to their ticket board. Members could then “pick up” these tickets and start working on them. Although the Builders Team usually worked on development tickets, most of my tickets focused on automation. Because of this, I was able to get to know and work closely with the automation team. My first step was to recreate the test I would be automating manually so I would get a sense of the code I would be creating. After this, I worked with the automation team to create a test plan. Once that was complete I began coding. This included looking through the automation repository for other peoples’ code I could reuse, while also having to add new code on my own. This could be time-consuming, depending on how difficult the ticket was. Once the code was complete I had to make sure the automation would run successfully through Webdriver IO. After all of this, I would create a merge request so other engineers could approve my code and I could merge it onto the automation repository. Overall, I found working on these tickets very rewarding, always having a new puzzle to solve. At the end of every “sprint”, there was a “code freeze” where software engineers would stop working on tickets and merging any new code. During this time, every team would be assigned regression testing, where teams would test tickets that were merged that sprint. In the afternoon, the Builders Team would have a retrospective meeting where we would talk about what went well and areas of growth from our most recent sprint. We would then use this feedback for our next sprint. On top of this, we would play some team bonding games such as code names. I found that I got to know my teammates better through these exercises.
Throughout my two-month internship at Bullhorn, I learned the importance of teamwork in the workplace, taking ownership of my work and the deadlines that needed to be met, and practicing other skills that will help me in the future. Thank you so much to Adam Crowe, Rohit Mahatma, the rest of the Builders team, and Mr. Schlenker for giving me this opportunity and for all your support!
Comments