Why we extended all our co-op terms in 2021

In all the tech organizations I’ve been in, we’ve always had a good co-op program. Generally, we prefer the 8 month vs the 4 month for a couple of reasons.

1. It takes a while for co-ops to ramp up, and they usually hit their stride to the tail end of 2 to 3 months
2. We want to invest in them, just as much as they invest in us ~ 8 months is a long time, especially when you are eyeing a graduation date

As we were preparing to go thru our planning for the next round of candidates, one of my managers suggested if we should extend our existing co-ops.

Our 2021 co-ops were all stellar, so of course we would want to extend them. On the surface, I didn’t think they would go for it, as that would be another term or 2 that they would miss from school.

When the first person said they were excited to re-join, we said, let’s ask all of them. And sure enough all 5 wanted to stay on. I have had co-ops extend before, but never all of them. I wanted to dig into this and see why, so I asked them a few questions, and this was their feedback:

Why did you extend your co-op?

Dishant : I loved working with the PWRfleet team and am proud working on different workflows including CI/CD, monitoring and Site Registrations. I was never treated as a co-op student but was more treated as a Backend Engineer that forced me to continue working with this team. I was feeling like I am growing together and getting adequate knowledge on copious stuff at a time that forced me to extend my current co-op term.

Kobe: My team has allowed me to make mistakes, without letting me get away with keeping the mistakes. If a pull request of mine has an issue, my teammates will suggest a fix and expect me to implement it. If I don’t understand why something is an issue, they’ll explain their reasoning. I still feel like I can learn a lot working here.

Arya: I have worked on many interesting projects, but feel like there’s still a lot to learn here at Generac. My current team lead is a great mentor and someone I’m really happy to learn from. I think extending my co-op term allows me to further develop my skills and really expand my knowledge in DevOps. Interning at Generac has been a valuable experience and I’ve really grown a lot to where I am today.

Thomas: There is still much more to learn as part of the PWRview team and at Generac in general. We are bringing about various improvements and new features to the backend of the application and I am excited to contribute and learn as much as possible.

What do you like most about your team?

Kobe: They don’t treat me like I’m just a co-op. The items they have me work on are just as important as what the others on the team are working on. They’re also willing to help me out whenever they can, so I don’t need to be worried about getting blocked on anything.

Thomas: I feel like I am part of the team and not just an intern or co-op student. They were patient, friendly and eager to help while I was coming up to speed and learning about all the different aspects of our stack, standards and procedures. It has allowed me to grow to a point where I feel I am actively contributing and improving the backend.

Dishant: Every team member is kind and helps you on topics and things you are unaware of and doesn’t let you feel down. Sprint Plannings, Product Backlogs and Daily StandUps is an intuitive way to collaborate with the team and know more on who is doing what. Also, everyone is pretty active on Slack so it just takes a few minutes to get response.

Arya: It’s been a nice experience working with the DevOps team for the past 8 months. The team is really friendly and approachable, so it’s been easy for me to feel a part of the team. Whenever I have questions, it’s nice to be able to chat with the engineers on the team and learn about the different ways to solve a problem. I enjoy contributing to the team and the work they’re doing.

What’s the most difficult problem you’ve worked on?

First off, I love this as an interview question, especially when you have them timebox it to something recent. It’s open ended that allows you to be as specific or general as you want, and can also elicit passion, dedication and perseverance. I didn’t tell them that this is what I ask in my interviews, so I was impressed to see their responses. I’ll do a little analysis on each response.

Arya: The most challenging project was when I successfully designed and implemented a fully automated CI/CD pipeline for ECS Blue Green deployment as a proof of concept during the first month of my work term. It was a challenging, but rewarding journey as I learned how to integrate CircleCI and various AWS components through online resources and working with other team members. Within a month, I was able to connect all the pieces together and showcase my solution to the team. It was really exciting because this proof of concept will help us continuously test and deploy applications to production with near zero downtime. Learning everything from scratch within the first month through this experience was a steep learning curve for me and I had a lot of fun exploring various technologies with this project.

Great answer, it shows she’s a quick learner, not afraid to take on big challenges, and even used the timebox strategy. Also, had a go with public speaking and disseminating knowledge across teams.

Dishant: The most difficult problem that I worked on was my very first endpoint. This endpoint was supposed to return the site details results on the basis of the query params passed. Creating a workflow for this endpoint was not difficult but it included a part of Elastic Search that I have never worked on. I got some help from [my teammate] and he helped me to get the last things needed to be included and finally I deployed that change to production that was also my first deployment.

Not afraid to ask for help to be pointed in the right direction. Also demonstrated a level of trust by deploying to production — that can be daunting, especially for your first deploy.

Thomas: Helping to redesign, refactor and re-implement the services responsible for the system telemetry and billing data. Besides debugging to resolve issues that existed in these services, it has been a great experience rewriting them as part of the architectural changes to our backend required for system control and the PWRview demo account.

Reading someone else’s code is one thing, helping to refactor and rewrite is not trivial. Shows they are not afraid to take on lofty assignments and willing to dig deep to understand the code and work senior engineers that trust him.

Kobe: During device removal v1 we had to use [a proxy service ] but found that when testing the [proxy service] functionality in our endpoint, the changes didn’t appear on PWRtools right away since we didn’t have a test system to actually remove a device from. I had to reach out to my teammate who originally wrote the implementation plan to help me come up with a test plan. We noticed that after calling [my] endpoint, the [proxy] devicemap would be missing the removed device for a few minutes. With this, we now had an updated test plan we could use to QA our work.

Not only does it show the ability to reach out across the boundaries of your immediate team, but it also goes towards making the process better by coming up with a test plan to ensure quality.

Like I said, our 2021 cohort was stellar, and I wish them all the best, wherever they end up.