Michael McRoskey

To listen to Maggie’s and my podcast on the interview process, click here.

1. From your experience, what are the most important parts of the guide your group constructed? What do you know now that you wished you knew earlier? What is the best advice or guidance you’ve received?

I think the most important piece of advice Maggie and I discussed in our podcast was to engage in outside projects. I cannot stress enough how vital this is for your own enjoyment, learning, and making connections. Maggie and I tend to involve ourselves in lots of outside projects–building websites for ourselves or friends, participating in hackathons, and working for OIT–to name a few. These experiences help enrich our CS experience so that we are actively learning new scripting languages, ones that might not be part of the typical NDCSE curriculum. Projects often occur in group settings, so this is also a great way to meet people, especially people interested in similar things as you! Of course, this all contributes to a hidden side effect–having plenty of technical experience with people that you can put on your resume and talk about in an interview. I have not had a single interview where I haven’t brought up one of the many projects I did outside of the classroom.

I wish I had applied to more hackathons across the country! I think travelling for conferences has been one of my favorite experiences at ND. There are lots of opportunities for undergraduates to just attend conferences–but this wasn’t something I was aware of until late into the game.

The best advice I’ve received is to invest in Cracking the Coding Interview early. It’s an incredible resource for simply re-learning the basics on data structures and certain coding questions. It serves as a fantastic guide to the entire interview process, outlining a timeline for how to properly prepare for a technical interview, starting months in advance. If you know even half of this book cover to cover, you’ve ensured yourself a solid chance in an interview.

 

2. College traditionally has been viewed as a place of learning, not necessarily job training and yet students are spending more and more time preparing for the job interview process. Should colleges adjust their curriculum to face this reality? If so, how would you change the ND CSE program to better prepare students for the workforce? If not, discuss why you don’t think changes are needed and how the ND CSE program already supports students.

The ND CSE does an excellent job supporting students, but can always make improvements to better prepare students for the workforce. I think the recent course scheduling changes will have a significant positive impact on younger classes when applying for full-time roles (specifically, taking Data Structures as sophomores). However, the College of Engineering and First Year of Studies programs need to be more flexible in allowing more CS classes to be taught earlier. This summer, I was shocked to learn that one of my colleagues who was from Berkeley was one of 300 in her class who were also working at Google. When I asked about her course schedule, I was shocked to hear that she and her peers began taking 4-5 CS classes the fall of their first year. Understandably, Notre Dame just doesn’t have this flexibility, but I could certainly see the case for one or two required CS classes offered during freshman year.

 

The root causes of the Therac-25 accidents were an overemphasis on software-defined physical functions and buggy, untested software that responded poorly to real-time situations. I think these issues could have been largely averted by slowing down and clarifying the procedure to be performed before it began, requiring plenty of confirmation by the operator. Such inconvenience is a little price to pay for the lives of patients.

One of the most fascinating parts about working for Google this summer was learning about how they test their products. Specifically, there are often way more lines of code defining test cases for a feature than lines of code defining the feature itself, particularly for features with a direct revenue stream. One of my friends worked in Google Ads, which accounts for a significant portion of Google’s revenue. At one meal, he explained to me the many safeguards it took to make sure Ads never went down. If even a portion of the service was down for 10 minutes, it might cost millions in revenue for Google! Pushing a commit of production code requires several layers of approval and can take weeks (as it did for my team) to get fully approved. Google had such a strong testing culture that it posted “Testing on the Toilet” memos each week with tips on how to make test cases specific, inclusive, and encompassing. Though it was frustrating to write comprehensive test cases, it was worth doing so for the integrity of the product and future versions.

Such safety measures to ensure steady revenue should also be made to ensure the safety of consumers or their data. The recent Equifax breach highlights gross irresponsibility in protecting sensitive consumer data. Last month it was announced that 146 million Americans’ personal information was compromised when Equifax failed to update their Apache servers with a security patch within a 2-month window. Subsequent investigations found that typing “admin” as the username and password for a specific Equifax login credential granted access to hundreds of thousands of records. These incidents could have been prevented with simple security procedures in place like frequent vulnerability patch updating and guidelines on account management.

Even more important that consumer data is human safety, which intersects often with technology in transportation and medicine, as we saw with the Therac-25 incident. One of the most fascinating parts about attending talks at Google was learning about the various ways they employ redundancy to safeguard against malfunctions. A relevant safety-critical system in production there is Waymo’s autonomous vehicles. These self-driving cars can be seen zipping about Mountain View day and night. One of the most important features of these cars is having two computers–one as a fallback in case the first malfunctions. Further, the cars are designed such that control “waterfalls”: if power is cut, each component down to the sensor has redundancy to safely stop the vehicle.

