Interviewing a Software Engineering Manager

This week I interviewed Kristopher Berge, a software engineering manager at my place of employment, Teradyne. I reached out to him because once I get my degree, I would like to work for him–I already work with him on a regular basis as a technical writer, and find that we get along great, he is very helpful, and we both think alike and approach problems in a similar fashion.

Given that we already work together, I tailored some of the questions more to the software groups at Teradyne so I could try to get a sense of what I might want to work on when the time comes. But in general, his advice for how to succeed in the industry was that it always pays to be curious, because you never stop learning. The technology and the demands of the industry are always evolving. He said that looking back at his own education and career early on, school taught him how to solve problems. Once you’re out, you're now put in charge of solving the problems yourself, and there isn’t a textbook that already has the answers to these problems.

I asked him what he saw as the next big trend in technology, and he of course answered AI, since that is on everybody’s mind, and it’s new and exciting. He thankfully had an optimistic view on it though, and foresees it enhancing the tools we use, or streamlining the more mundane parts of our work, rather than outright replacing a substantial part of the industry workforce.
Something I already knew I would have to consider at some point, but was clarified a bit better by Kris was what type of software engineering I’d want to get into. There are different software engineering groups at Teradyne that work on different types of projects (GUIs, tools, lower-level hardware programming, etc). It’s my hope that after I’m able to complete a few projects throughout the CSUMB program, I’ll gain some insight into what type of projects I like to work on. But I also know from working with different engineers at Teradyne that they tend to jump around a bit, and have some freedom to try out different teams and projects, so that leaves me a bit reassured that I won’t be stuck doing something that I don’t enjoy.

I think my take away from this conversation is that I need to focus more on the journey than the end result. I kept feeling like by the time I leave the CSUMB program, I need to know X, Y, and Z, but as Kris described, the important thing is being curious and wanting to figure things out. Gaining the skills to solve a puzzle is more important than already knowing what that puzzle is, because it shows you can learn. I feel like I’ve done very little experimenting, but I keep finding small projects that I want to pursue as a means of figuring out how to code something else. I wish I had more free time to pursue things like that, but I’m forcing myself to get some extra coding practice in.

As I continue with the degree program, I know I’m going to constantly compare it to what I know about Teradyne, and how the projects I support alongside software engineering evolve, and what their challenges seem to be as the projects progress. I’m mostly trying to stay optimistic, since I usually feel unprepared or inadequate whenever I have to investigate things that seem too technical. But I remind myself that I have already gained way more confidence in my technical understanding of the programming environment just since I’ve taken my couple lower-division computer science courses.

Comments

Popular Posts