Following The San Bernardino Gunman's iPhone incident less than a year ago, there is a fierce debate about encryption and goverment backdoors. I do not believe technology companies should be required to purposely weaken encryption or implement backdoors in their products for the benefit of anyone, including the government. One fundamental problem is that if a key or a way in exists, you never know for sure who has it. If there is a backdoor into iPhones that the government can use in extreme circumstances, how can we be sure method of accessing an iPhone will never fall into the wrong hands? If the key to the door is out there, you can never be sure how many copies have been made and who is in possession of them until it is too late. What is the point of developing the encryption technique if you can’t be sure the secret is safe?
Additionally, I disagree with this requirement from a fundamental standpoint. I believe users are entitled to a degree of privacy. If their product offers encryption and privacy, I don’t see the problem with that. If you want to send an encrypted letter message on a postcard to a friend, where is the problem? The government doesn’t need to know what it says and they were never intended to know. Unlike Apple as explained in the New York Times Article “Apple Fights Order to Unlock San Bernardino Gunman’s iPhone,“ if technically feasible, I would unlock the iPhone for the FBI at their request. While I don’t think they should be mandated to give the government a backdoor entrance, I think it is in Apple’s best interest to turn in data that can advance the national security of the United States regarding terrorist attacks if they have the means possible. Since their encryption is so deep and powerful that they are no longer able to decrypt the device themselves, this is no longer an option. As unfortunate as it may sound, I believe that a device with such encryption should be considered equivalent to a physically smashed iPhone. If the user was smart, they would have also used proxies and vpn’s to communicate with others instead of texts and calls so that their communication could not be traced. Gaining access to the device does not guarantee that the device even has the data that is sought after. While on the surface it may seem that backdoors should be implemented and accessible to the government, I don’t know that this will truly solve the problem. If it becomes known that the government has these backdoors available, people can simply try to stay one step ahead and hide their communications behind proxies and vpn’s. When the backdoor is known to exist, people will respond to this and will seek alternative methods of hiding their sensitive data. Thus, I don’t think giving the government a backdoor truly solves the problem in the long term, and it instead compromises the security of everyone. With such a backdoor available, you can never know for sure who has access to your data.
0 Comments
The interview process is difficult for both the interviewer and the interviewee. Trying to assess so much information about a person in such a narrow time frame is very difficult. The interviewee is tasked with making an assessment of your ability and desire to bring success to the company with a very limited understanding of your skills and experiences. With this imperfect perception of who you are, they must make a decision. Throughout the process, the interviewer must also try to determine the real you vs the self you are displaying during the interview.
Interviewing is very difficult for most candidates. Few are able to succeed without deliberate practice in the technical interviews. Interviewees are generally presented with a random technical question that pertains to any number of data structures, algorithms, or other CS fundamentals. While it is a good opportunity for the candidate to display their thought process and analytical ability, these questions can be very hit-or-miss. The candidate may not be able to fully wrap their mind around the question or figure out how to make it efficient enough in the short time span of the interview. It is also excessively difficult to see a problem and to start talking intelligently about it within 10-15 seconds of digesting it. During interviews, there is really no chance to take in the problem and take a step back and think about different solutions and approaches. You are expected to verbalize your thoughts throughout the process, which can even distract yourself while trying to think of solutions. If you know there is some kind of trick to the problem but you cannot think of it within a moment or two, you are forced to move on. Because the problems can be so hit-or-miss, you don’t have the chance to think for yourself for long enough, and the time window is narrow, it makes it very difficult for the candidate to consistently succeed in multiple consecutive interviews. Our proposed interview process, while still testing technical knowledge, focuses much more than the current process on previous work and projects and the weight that they carry. Our process gives candidates a chance to talk through past projects, how they overcame obstacles, how they worked on a team, why they made the technical decisions that they did, and so forth. It also focuses more heavily on the candidate’s initiative and desire to work at the company. Because of the take-home assignment, candidates will not simply apply to a hundred company’s shot-gun style and hope to hear back from a few. Instead, they will be more deliberate about the companies they apply to and are more likely to be sincerely interested. Candidates will not have the time to do the take home problem for every company they apply to, so this helps companies know they are truly interested and provides a concrete demonstration of their skills. I believe that our process is more ethical because it seeks to know the person on more levels than “can you code this in 45 minutes?” Instead, it gives the candidate a chance to discuss past experiences, demonstrate their skills and abilities in a take home project, show their ability to communicate, think analytically, and solve an unseen problem in a technical coding interview, and assess their fit with the company culture and their desire to work at the company. All of these things give a much better picture of the candidate as a whole. Project 2 link: https://nward3.wordpress.com/2016/09/30/project-02-tech-interview-reimagined/ I believe the root causes of the Therac-25 accidents revolve around how the software was developed as well as people’s optimism toward software and their growing complacency concerning software and safety. As explained in “Killed by a Machine: The Therac-25”, the most concrete cause of the Therac-25 accidents was the way the software was developed. It was said to be developed by a single, relatively inexperienced programmer and there was no timing analysis performed. While it is essentially impossible to 100% guarantee that the software will never have a bug in any possible scenario, all effort needs to be put into designing a holistic system that is designed to avoid failures when its use is safety-critical. As the “An Investigation of the Therac-25” article recommended, software should be seen as only one part of the system design. There should be more fault checks – hardware interlocks should not be removed if they can help ensure the design operates safely. Of course, the code should also be unit tested and tested end-to-end with best software development practices. Safety critical software cannot be “hacked together” under any circumstance. For many software engineers, this is a different philosophy. Many companies have a culture of “fail fast, fail often”. If Facebook goes down, no one is going to die (I hope). But if a medical device’s software has a bug, it could potentially end someone’s life. The stakes are infinitely higher. As the “An Investigation of the Therac-25” recommended, this type of software also needs to have excellent audit trails and incident analysis procedures so that the root cause of issues can be pinpointed and eliminated.
With safety-critical systems, extra care and effort needs to be given to brainstorm all possible things that could go wrong, and make sure they design accounts for these things. It should also go through the code, line by line, and figure out what could possibly make each line do something unexpected – all assumptions must be challenged. The entire design philosophy must be adjusted from traditional software companies. Companies developing safety-critical systems have no choice though. I believe they are just as responsible for their product as an auto manufacturer is for their automobile that spontaneously fails and endangers lives as well as the engineers who design a bridge or a building. These systems must be designed to be resilient to failures. A company designing children’s toys cannot say “We didn’t expect the child to put the toy [with lead paint] in their mouth.” The company must foresee this type of error and account for it in their design. The issue is that software has seemingly infinite possible bugs, whereas many physical systems can be tested and proven using physics. This is why I am particularly afraid of self-driving cars. As Adam Fabio of “Killed by a Machine: The Therac-25” wrote, the Therac-25 incidents were “the watershed event[s] that showed how badly things can go wrong when software for life-critical systems is not properly designed and adequately tested.” There are an infinite number of scenarios that could occur with a self-driving car, and with far more of these safety-critical systems on the road than there were operational Therac-25’s, the stakes are that much higher. Users must either trust that the engineers have learned how to better account for unexpected catastrophes and prioritize safety or refuse to use these new systems. Unfortunately for the case of the Therac-25, this system working correctly was critical to the health of the patient and choosing not to use the machine was not a realistic option. Erica Joy talks about trying to fit in and changing herself in “The Other Side of Diversity”. She explains over the length of the article how she never really feels like she fits in until she finds a black community. One thing that stands out to me from her post is that she seeks to be in a community of people with the same gender and race, which is exactly what we are accusing the tech industry of doing. She seems to have been looking for other black employees that she would fit in with all along. If the tables had turned and the industry was predominantly black women instead of white men, would Erica still call for increased diversity?
There is a call for the tech industry to become more diverse. While I think this call is certainly warranted, I’m not sure that it would fix Erica Joy’s issues with the tech industry. The tech industry cannot be simultaneously diverse and fully welcoming to every minority group. Any employee can always find themselves feeling isolated on their team because they don’t fit in with the other members. Increased diversity wouldn’t necessarily change that – it may just make everyone feel that way instead of some people. I like to think that race and gender don’t matter, that I can work with anyone. But Erica’s post is giving me doubts – she seems to have been unhappy over the last 13 years working with coworkers when she was in the minority and not happy until she was working with other black employees, especially women. This doesn’t sound like she is truly interested in a diverse workplace. At the end of the day, maybe people do just want to be surrounded by others who look and act like them. If that’s the case, I don’t see diversity in the tech industry changing anytime soon. While I don’t think that a lack of diversity is a problem in and of itself (I haven’t seen anyone complaining that 67% of NFL football players are black while only 12% of the US population is black, or that the NBA is composed of 75% black players), it is very much a problem if minorities are being discriminated against and held back in the tech industry, whether by conscious or unconscious bias. It is easy to look around and notice that most of the tech industry is white. But then again, so is over 63% of America according to the latest Census. When talking about diversity, I don’t think it is fair to argue that the proportional percentage of a minority must be greater than the minority’s representation in the US population. For example, if blacks are 12% of the population, it is not rational to demand that they represent 50% of the tech industry. I believe we should keep in mind the proportional population when considering diversity in the tech industry. However, I fear that if 12% of the tech industry was represented by black employees, Erica Joy would not be satisfied, because on average, on a team of 8, she would be the only black employee. It is easy to become attached to what we know and are comfortable with. It is far more difficult to be willing to try new things in life and experiment with the unknown. Perhaps even more important than emphasizing the call for increased diversity is to emphasize the need for employees to be more open and considerate of employees with interests different than their own, and instead of ganging up on employees with different interests and ostracizing them, welcome their differences and celebrating their unique offerings. From Erica’s post, I believe this would have been far more beneficial. I don’t think what she was really truly looking for was only other black employees and no one else, but rather for employees who would not judge her for her differences and for being herself. It is very sad that she never really found such a team after 13 years of searching and changing teams. If the tech industry, specifically each individual employee, worked on this, I think the industry would make far greater strides toward diversity, because when minority employees join teams, they wouldn’t feel so isolated. The difficulty in this comes because employees who have found hobbies (such as video games, paintball, etc) that they enjoy may not be willing to give these up so that new employees do not feel left out. Interactions on a micro level are very difficult to control, and I think this is one of the reasons it has been so difficult to increase the diversity in the tech industry. In my senior year, I have begun to think about and fear burnout. The past two years, the thought never even entered my mind. I felt that I was playing a game of catchup, mostly against students at other schools who started their curriculum early in their freshman year. I have tried to push myself to the limits to in order to catch up, and even to try to get ahead, whether through homework, class projects, interview prep, or side projects, I haven’t given it a second thought. Perhaps it is senioritis setting in, but I am beginning to look at the bigger picture, what life outside of college will look like. While I certainly want to continue to grow, to stay on the cutting edge and to avoid falling behind, I also want to make sure I correctly prioritize my life. While improving my coding skills and getting a good job have been my primary focus over the past two years, I have recently realized that I need to take a step back after graduating and reevaluate what is most important in my life. The reason I have worked hard in school is so that I won’t have to worry later on about providing for my family. I haven’t burnt out quite yet, but I need to make sure I don’t after I graduate either. If I continue on at the same pace after graduating, I fear that it won’t be long before I burn out. As Andrew Dumont explained in Avoiding Burnout, I fear that burning out would be disastrous and difficult to recover from.
To help combat burnouts, I plan to have a good work-life balance and to keep work at work. I also want to invest more time and energy into hobbies outside of computer science such as cycling and weight lifting. While in school, I have felt a constant pressure and reminder to do all that I can to best prepare myself to get a good job. I hope to be able to turn this constant reminder off and to enjoy life more. While I certainly don’t want to stop learning or to lose passion for CS, I want to make sure that I dedicate more time to family and friends. From my understanding as well as Andrew Dumont’s experiences, I believe that burnout occurs when you aren’t able to draw a line between work and life outside of work for an extended period of time. In the long term, it is a much better idea to aim for sustainability than for maximum output in the short term. While I believe it has been necessary to be “unsustainable” for most of my time here at ND, it is because I have felt that I have been playing catchup with others that I am interviewing against. I know it will be tempting at times in order to remain competitive, but I hope to avoid burnout and to refocus my efforts on the things that matter more in life beyond my job. The manifesto does reflect my thoughts and feelings. I really do feel that countless people in the Notre Dame CS community have significantly contributed to my success, and I feel passionate about doing the best I can to help the sophomores and juniors. This passion is why I pursued a leadership role in the computer club and have TA’ed the CS Fundamentals courses. I don’t think I would be nearly as well of if I hadn’t been able to get help and advice from TAs, opportunities to talk about job opportunities and experiences with upperclassmen and received countless tips for technical interviews. While the manifesto is not a warcry, it is a profession of thankfulness and gratitude to those who have committed the time and energy to helping us along our career journeys, and a commitment from us to do the same for others.
I do identify with many parts of the Portrait. I am a white male from the Midwest. While not the primary reason, Matlab did play a part in convincing me to major in CS. I had been interested in it since the second half of high school though, albeit uncertain. I think I also dress fairly consistent to the description in the portrait as well. Additionally, I do indeed enjoy coding, attending hackathons, playing video games, and being with friends in my free time. Furthermore, I am religious and do believing in using my talents for the good of society as explained in the Portrait. Although I have not accepted a job offer yet, I do seek to work at a big name tech company. Perhaps where I differ most from the Portrait is in what I study outside of CS. Unlike many of my classmates, I do not have many particular interests outside of CS. I do not have a passion for the liberal arts, or pure math or science. The most I can say is that I am interested in HCI and designing the best user experiences possible in projects as well as having an interest to some degree in learning more about the business and financial side of companies. However, my passion and the vast majority of my time spent learning is dedicated to CS. I think stereotypes are important and relevant because people generally - even if only subconsciously - believe them unless they have a specific reason not to. They can cause people to form opinions about things before they really know for themselves. I think that people tend to rely on stereotypes until they experience things for themselves. But they can be beneficial and harmful. For example, the stereotype that hackers have malicious intent is harmful to the hacker community overall. But the stereotype that Notre Dame students are very intelligent is generally beneficial, particularly when applying for jobs. If a manifesto or portrait can have a consensus approval from those it represents, I think that they can be healthy. However, if the portrait or manifesto is written by a small subset of the community it claims to represent, I don’t think that it is likely to be an accurate representation of the community. If the option is for someone to know nothing about a community or be able to read the community’s manifesto or portrait, I think it would likely be beneficial in this case, although there is a chance that the document is not truly representative. Our Manifesto and Portrait can be found at: www.nward3.wordpress.com/2016/09/08/project-1-manifesto-portrait/ My job interview process has largely consisted of applying to as many interesting companies as I can and waiting to hear back. In a few cases, I was contacted first by a handful of companies before I applied. However, this is certainly not a frequent occurrence. I have been a bit surprised at the lack of “new grad” specific job opportunities by many companies. While I want to apply early, many companies do not yet have “new grad” positions available online, so I have to either check again later or apply for a position that requires 3-5 years of professional experience and hope to simply get into their system and on their radar. This aspect of the job search has been a bit frustrating, adding additional stress to the job search.
An additional aspect of the job interview process I have found frustrating are the phone interviews. In many of the phone interviews, I have had a difficult time hearing the interviewer sometimes due to an accent, sometimes due to a poor connection with static and background noise, and sometimes both. On top of this, I find it difficult, in some ways more-so than onsite interviews, to communicate my thoughts clearly to the interviewer. While there is more stress onsite, you are physically in the same room as the interviewer and draw diagrams and sketch out your initial thoughts. Over the phone, the interviewer can only see what you type on the page. It is very difficult to quickly think on your feet and effectively communicate your initial thoughts to the interviewer without the ability for the interviewer to visualize your example or to sketch out your thoughts on a whiteboard. On the flip side, I have had a few companies send “coding challenges” which require the candidate to complete a 1-2 hour set of problems online on your own. I like these more than phone interviews because I have a chance to think on my own without verbalizing my entire thought process, and it gives me more of a chance to find an efficient solution before I begin. I also find it frustrating when interviewers ask “classic” interview problems that are well known, because if I haven’t seen it or solved it before, I feel like I am at a disadvantage both because I am probably expected to have already solved it or others who are also interviewing have likely already solved it. I think unique problems, while much harder to think of and plan out, are much more effective at testing a candidate because they really have to think through the process of finding a solution. Interviews for software engineering positions are very technical. But the questions have surprisingly little to do with the majority of what I have learned in my courses. They are generally very heavily data structure and algorithm focused, possibly mixing in bits and regular expressions every once in a while. Thus, I have found interviewing to be a skill in and of itself that must be practiced on its own. While it is certainly still possible to excel in interviews without doing so, practicing extra problems, recognizing patterns, and developing strategies for attacking new problems has been very helpful for me. I am very thankful for upperclassmen explaining this to me as a sophomore and junior, but I know many students don’t fully recognize that interviewing is just another skill that needs to be intentionally practiced. Unfortunately, the department has not done much to explain this to students, and we have had to rely instead on upperclassmen who learned this for themselves. I have also found the questions I have been asked a bit hit-or-miss. Sometimes they are quite reasonable and make sense at a high level, and other times I have been confused about what the question is even asking, even after asking multiple clarifying questions or I simply have never come across anything remotely similar. As Sam Phippen argued in “On the unreasonable reality of ‘junior’ developer interviews”, I think that many interviews are taking the wrong approach. While I like that they are looking for your thought process and communication more so than getting the “correct” answer, I think that introducing more deeply technical conversations about past projects or experiences would be highly beneficial. Instead of finding someone familiar with your coding language of choice, the company could find an interviewer who is familiar with the types of technologies you used in your projects. They could then ask technical questions about your projects, giving you a chance to communicate to them why you made specific decisions and the tradeoffs for different options that you weighed. I’m not arguing that this should necessarily be the only type of interview conducted, but I do think that this would be insightful for the company as at least one of the multitude of interviews. In particular, I could see this format being far more effective in a phone interview. The readings portray a hacker as someone whose curiosity and desire to understand is ceaseless. The phrase “the curiosity killed the cat” is a bit too applicable to some hackers who just can’t seem to stop themselves. Some well-intended hackers can cross the line when breaking into others’ systems. However, my definition of a hacker is not so much someone who seeks to break into other people’s systems as the general population believes as it is a person who is constantly learning and constantly trying to push the bounds of their own knowledge as well as the collective community’s knowledge. For example, I would certainly classify this man as a “hacker”: http://www.bloomberg.com/features/2015-george-hotz-self-driving-car/. While we normally associate self-driving cars with extraordinary complexity, and rightly so, this man single-handedly added self-driving functionality to his own vehicle, albeit limited. Pushing your own abilities beyond either your own or the community’s boundaries is what I believe makes you a hacker.
In many ways, being a “hacker” is important and useful. For example, knowing how to hack into servers and websites prepares you and your company to better combat others with such knowledge who could potentially use their abilities to overtake your systems. If you have never experimented with security and only faintly understand the attacks that may come in from the outside, you are very likely to be vulnerable. I am certainly not justifying people who hack companies’ systems, because there are other, moral ways such as creating a testing environment of your own and trying to hack into your own environment with the same methodologies. This way you can still figure things out for yourself first-hand without putting others at risk. Many of the readings make the hacker community sound very concrete, and that all hackers are actively a part of this community. I think that many hackers gravitate toward this community of like-minded individuals, but I don’t necessarily think all hackers are actively engaged in this community and behave in exactly the same ways. I don’t know that I would fully consider myself a hacker, but I also wouldn’t say with certainty that I am not. However, I do know that I am not an active member of the hacker community. Instead, I enjoy trying out new languages and technologies for myself, although I am certainly not approaching the cutting edge or in danger of any true break-throughs. Overall, I do agree with Paul Grahm in “The Word ‘Hacker’” that the hacker culture is important and that it is becoming threatened. For many companies, it is in their best interest to encourage the hacker culture. I believe many innovations do result from people trying to see if they can expand the realm of “possible”. Additionally, people should not be penalized for learning how things work internally, so long as they are not destroying the property of others. I think it is difficult to pin down the archetype of a hacker. In general, they seek to learn new things, work around blockers, have an insatiable curiosity and a desire to build and create new things. To this end, I believe I am a hacker, even though that was never my primary goal but is instead simply a characterization that describes my interactions with programming and new technologies. I do not believe programming is a super-power, but I do believe it is very empowering. There are a few reasons for this belief. Naturally, I believe super-powers are unique and super or extra-ordinary. Similar to the "if everyone is special, no one is" argument, I don't think everyone could have super-powers and still call them super. Another connotation I have with super powers is that they do not come about through training and deliberate actions. Rather, they are generally thought of as being innate or accidental. It is precisely the great accessibility people have to programming that reduces is "super" power. I say this even though the accessibility is one of the best features of programming: the fact that high school dropouts can excel in programming, that those who put their mind to it can learn it, even if they have no prior experience. Furthermore, super powers can generally be used on-demand - they do not take hours, days, or even years to produce a noticeable effect. Even though programming has the ability to bring to life software that has the ability to rapidly bring about changes in society and human behavior, to my knowledge we have never considered other engineering disciplines super powers. Even though mechanical engineers build engines that power cars and planes and civil engineers design bridges and roadways that influence human behavior and entire economies, we do not consider these "super". For consistency due to the similarities, I am unable to classify programming as a super power.
On the other hand, programming does share many characteristics with super powers, which is why I firmly believe that programming has the ability to empower people. For example, programming does have the capacity to impact many people. It can change people's lives, the way they view the world, make them more safe, and can do things that were previously thought to be impossible. It can also be used for either good or evil, as can super-powers. It is very empowering that people have the ability and capacity to learn how to program to bring about change in the world. If programming were a super power, it is implied that only a small portion of the population has the ability to program, and that it it is difficult or impossible for others to gain the ability to program, which I do not believe is true. Programming also brings about change in a different way than traditional super-powers. Where traditional powers enable people to fly, fight with super-human strength, and move with super-human speed, programming does not quite directly affect humans in the same way, but instead can provide unprecedented levels of intelligence and analysis that we can then use and act upon. By claiming that programming is not a super power, I am not at all saying that I don't believe it has the ability to bring about enormous change. Instead, I believe we can all learn to program to help bring about the changes we want to see in the world. My name is Luke Garrison and I am a senior computer science major at Notre Dame. I am from Fort Wayne, IN and and grew up as a huge Notre Dame fan. Enjoying and excelling in math in science from a young age, I gravitated toward engineering, especially mechanical. In high school, I became curious about programming and wrote a few very basic C programs on my own. Although I did not pursue it further, my interest in computer science remained with through intro to engineering. After learning about the vast different specialties and concentrations available within computer science, my major decision became clear.
Ever since, my passion to learn and to share what I have learned with others has only grown. I have been continuously inspired by constant technological breakthroughs and I hope to improve the well-being of others through my software after graduation. Some of my favorite courses so far include databases, data structures, unix, and programming paradigms. I have really enjoyed learning about the API layer of websites and experiencing full stack development in side projects. Although I haven't learned any front-end technologies in my courses, I have really enjoyed working with javascript front-end technologies such as AngularJS and putting thought into architecting the front-end. I have been disappointed that there are not more opportunities to learn about creating scalable servers and RESTful API's through courses at Notre Dame since these are so important to so many companies' products. In this class, I hope to challenge myself and give more thought to the "why" and "should" questions instead of restricting myself to questions of "what" and how". By the end of the course, I hope to have spent time contemplating the ethical issues that surround countless topics in computer science, and I seek to prepare myself to make the right choices out in the real world. I am especially interested in considering topics such as intellectual property, digital life, security, privacy, connectivity and freedom of speech. I hope that in addition to contemplating the aforementioned topics on my own, we will also have ample opportunities to share our thoughts on topics in class in a healthy manner. Even though I enjoy software engineering, it's applications still make me nervous at times. For example, the sheer amount of data companies such as Google and Facebook have about me and others is astonishing. While I like the features and functionality they offer, something still feels wrong about how much data they collect. Specifically, I switched to Google Photos a few months ago because it offers unlimited storage of photos and has fancy features such as searching for photos by location, contents, or people. However, such advanced features and convenience come at a price - the app now has hundreds and thousands of pictures of me and the locations of where the pictures were taken. Data security is also an important issue. Giving companies sensitive information requires me to trust them. My health insurance provider was hacked last year, which means now my personal information including address information and social security number are no longer safe and are likely in the wrong hands. When things work all seems great, but it is amazing how quickly things can go wrong when systems fail. And most importantly, just because you can do something doesn't mean you should. |
AuthorSenior computer science major at the University of Notre Dame ArchivesCategories |