My Computing Science Graduate Co-op Experience: [Part 2] Finding Your Strengths

Sometimes in a co-op position you might not get tasks that you absolutely love.  Make the most of it like Evgeny did, Evgeny went from feeling this way to having his co-workers ask for his advice! 

The first week on the job at Broadcom was fairly easy: I met with my team, greeted my coworkers from other teams (lunchroom is the best place to meet people), learned corporate rules, team project documentation, and set up my working environment.

“Science Projects”:

During the first month of my co-op, I was working on a project that was not related to the main product developed by our team. My manager calls such tasks “science projects”.  This means you should try something without guarantees of success, and results of which might be forgotten in a couple of weeks. I guess working on such projects was my fate since I am a PhD student. And you know what? Such projects are not very rewarding:

1. It is tough to get them going: there is no one to ask advice.

2. It is not guaranteed that you will get at least some results.

3. It is almost certain that this labor would be forgotten very soon, because the main team working on unrelated product.

And by the way, such projects involve reading massive amounts of documentation, which I am not a big fan of.  After my first “science project” was completed (the results were not very encouraging), I was switched to other tasks that had more relevance with the main team project. The experience of my coop suddenly became much more enjoyable. I already knew most of the software development tools my team were using with the exception of the version control system called git (if you a CompSci student reading these lines, my advice – master this tool ASAP, it highly increases your chances to be hired). I had other people I can discuss my implementation with, and what is most important after some time my colleagues started to ask me for advice!

Self Evaluations:

You know, how the coop office always asks you to fill up your self-evaluation for the term and set up learning objectives? Well, mine was to learn project development flow in a big corporation setting.

Here are the results of these goals:

1. We had a team of about 10 people, and we worked on the product day and night; but when you look where it belongs in the end product, you realize that this is just a tiny feature among countless others.

2. Quality is the king when developing software in companies like Broadcom; and you have everything for this: continuous integration and testing, code-reviews by coworkers, version control.

These two conditions are very different from the academia setting! In university setting you aim for speed: the programs should just work, the amount of bugs or the quality of code are secondary. Although I did not start off doing work I was too excited about, I ended up finding my niche.  I was able to accomplish my learning objectives and learn a lot from the experience.

Read Evgeny's next post about his experience at Braodcom about staying motivated.

Beyond the Article:

• Follow Evgeny on Twitter or LinkedIn
• Check out Broadcom’s website for more information about the company
• Learn more about the Graduate Co-op Program.