We recently gave advice to someone working with a co-op student for the first time, and we figured it would be useful to share our suggestions with the wider world. If you have suggestions of your own, please share them in the comments or send us an email for possible inclusion in the article.
Many engineering schools run “cooperative education” programs, where students alternate semesters between school and paid work. These are colloquially referred to as “co-op” programs, and the participating students are often colloquially referred to as “co-ops”.
Mindset
It is helpful to have the appropriate mindset when working with a co-op student or an intern, as the interaction will be different than working with an experienced full-time hire.
Most importantly – have patience and be willing to teach! Co-ops and interns don’t know the things you know, and schooling is pretty famous for not preparing folks for professional work. It is equally important to remember that they may not implement something in the same way you would – in some cases, what they did may need to be redesigned or fixed, but in other cases it may just be best to live with what they did if it’s good-enough-but-not-ideal. Handing over ownership is one of the perennial leadership challenges.
Everyone has different aptitudes and interests – try to select work that aligns well with that individual. Give your co-ops and interns real tasks that move the product forward, not busy work. In the early days, it will be best to select tasks that are not on the critical path
Ideally the work will be a combination of interesting, challenging enough to push them a little, but not so far out of reach that they feel stuck. While we all have to deal with soulless or tedious tasks from time-to-time, they should not make up the majority of the workload.
For an example of what not to do: as a co-op student in his first semester of work, a team I worked for ran out of things for me to do. They asked me to update the copyright dates on thousands of source files, thinking this manual task would keep me busy for multiple weeks. And, surprise, it did not: I wrote a script to do it in an afternoon. After that, I was told I could spend the rest of the semester just surfing the internet. Instead, I moved to a different team – one that would set me on the path to working on embedded software.
While I was eager to help and do whatever was asked of me, I was quite sad to be given busy work instead of being able to help out in a more productive way. People want to be and feel like useful contributors to the group effort. Your objective is to train the intern or co-op to be useful and productive in the future (hopefully, at your company!). Failing to keep someone appropriately challenged and encouraging busy work and time wasting simply results in poor training. Consider whether that is really what your team is looking to accomplish with a co-op or intern program.
Finally, let them try to figure things out for themselves, encouraging them to come to you when they need help but after they’ve done some research on their own. If you think something is taking a long time, you can check in and see how things are going and ask if they’d like any advice on tackling the problem (and honor the answer). It also helps to schedule regular 1:1 meetings with the student to give them a venue to share what they are struggling with.
Ideas for Work Assignments
Perhaps the most challenging aspect of managing a co-op or intern for the first time is figuring out work assignments. We think it is important to have a large bank of work ideas to pull from, because there is nothing more disappointing to a co-op or intern than to be given busy work, “gopher” tasks, or just told to sit and play on a computer because there’s nothing for them to do at the time.
The primary source for work ideas, of course, should be related to the specific role and we cannot necessarily advise you on that. However, we do strongly recommend that your team sits down and comes up with a list of projects that are suitable for them. This should be done before the co-op students or interns come on board! These should be projects that move the company or product forward in some way. Often, suitable projects can be drawn from work that the team has not been able to get to due to higher priorities at work. Research, experiments, and exploratory development efforts are also good sources of work assignments.
Beyond that, here are some non-obvious suggestions that you can draw from:
- Bring them along to various meetings, especially those that involve interacting with other teams. Just being a fly on the wall can be great experience!
- Invite them to design reviews and code reviews for work that you and the greater team have done. These are great venues for sharing knowledge, especially about non-obvious techniques and principles.
- Ideally your team will already be doing this type of activity. But even if you are working alone, you can host such reviews with just you and your intern. The experience for you might be essentially the same as explaining your work to a rubber duck, but even that will help you share knowledge and find ways to improve what you’e worked on.
- If you don’t know what else to do, you can always do some pair programming (or other engineering tasks) – and don’t forget to let them drive from time to time :).
- You can identify tasks that get them interacting with other teams in the company, whether in big or small ways. The specific interactions will vary with the role and skillset, but here are some suggestions:
- Have them participate in schematic reviews with the EE team.
- Have them work with the EE team on bring-up and verification tasks when new boards come in.
- Have them participate in reliability testing. This can involve running the testing, manually evaluating device functionality after testing events, creating an automated test station the team can use to evaluate device functionality, writing custom firmware to support reliability testing, or writing up the results and presenting the findings to the company.
- Have them work with another internal team to learn what software capabilities would make their lives easier (e.g. shell commands that an EE might use for their own validation work), or to collect requirements for an upcoming feature.
- Have them negotiate equipment usage time with another team.
- Have them create a formal plan of some type (e.g., an acceptance test plan), getting input and agreement from all the various stakeholders.
- Involve them in helping reproduce hard-to-pin-down issues or validating fixes for reported issues.
- In addition to development-related tasks, have them help develop/expand supporting development, testing, and automation infrastructure.
- Have them integrate and validate an update to an external dependency used by the system.
- Use them as “documentation guinea pigs”. Have them work through the documentation to get started with the system, encouraging them to make corrections and updates based on their findings.
- This does not mean that you make them write the documentation for the system. They will not have the necessary understanding – that’s stuck in the heads of the designers.