Software engineers must take these systems seriously and be held responsible for inadequate testing. While it may be impossible to drum up every edge case in code, developers can certainly follow best practices and consult with others to ensure their code covers a wide range of scenarios.

Codes of Conduct are largely ineffective because they don’t require much buy-in. A few years ago, I read an interesting book which highlighted this point effectively. In ReWork, a team of consultants discuss positive and negative tactics for successful businesses to both emulate and reject. One of the chapters that sticks out to me to this day was on mission statements, which are a close cousin to codes of conduct in my book. Both are pieces of language handed down from superiors that represent the company.

It’s like when you’re on hold and a recorded voice comes on telling you how much the company values you as a customer. Really? Then maybe you should hire some more support people so I don’t have to wait thirty minutes to get help.
Or just say nothing. But don’t give me an automated voice that’s telling me how much you care about me. It’s a robot. I know the difference between genuine affection and a robot that’s programmed to say nice things.
Standing for something isn’t just about writing it down. It’s about believing it and living it.

This point can stand alone but I’d like to elaborate more on it in the context of our ethics discussion. It’s clear that people can take the same language and misinterpret it after an incident. The fallout surrounding James Damore’s internal Google memo is an illustration that codes of conduct might actually be misunderstood. From his perspective, his writing fell within the bounds of the community rules at Google and he felt entitled to share his opinion. From the perspective of many company leaders, such writing was invective and against Google’s code of conduct.

I’m wary of decomposing the issue to pure relativism, however. That might state that no one is truly correct. For instance, “James was correct in writing this memo because he actually believed it was factual and the right thing to say.” That stands in contrast to, “Google was right in firing James because they believed it was the right thing to do.” There has to be a line somewhere–somewhere between free speech and censorship. James addresses this in his op-ed to the Wall Street Journal after his firing, where he quotes the famous American linguist, Noam Chomsky:

“The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum.”

This full linguistic spectrum truly ranges from end to end, with obvious undesirable consequences at the extremities. One end devolves into unfettered hate speech–Nazi propaganda, terrorist threats, and comments that cause severe emotional pain. On the other end is censorship: political correctness and limits to free speech. There has to be a way to reconcile this division.

The US Supreme Court has many times addressed such extremities and revised protocol over time, in an effort to protect perhaps the greatest freedom afforded Americans: free speech. Today, the doctrine of clear and present danger is the current test for protected speech–if someone threatens imminent danger, such speech is illegal. However, this very legal definition may not suffice for safety in the workplace. People can feel emotionally threatened without an imminent physical threat. I think our companies now need to define where they stand in this free speech spectrum–clarity will help everyone communicate better.

We love to segment our lives in every way possible. I, for one, have 10+ calendars on Google Calendar. One is for fitness and shows only active activities in green. Another is for schoolwork which is yellow probably because school buses are yellow. I even have a purple calendar marked “religious” that shows mass and confession times. These parts of my life are distinct, segregated, and separate.

I can’t help but wonder what balance means, looking at my Google Calendar. Is balance the moment the screen displays all 10 calendars in their spectral vibrance? Or might it mean something the website can’t quite depict—unscheduled, quality time to myself, with others, or with God? Balance is this elusive subject that seems to be the obsession of “thought leaders,” self-help authors, and the motivational parts of YouTube, yet one that some of the most successful people don’t seem to have. In other words, the 0.01% of doers seem absolutely obsessed with their end goal—and likely achieve it—at the expense of their closest relationships.

Steve Jobs and Elon Musk come to mind when talking about this elite group—both people I tend to admire. I love their drive, their commitment, even their brutality at times. “That’s what’s required to be successful,” I might think. But then I look at their personal lives: the divorces, the paternity denial, the burned bridges of former employees. This summer, I watched a documentary on famous Hollywood directors that asked the question, “Do you have to be an asshole to be successful?” No, I don’t want to believe that. So there’s this other part of me that rejects that familial and relational imbalance. I want a family, and a strong family at that. But I also want that astounding success. It doesn’t seem you can have it all—but that’s not what we’re told.

A major factor in our generation, of course, is FOMO—fear of missing out. I don’t mean this in the sense of “going out or staying in on a Friday night” but a much deeper, sobering, nagging question: “was my potential misused?” There’s an incredible fear of what might have become of us, what could’ve been. Maybe if I had focused all my energy into piano when I began lessons at age 5, maybe if I had chosen that Ivy League, maybe if I had worked out every day, maybe if I had paid attention in class—I might be…something.

