Working at WatchGuard really showcased my flexibility. I started by setting up competitor firewalls alongside our own. This was research and hands on. Next step was writing a script that used pattern matching and interacted with a database to store statistics on the mail passed through the firewalls. Then I took those statistics and wrote a script to automatically generate graphs. This was all a solo project.On completion I joined the team writing our mail server code. As needed I was also given projects to work on our firewall code, a different programming language. I then transitioned to writing our firewall manager code. A different programming structure.Finally, until I finished working with WatchGuard, I worked on a drastically new generation of our firewall manager code. We transitioned to the cloud and had to re-write everything, once again under a new programming language and structure, to do so. This involved a lot of research, partial starts, and unique problem solving as it was a drastically new endeavor for the company. I worked where I was needed and was happy to do so. In the time I worked at WatchGuard I used Python, regex, PostgreSQL, FreeBSD, C, Javascript, HTML, CSS, Angular 2, and AWS.

From BlackBerry I’d like to highlight how I was a hard worker. The primary day to day work for myself was running tests on camera modules. We received camera modules from different manufactures, from different batches, for different phones, or with different hardware. One of the important things that needed to be done was test their performance. Day to day, I had trays of modules I would run through various tests to create performance reports for the rest of the team. It took a lot time, was always needed as soon as possible, and I worked hard and as long as was needed in a day to make sure they got done. I also created the starting point of a new set of tests. We had no set performance metrics for blooming in a camera module (which, as a side note, please feel free to ask me about what that involves), so I took our camera modules and purposely created blooming. I tested how the modules reacted under certain conditions, what could measure the blooming performance, what gave useful quantitative measurements. It was a lot of research and gathering a lot more data than normal, and it set up the basis for the next co-op student to continue.

At AIG I was part of a unique, small team. Day to day I interacted with my manager, who had experience with SQL, and another co-op student in a math program. Our team was primarily focused on programming a specific internal tool. This position required self-reliance as I was not surrounded by people working on the same thing as myself, or people with the same experience. Everyone had their own focus. My manager handled a lot of the SQL, but did not touch the C# programming I was hired for. My fellow co-op student was also working on a completely different area than myself, and as programming was not her primary field of study, I was left to find my own solutions to any issues I encountered. I was hired at AIG for my ability to program and problem solve, as I needed to be able to do that on my own, and my work over the term showed I was quite capable to do so.

At AMD I was third level customer support. We received the more unique issues that required development and new drivers. I would always reproduce the issue, but then, depending on the issue, I might modify the registry keys, disassemble the computer and swap parts, or run test programs. Of course each of those paths would then have its own set of paths depending on what I saw. Eventually I’d figure out the issue, if there were driver changes required I’d let development know, and then the customer would be contacted back.