The rotation experience – Antique Geek Notes
The rotation experience

After university I joined a semiconductor design company as a hardware design engineer. The graduate rotation program was optional and only a few of us did it, but I was too much of a hyper-curious person to turn it down. The biggest push-back against rotation was seemingly wasting a year of career learning a bunch of things that might have very little impact on the career trajectory (hint: think about what we've done in university). But I was lucky - all of my rotations were quite well fit and miraculously all of them had strong and lasting effect on my career.

What is graduate rotation program?

Companies often recruit newly graduated candidates into their graduate scheme in which new employees take multiple roles in different parts of the company for one or two years. The exact detail of the program varies wildly from company to company, but the general idea is to create an opportunity to have wider visibility of the company, establish important connections and hyper-boost growth potential. After the rotation period ends, depending on the program, the candidates might return to their home team, or choose to start their career at other team and other role.

It's nice to be part of the team

If the person joining the team is in temporary basis, for example as part of the graduate rotation or secondment program, it's very important to let them integrate to the team a little more.

My first rotation didn't have a general theme or a coherent set of tasks, which was quite unusual given our graduate program was a bit "too" well organized. Instead I was given 3 tasks: one design task, one verification (i.e. test) task and one task writing scripts.

Obviously we needed to design stuff as a hardware design engineer, and occasionally wrote different kinds of scripts to automate our workflow, so having some exposures would help me familiarize myself with the project, the general workflow and what is where. The verification work was quite interesting though, in the sense that design engineer didn't normally do verification work - we had a dedicated team (or teams) for that in most decent-sized projects. The verification team however was the team that we interacted the most in our daily life and it would be good to understand their daily work as well as build rapport with the team. After only 4 months of the first rotation, I had interacted with basically the entire design team, plus part of the verification team, and some people from other teams (e.g. physical implementation, softwares, etc.).

The most satisfied thing was, my work was part of the project and was shipped to customers just like the contribution from any other team members, which was actually not popular. And about 3 years later, some customers still asked us about the functionality that I designed in my very first few weeks.

I've learn a few things from this rotation. Being part of the project and part of the team is vital to the success and the experience of the rotation because the motivation and sense of achievement is higher and the team can offer wider range of support. Furthermore, a rotation doesn't need to have a theme and still be good. Sometimes it's more desirable not to have a concrete scope and let the new joiner do it at their own pace and explore the new interesting territory themselves.

The one with a theme

My second rotation had a proper theme. It was about bringing up a verification methodology that had been proven to be very effective on finding dead-lock - the kind of serious bugs that could lock up the whole system. The work was by no mean innovative, but the prospect of solving the traditionally impossible problem intrigued me immensely.

I was not so integrated in the team during this time as my work was relatively independent and experimental. The project was also extremely complicated (one of the most complicated in the industry), the amount of knowledge required was huge and the team was busy and under great pressure. And if that wasn't bad enough, this verification methodology was notoriously hard to deploy correctly and effectively.

Even though from my perspective my contribution in that project was quite limited, I was still quite happy with the sheer complexity of the task, the excitement when something worked, and the foundation I'd laid for future attempt to tackle this challenging problem. The team lead was always supportive and was very pleased with my work though - I just loved the positive atmosphere and the encouragement he gave me throughout the rotation. Later in my career when I had more experience I realized it was actually really good, so I guess he was right after all.

The most important thing I've learned from this rotation is to be supportive and provide positive atmosphere regardless of the situation. I wasn't a big believer of this concept, but the rotation seemed to give me a very good reason to do so. It doesn't necessarily affect the outcome of the project, but some people might just be too hard on themselves and a gentle reminder of how much they have accomplished sometimes works.

The adventurous one

My third rotation was something completely different: I worked in an independent initiative to improve verification methodology across multiple projects. It might sound awesome but to be honest to this day I still don't know where that project was heading at at that time.

The project was so adventurous and so aimless, I wasn't sure if the rotation lead actually had any idea what we should do. The problem was extremely challenging and novel, there was virtually no help. I threw the best of my abilities to the project and built a data flow analysis system that could process a huge amount of traces, a kind of log that contains all the events happened in the system, detect patterns and spit out a bunch of graphs. Because the amount of data needed to process was too large, the project became quite complex and I needed to add a lot of new techniques in order to process all the data in parallel, across multiple node in our oddly deployed high performance computing infrastructure.

From the project objective point of view, it was a complete failure. The problem was too difficult, til this day after some attempts by other people it's still unsolved. But just like the previous rotation, it pushed me to learn and explore much wider of the company, interact and get help from seemingly random teams, and explore some of the deepest parts of the company that for some reason became very useful later in my career. And even though the project did nothing useful, the data analysis framework I developed was intriguing enough to be picked up by yet another team to further improve to become a tool for wider use in the company.

There are plenty of things to think about after this rotation. It wasn't successful but to be fair I didn't expect it to be successful anyway. It was a nice rare adventure from my point of view and the legacy of that project wasn't too bad. I do admit I sometimes think about finding a grad to work on some of my adventurous ideas, but I normally prepare something a lot more concrete and certain than this project. These kind of rotation project is very difficult to get right unless the idea is clear and innovative and the potential outcome is really satisfying. Also if the innovation is somewhat within the scope of an existing project, it'll feel a lot cozier.

Final thoughts

I had 3 great graduate rotations and all 3 of them gave me lots of skills and experiences and opened many possibilities that I didn't anticipate and that made a huge difference in my grow potential. Writing all of these down not only reminds me of my favorite experience at work, but also helps me find the best approach to design a good graduate rotation in the future.

Be aware this is my experience and the outcome can be very different with different person. That's one of the pitfalls I need to be very careful about to make sure I don't make dangerous assumption and end up proposing a project without enough benefit for personal growth, not giving enough support or making wildly unrealistic expectation.

Copyright © 2023 Antique Geek Notes.