This summer I was fortunate enough to be granted the opportunity to be a software engineer at Bullhorn. Bullhorn works to improve the experience of the staffing industry with its two main products: customer relationship management (CRM) software and applicant tracking system (ATS) software. As simply put by their mission statement, Bullhorn powers the staffing industry to put the world to work.
Bullhorn was initially based out of Boston and now has offices across the world. However, they recently transitioned to being a primarily remote company, allowing my team to be located all around the globe. Unfortunately, I was remote all summer and only managed to spend one day working in the office. I spent the summer with the builders team, a team made up of software engineers and quality assurance that have recently joined the company. The team shifted around throughout the summer due to workers graduating. I was accompanied by four other interns, all going into their senior year of college. Due to the team’s onboarding aspect, the builders would spend two days a week working on learning new skills, and the other three working on tickets.
The team was led by their manager Charles Thompson, the interns' manager, Adam Crowe, the scrum master, and Tanya Leonce, the product owner. Tanya was in charge of pulling in all the “tickets” (tasks) for the team members to complete. Charles and Adam were extremely helpful when answering questions I had about my work.
The summer started off with a week of onboarding, where the interns learned about the company as a whole and how different sections of the company interact with each other. During this onboarding, the interns had one-on-one meetings with everybody on their team. Later on, we had the opportunity to meet with individuals in other departments with the goal of learning more about different careers we might be interested in exploring.
The builders operated in two-week “sprints.” Sprints were designed to force workers to split up projects into smaller tasks and frequently check to see if new code worked well with the pre-existing code. At the end of a sprint, there would be a “code freeze” which forced all software engineers to stop working on their tickets. During this time, the team would have a “retrospective” meeting where they would discuss how they think the sprint went and how they could improve for the next sprint. After this, the team would play games at a team bonding meeting. The last day of the sprint would be a “regression” day, where all the software engineers in the company would test code to see if new code deploys are working. At the end of regression days, there would be a “sprint planning” meeting, where workers would list their availability and how much work they believe the team could accomplish in the next sprint.
Every week, the team would have a meeting led by Tanya with the intention of voting on how much effort each ticket would take. The purpose of this was to make sure the team didn’t bring in too much work for each sprint. Every morning the team would have a “standup” meeting, where each team member would state what they would work on for the day. Shortly following standup would be “Charles’ fireside chat,” a time for builders to bring up issues they have or discuss recent discoveries they’ve made. In addition to these meetings, interns would have a weekly one-on-one meeting with Adam Crowe and a weekly one-on-one meeting with their mentor in order to receive help with anything we are struggling with.
The interns and I worked on a project with the goal of decreasing the errors logged into the company’s database. Our work would make it significantly easier for the software engineers at Bullhorn to recognize which errors were more serious and which were just taking up space in the company’s error-logging database. We would be assigned research tickets, where we would have to look into the stack trace of the logged error and find the class of code where the error occurred. From here we would have to find out if the error was legitimate or whether it could be downgraded from an “error” to a “warn”. We would then put all of the information and suggestions we have gathered from our research into a google doc. After the doc was submitted, a ticket to make the code changes would be created and assigned to the interns. I was fortunate enough to do both research tickets and code change tickets.
Thank you so much to everyone at Bullhorn, all the Builders, Charles Thompson, Adam Crowe, the other interns, and Mr. Schlenker for making this summer with Bullhorn amazing!
Comments