Cambridge Silicon Radio was a big step up for. It was one of those big company type interviews that I had become accustomed to while being a student; the kind I thought would be a good personal experience but basically a waste of time. Although it had only been 1 year since graduation, a lot of things had changed.
For one thing, big companies hiring fresh graduates typically expect zero technical knowledge. In other words they don’t care how good you are at programming, they only care about soft skills and what kind of suit you wear; hence waste of time. (Or maybe I was just applying to the wrong kinds of big companies as a student).
But I wasn’t a fresh graduate any more. They stood me infront of a whiteboard and gave me a marker. They didn’t care that I forgot my belt and tie 100 miles away at home. They actually expected me to know something.
The other thing that was different was that within the first year of graduating I started to take my studying seriously. At University I had different priorities. Now that I am in the throes of the real world I do not really regret my very unscholarly attitude at University, if anything I wish I had done more extracurricular activities.
In any case, leaving University I started to read books. Serious books like The C++ Programming Language, Expert C Programming and the Effective C++ series. I even read those silly online Wikibooks on things such as Embedded Systems. And I didn’t just read. I did the book exercises and I worked on side projects. Ultimately it was all this effort that paid off during my interview.
Even 6 months prior to the interview I had no idea what a watchdog or a memory pool was and even though I had no direct experience with many of the things that came up, having read about them enabled me to demonstrate a sufficient enough understanding. And even though they could not care less about my C++ experience it was still immensely helpful to be able to explain how and why C++ evolved a certain way when discussing some of the specifics of C (comparing C++ exceptions to C return codes and long jumps for example).
At the time I didn’t really overanalyze my experience. I was feeling fairly worthless and didn’t think I had a chance with any of these big Cambridge companies. One thing I take away from my interview at CSR was the feeling that I had fun. Both the interviewers were very knowledgeable and skilled. Performing an exercise I had never done before on the whiteboard with them felt much more like a technical discussion than a pass/fail exam. I don’t remember if I really learned anything but I remember walking away feeling like I had enjoyed the mental workout.
One and a half years later and I still don’t really understand how CSR was structured as a whole. There were several desperate groups all with wildly varying levels of expertise and dedication. Fortunately my team were on the very high end of both these spectrums. Perhaps too high.
As an engineer I was part of a scrum team. Not everyone in the company did scrum, but our highly skilled, highly motivated team did. I think the fact that I was by far the youngest and least experienced in the code base was a major problem. It was a constant challenge to find work I was capable of doing and getting it done in time. There were several instances where my teammates grew impatient, especially when staring down the final few days of a sprint and work would be snatched away from me. I would turn up to the morning standup to find out that someone else had already finished off my bug the previous afternoon without telling me. It wasn’t very good at times.
My experience suggests to me that Scrum only really works if all the developers are either very closely aligned in skill and experience or are genuinely “cross-functional” and have sufficiently separate areas of expertise. The way our CSR Scrum team was organised meant that taking someone like me out of the team wouldn’t make a difference but taking a certain other person out of the team meant that the team literally got no work done. Both of course happened due to holidays etc.
As a result I am very skeptical of Scrum. There were times at CSR when it worked very well but unfortunately most of the time it didn’t. Like I said, everyone involved including the product owner were very intelligent and knowledgeable; it was not at all a problem of ignorance.
In theory Scrum means it all team members are equal because knowledge and experience is shared. There are no experts or territories marked out in the code base. Management can swap Scrum team members around and it doesn’t matter. If someone on the team is hit by a bus it doesn’t matter. Unfortunately that doesn’t really hold water when I’m on a team full of people twice my age. I had a good time poking through bug tracking systems and version control histories and learning lots of things but getting hands on experience was difficult and made me feel like I was getting in the way more than anything else.
Another peculiarity of CSR’s structure was the way they followed the benevolent dictator model. That is a single oracle who knew everything and watched over everything and wouldn’t hesitate to tell you that this bug you are working on, or this experimental thing you’re playing with, it’s all crap and you’ve done it all wrong and needs to be changed. The worst part was that this inspired mini dictators emulating the same behaviour closer to the teams which was not very fun.
For all my whining CSR was a great place to work. I learned lots of things and during the times I was able to make meaningful contributions they were … meaningful. The thing I liked most was the dedication to quality and doing things right first time. In actuality I don’t think there were any other Software Engineering jobs I would have preferred and I didn’t think I would be leaving CSR for quite a while (assuming they didn’t find someone else twice my age to fit in better with the team and then fire me).
I was quite shocked by how horrifically bad Qualcomm handled the acquisition and left me, and several others, with no other choice but to leave. But that’s a story for another day.