This is such a harmful mantra, but it only gets reinforced by our infinitely scrollable feeds. Everyone on Instagram has ridiculous vacations, is incredibly fit, and has happy friends. They cook Food-network-like meals and can scrapbook like Martha Stewart. They’re also artists, but nail the candid didn’t-know-the-camera-was-catching-me-laugh pose. It’s the new social currency, and it makes us feel like we’re deficient in most parts of our lives. But we’re not, we’re all human. Being a rockstar in one area likely means deficiency in another.  If you’ve ever read about the training regimen it takes to be a Marvel character, you’d likely realize that’s not the life you want to live.

So can you be a Steve Jobs while maintaining a healthy family life? How much of the screen should the “family” Google calendar take up? I don’t have an answer here yet, but I can tell you most of the people we strive to be like have incredible imbalance in their lives. Life has tradeoffs after all.

So in picking a company to work for, a part of my life that will take up 40 or more hours a week, I’d like to think that I take balance into consideration. I’m looking for a place that prioritizes family, flexibility, and health. I want to feel energized going into work and want success at the company to be measured not by rank but well-being. Of course, maybe that’s not possible—for me at least, that’s asking to have it all.

This summer, I read two books with conflicting messages. The first was Grit by Angela Duckworth. In it, she makes the case for hard-working, passionate people who follow through on a narrow set of interests and prioritize one or two life goals. She points to accomplished musicians, athletes, researchers, and military leaders as having the grit to stick to their objectives even when they lose interest. The second book I read this summer was by Tim Ferriss, an eclectic thought leader in Silicon Valley who offers chapters of productivity advice, life hacks, and promises of fulfillment in The Four Hour Work Week. Tim advocates no 10-year or 5-year plans but 2-week plans and suggests experimenting with life to always try new things.

These pieces of advice seem to have incompatible messages, particularly in regards to career advice for a senior college student. What kind of role should I pursue post-graduation? An international job that could generate amazing, memorable experiences or a desk job that keeps it 9 to 5. I’m even conflicted on industry: ought I devote myself to Computer Science (get the Masters, work for a major company 10+ years, etc.) or consider jobs in other areas I like such as media, politics, or something else? I’m also entrepreneurial—should I just take a risk and start my own thing?

Tim Ferriss seems to answer these questions best, in my opinion. His response accounts for the reality of life—it moves quickly and people change. I’m not the same guy I was four years ago and certainly don’t expect to be the same in four more. Life also shouldn’t be defined by career but by experiences and relationships. That means I’ll make real career sacrifices to surround myself with the people I love and do the things I want to do. We’ve each just got one shot at this life, why limit it? At the same time, I see the power of focusing energy in one specific area—achieve incredible (yet narrow) results.

The caveat I propose is thus a merger of Tim and Angela’s advice—continue to experiment until you can continually pursue your most fulfilling work. At this point in my life, I can’t imagine staying at the same company for 3+ years let alone on the same project. I have too many interests and too much of the world to learn about. So learn about it! Find new interests and experience different roles and opportunities. At some point, I may find an area to focus my energy, but that’s not my objective yet.

Some of my favorite people experiment often. Elon Musk spends his weeks handling three separate companies and Casey Niestat is always trying out new gear. Steve Jobs once said, “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. As with all matters of the heart, you’ll know when you find it. If you haven’t found it yet, keep looking. Don’t settle.“

What does that mean for me practically? It means I might return to Google, maybe go to Facebook. I might take a year off to shoot another documentary; or pursue graduate school; or service abroad; or start my own graphic design firm. A couple months from now, all my plans might change again—they may need to. I think keeping options open is the #1 way to leading a rich life. Don’t box yourself in to one discipline, one career, one trajectory. Don’t settle.

A lot of people act surprised when I tell them I’ve never seen Star Trek or Star Wars. They say things like, “I feel like you would get that reference.” The same is true for some comics, massive online video games, or the standard comp-sci TV shows (think Silicon Valley, Big Bang Theory, Rick and Morty). The thought is, if you study Computer Science, you probably fit the archetype: pasty kid wearing a hoodie, socially inept, staying up late into the night glaring at a terminal window, junk food wrappers surrounding. That’s never been an image I’ve wanted to emulate, despite enjoying coding. In fact, I almost always actively reject “nerd culture” whenever it pops up—a visceral reaction.

Much of this comes from a profound desire to be seen as more than a single label—more than just a photographer, more than just a Computer Science major, more than just “the Red Bag guy.” These are parts of me, but not all of me.

There’s a delicate balance here, however, and I’m aware that I cannot have it all. On my first day at Google, I found myself vastly overmatched. My peers were discussing machine learning projects they had developed to improve compression algorithms, comparing their contributions to NPM or IEEE, and voicing their annoyances with near-native apps built in JavaScript. I felt like I had little to contribute on these fronts. Even my excitement and conversational contribution in self-driving cars was quickly shot down as “not the area where computationally-heavy computer science was making gains.”

Suddenly, a concept I had mocked so much before (having heard it mentioned dozens of times) became much more real: imposter syndrome. I didn’t feel like I fit in. All these people had clearly subscribed to Computer Science and the entire culture surrounding it. They were hosting “Rick and Morty” watches and competing on HackerRank. Was I not fit for this industry?

A lot can change in three weeks, and it was after that time I met and began to hang out with new, interesting, and fun people. I found a group of interns who played sand volleyball each week and went indoor skydiving with others. I saw there were people at work who didn’t spend all day in front of the screen and enjoyed going to the beach on weekends. I realized many of the intimidating topics of conversation on the first day of work were purposefully ostentatious and actually rather shallow. Like me, people had a desire to just fit in.

I think the term “hacker culture” needs a new name and a better definition. It should emphasize individuality more and do away with the negative connotation of “hacking.” I want people to see computer scientists in every field, with lots of interests, unified by one desire to be a little crazy. Don’t box people in to nerdy cultural norms. The only way we can draw more world-changing people to our field is by creating a vision of an inclusive culture.

Programming is certainly a super-power, but it doesn’t require a superhero to do it. There’s an important distinction between the power code has to change the world and the power a coder has to write code. Let me explain.

Two years ago, I ordered a water with ice on a cross-country flight. When I had finished the water, I began to do the unthinkable: chew the ice cubes. Two days later, the resulting heat sensitivity in one of my teeth was so intense I had to get it checked out. Given that I was out of town and away from home, I wasn’t sure what dentist to use but trusted Google reviews enough to get myself in the door at one. As the x-rays emerged, I stared in confusion at these grayscale photos of my teeth–what could it possibly mean? There were dark spots and light spots, thin lines and thick lines. As hard as I tried, I couldn’t see which tooth was the problem one or why that might be, but the dentist didn’t bat an eye. He identified the deep roots which were touching the nerve and pointed out subtleties on the display I submitted myself to nodding to, despite not actually seeing what he saw. That identification was necessary to fixing the problem. Three days later I could eat anything I wanted, but of course I stayed away from chewing ice cubes.

Was that dentist a superhero, a magician? The results certainly were fantastic and I couldn’t quite explain to people what had been wrong and what had been done to fix it. However, from his perspective, it was simply another standard operation. He had spent time learning the necessary skills to understand the intricacies of the mouth and how to operate tools to repair it. This is not to say “anyone can be a dentist,” but that anyone can understand that dentistry is a skill that is acquired, not innate. Similarly, programming is just that: a learned skill. Even the greatest coders once wrote “Hello world” or equivalent programs.

Of course, code does have this super-power-like potential. A couple lines of code can affect millions, even billions of users. However, I’m weary of referring to programming as a super-power since it’s the scale of the infrastructure that gives it potential, not necessarily the person writing the scripts.

In his Wall Street Journal opinion, Why Software Is Eating the World, Marc Andreessen details many of the industries that have been transformed by software–perhaps even “eaten up” by it. It’s a little bit harrowing to see software portrayed in this perspective. The things we do with code today are so much more expansive and life-altering than those we did with it 10 years ago. It is the infrastructure and the application that gives code its potential, not the coders themselves. In a sense, I’m arguing that coders are expendable–at a certain level, anyone who can code can accomplish the same task. It’s then about the context of the code–what information the code has access to, the computer power it has access to, and the goal of the code–that actually represents the super-power.

Hello world! My name is Michael McRoskey and I’m a senior Computer Science student at the University of Notre Dame. Originally from San Diego, I have six older siblings–5 of which went to ND before me. I enjoy doing creative things like taking photos and making videos. You can check out my personal website and portfolio here. This past summer, I interned at Google as a Technical Program Manager in the Google Cloud Platform team, working on Cloud Router and Cloud Load Balancing features.

As a freshman, I started out as a Mechanical Engineer, but by the end of the year, I had found my major: Computer Science. I chose to study Computer Science for a couple of reasons. First, I enjoy solving problems and coding has a particular ability to do that in today’s world. Second, I had always been interested in technology, computers, and coding–Computer Science seemed like the perfect fit. Finally, I was attracted to the laid-back lifestyle in the industry, having seen my brother work in it for a couple years.

I hope to form some solid opinions on some of the difficult topics we will discuss in class. I have a strong ability to see both sides of an argument but often that can be paralyzing when actually making decisions. I think the most pressing ethical issue facing Computer Scientists today–and the topic I’m interested in discussing–is how to be stewards of information. What does this mean? Most of the world’s information is produced, stored, and consumed on devices. Code can thus grant and prevent access to it, and fail in doing so. Code can also alter that information, or cherrypick what gets shown. As writers of code, we need to be aware of this possible distortion and work to correct it.