DAVID MALAN: This is CS50.
Hello, world.
This is the CS50 podcast, episode 5, 0 indexed.
My name is David Malan, and I'm here with CS50's own Colton Ogden.
COLTON OGDEN: Glad to be here--
interesting thing to start us off-- so, we've talked about robocalls a lot
in the recent past, multiple episodes.
And I think we touched briefly upon the prospect
of finding a solution to this problem.
You know, people are getting robocalls all the time,
even though, in the last couple of weeks,
I have noticed the numbers sort of dropping, at least for me, personally.
I still get the occasional call from a presumed spoofed caller.
DAVID MALAN: Yeah, sorry about that.
COLTON OGDEN: But, apparently, the FCC--
Ajit Pai has proposed a ruling that would actually
allow phone companies to block these unwanted calls, these spoofed calls,
before they even get to potential customers.
DAVID MALAN: Yeah, no, this is a nice initiative.
It's perhaps a little belated at this point, certainly.
Because, as we've discussed, these robocalls, these automated calls,
have really been proliferating, in large part
because of the software via what you can do this,
and the API access which you can do this.
But I think the fundamental problem, frankly,
is that the phone system that we have today
really is not all that fundamentally different from what we've
had for decades now, which is to say that there's
no authentication of these calls in the first place.
The systems generally just trust that the number being presented in caller ID
is, in fact, the number from which a call came.
And that's, of course, not always the case.
COLTON OGDEN: Right, and the--
I guess the proposed sort of authentication system that they're
going to roll out is called Shaken Stir, which is very akin to what James Bond's
says when he orders a martini.
But the acronym is a--
basically, the shaken part of it is signature
based handling of asserted information using tokens.
And then the stir part would be secure telephone identity revisited.
DAVID MALAN: Indeed, it's a wonderful acronym
if you allow yourself to use arbitrary letters from some of the words.
COLTON OGDEN: Yeah, and it's a bit of a mouthful.
But this is cool, because this suggests that we'll actually
get what you just alluded to, a way of actually signing calls and making sure
that people who present themselves as xyz are in fact xyz and not,
you know, sort of proxying themselves or presenting themselves
as some other entity.
DAVID MALAN: Yeah, I mean, much like the web-- thankfully
we got that right, presumably because of lessons learned from things
like telephony over the years.
Of course, the phone system has been around for so long now
that it's certainly hard, I imagine, to shoehorn
in some of these more technological features
without breaking some of the intermediate points
or some of the last miles, some of the folks
who are on the other end of the line that might not necessarily have access,
in their municipality, to the latest hardware.
So, I'll be curious to see how this evolves.
I mean, to be honest, this might all become moot over time
if phones themselves, or phone numbers, are perhaps
replaced by more data based services.
I mean, right now, we're very much in the phase
of commercial services like WhatsApp, and iMessage, and so forth.
I mean, but those have started to supplant already things like SMS,
so, frankly, maybe the solution is ultimately
just going to be too late in coming if the world moves to something else,
anyway.
COLTON OGDEN: Yeah, I imagine, when folks were developing the phone system
we have in place, they weren't expecting the ability for somebody
to arbitrarily code and script, en masse, the sort of behavior
that we're experiencing now.
DAVID MALAN: Yeah-- hey, back in the day, it used to be based--
at least pay phones-- on actual sounds, right?
There are so many documented cases, and I
think Steve Jobs and Steve Wozniak were among the folks involved
in this back in the day, where you could have a little box that would generate
the appropriate sounds that mimicked what the sound was if you
put a quarter or a dime into a phone.
So, you could effectively make free long distance phone calls
by spoofing those sounds.
So there, too-- there was a sort of an assumption of trust
that was quickly broken.
COLTON OGDEN: I think the theme is always that, if there is a system,
humans will find a way to abuse and break it.
DAVID MALAN: Indeed, but there are some really real world implications of this.
In fact, just the other day did I see an article
online about what have been called virtual kidnappings which, frankly,
is literally ripped out of a "Law and Order" episode
that I'm pretty sure I've seen, which is ironic,
because usually it's "Law and Order" ripping
things out of the actual headlines.
But this, I think, predates this, whereby
folks have started to get, terrifyingly, what
appear to be actual phone calls from their child's phone
number, or relative's phone number, or a co-worker's phone number,
and on the other end of the line is some adversary, some human who
is pretending to have actually kidnapped the person whose phone they're
purporting to be calling from when, in reality, they're just spoofing
that number and tricking someone into thinking that they've actually
physically hijacked their phone number and kidnapped that person.
COLTON OGDEN: Yeah, presumably, I mean, with this new ruling, hopefully,
you know, this sort of horrendous situation
doesn't end up becoming common at all, or at least it
gets completely remediated.
DAVID MALAN: Yeah.
COLTON OGDEN: Because this is one of the more terrifying examples of how
to abuse spoofing.
DAVID MALAN: No, absolutely.
And it's horrifying that it's gotten to this point
but, you know, what you might think is kind of a cool hack,
the ability to spoof your phone number, really
does have some non-trivial implications.
And especially, for most folks out there, you know-- myself,
before I even thought about this the other day after reading the article--
you might not even realize that this is possible
and what the implications, therefore, are of these sort of bugs at best or--
bugs at worst, or missing features at best.
COLTON OGDEN: Yeah, I mean I think if this even happened to me,
I think my initial inclination would be to believe it.
I mean, certainly it would be terrifying,
and you wouldn't want to take any risks and assume
that whoever's on the other end of the line
is actually bluffing you or telling the truth.
Now, speaking of ransoms, unfortunately, I
think these have cropped up in other contexts in the news of late
and for the past couple of years, in fact.
DAVID MALAN: Yeah, no.
I mean, there have been multiple cases, WannaCry being very prominent in 2017,
of these sort of worms that infect people's systems
and, you know, potentially encrypt the hard drive, or do other things,
and request that, in order to have this fixed,
the end user end up paying some amount of money,
either bitcoin or actual money, to decrypt their hard drive
or do whatever needs to be done to unlock their system.
COLTON OGDEN: Yeah, no, and that's the problem with worms, and viruses,
and just malware, malicious software in general,
is that, if it has the same privileges that you, the user, who accidentally
installed it, somehow do--
or worse, it has administrative or root access
to the computer-- it can do anything with your system and the data.
You know, it almost makes exploits like sending spam automatically,
unbeknownst to you, from your computer seem like completely delightful
in comparison because, now, these most recent forms of ransomware
are indeed doing exactly that.
They're actually running algorithms to encrypt the files
on your own hard drive and then not telling you,
the owner of those files, what the key is, the sort of secret
with which they were encrypted.
And, so, in this way can the bad guys literally say,
hey, pay us some number of dollars or, in practice, some number of bitcoins
in order to get access to the key via which you can unlock your data.
Who knows if you're even going to get the key.
I mean, frankly, an even more compelling ransomware
would be to just encrypt the data and throw the key away.
Then you don't even have to communicate further with the person
once you get that fund.
DAVID MALAN: Yeah, and, in light of this sort of horrible new trend
of ransomware that we've observed over the last few years,
there are companies that do try and take advantage of this and will say,
you know, we will help you decrypt your system.
We will use high tech, quote unquote, solutions to reverse this ransomware.
But it turns out that some companies, instead
of actually having the algorithms and the technology to do this,
are paying the actual people responsible for the ransomware
directly and then charging you a premium.
COLTON OGDEN: Yeah, no, this is really kind of a tricky thing,
and I'm reminded of most any Hollywood movie, where someone is taken hostage.
And, at least the US, in these movies, is always--
takes the position officially-- the US does not negotiate with terrorists.
Well, that may very well or not very well
be the case, because the closer you get to home,
and the closer you get to it involving people you know, or files you own,
or information you need, do these decisions become a little less obvious.
And it's a little harder to take that sort of moral stance, if you will.
And, in fact, in one of the articles on ProPublica was this wonderful quote.
It is easy to take the position that no one should
pay a ransom in a ransomware attack, because such payments
encourage future ransomware attacks.
It is much harder, however, to take that position
when it is your data that has been encrypted
and the future of your company and all of the jobs of your employees
are in peril.
It's a classic moral dilemma.
And that really does put it into perspective, right?
It's one thing to sort of argue-- no, we should not pay this ransom,
because it's only going to happen to us or perhaps other people
with greater frequency.
But, if you really need the data on that hard drive, the financial information,
the medical information, anything, the business information,
you're only recourse might actually be to pay the ransom
and then hopefully lock your systems down much more
effectively the next time around.
DAVID MALAN: Yeah, it's difficult when you're so--
when you're far removed from the problem,
it's easy to say, oh, just don't negotiate.
But, when you're actually there, when it's
your data, your information, your loved ones, it gets a little bit trickier.
It's a little bit greyer.
COLTON OGDEN: And, if you do pay that one time to get your data back,
man, you've just presented yourself to the bad guys as being someone
they can clearly fleece again.
So, it really boils down to--
try to avoid putting yourself in that situation at all,
and have all of the defenses you can think
of in place in terms of your systems, in terms of your personnel.
I mean, frankly, too often are these exploits
the result of social engineering, actually tricking people
into revealing their passwords by typing it into a website,
or tricking them into opening a link, or click on some attachment, or the like.
And then the whole setup--
your whole system can perhaps be compromised.
So, getting ahead of that and instituting better principles,
some of which we've discussed on the podcast, password length and so forth--
password managers can be just a step toward avoiding the problem altogether.
DAVID MALAN: Yeah, it's so tricky.
I mean, we have--
like we've talked about before multiple times,
the good guys have it the hardest.
The bad guys just need to find one way in.
COLTON OGDEN: Yeah, they just need to find
one employee who accidentally clicks on that link or discloses that password.
DAVID MALAN: One open window, so to speak--
[SIGH]
It's unfortunate.
It's unfortunate, because there are vulnerabilities
that ship, not only just--
there are vulnerabilities that don't arise just
out of the negligence of individuals but the negligence of companies themselves.
COLTON OGDEN: Speaking of--
DAVID MALAN: And, in the news recently, some folks might know already--
WhatsApp actually had a vulnerability that was revealed.
There was a company that was releasing spyware.
It was actually shipping spyware through calls
made through the WhatsApp application, which
is a incredibly commonly used application in the United States
and abroad.
COLTON OGDEN: Absolutely.
I mean, it is, ironically, an alternative to SMS or texting
that I alluded to earlier.
It's data based, in which-- a case that uses TCP/IP
and network protocols to actually transmit the messages.
And, as best I could tell from actually reading Facebook's own disclosure--
Facebook, of course, being the owners of WhatsApp--
it seemed to be some low level code that actually rendered
the application vulnerable to a so-called buffer overflow
exploit, whereby they must be allocating some amount of memory
inside of the source code for WhatsApp.
And, unfortunately, at some point in their code,
they weren't checking to make sure that they were confining their use of memory
to that footprint.
So, if they allocated 100 bytes, they weren't actually checking
to make sure that they didn't accidentally write more than 100 bytes
to that location in memory.
And, if you're using a language like Objective C, or other lower level code
that's involved with networking, you might very well not
have the language to protect you from yourself.
And, in this case, it seemed to allow an adversary to actually install
malicious software on your own phone.
And, in this case, it seems to have been spyware of some form, which
is to say that you might have some software running
on your phone unbeknownst to you, somehow listening to you or your data.
DAVID MALAN: It's interesting, because CS50--
in your lectures, you even talk about buffer overflow attacks
and how to mitigate them.
COLTON OGDEN: Yeah, I mean that depends on how complex your code is.
It can be easy still using languages-- perhaps Objective C, in this case.
Although, they weren't very forthcoming with the particular
implementation details of the hack.
It's certainly still possible.
There are good tools out there that can help you detect these things.
Whether or not those tools were in use in this context is also not clear,
but it's sort of a fundamental flaw, at worst, or missing feature,
at best, to borrow our terminology earlier,
that this is even possible in these languages.
So, this is why there's been trends toward languages like Java, and Python,
and the like that actually don't even let you do this in this case.
DAVID MALAN: Yeah, with great power comes great responsibility
and a lot of weight on your shoulders if you're a low level developer.
COLTON OGDEN: Yeah, no.
And just think, to your point earlier, all it takes
is for one adversary out there with a little too much free time
to find the one bug that's in WhatsApp, though surely there's
many more than that.
And then he or she can have access, potentially, to a whole system
if the bug is bad enough.
DAVID MALAN: Yeah and, in this case, I mean,
they were even able to transmit the data if they didn't answer the call.
So they could get a call, not answer it, still get infected.
And it was the case that some of the calls
actually could be removed from folks' logs, too.
So, they wouldn't even be all the more privy to the fact that they got a call
and were potentially infected in the first place.
COLTON OGDEN: Yeah, you know, it reminds me of an incident a few years ago
now when Sony had some software--
DRM software-- for digital rights management
whereby, if you put, I think, a CD into your computer,
it would actually install what was effectively a route
exploit, somehow taking advantage of the ability
to install software, run it behind the scenes, but then cover its tracks,
and not even show up in the Windows Task Manager, for instance, as I recall.
So these are particularly malicious, and that was done by a company,
not even just by an adversary on the internet.
It's scary that this is still possible in systems.
DAVID MALAN: I remember hearing about that.
I'm not sure if it was us that talked about it,
but I remember thinking, wow, I can't believe a company that big
is doing something like that.
And who else might be doing something like that,
unbeknownst to the rest of us?
COLTON OGDEN: Yes, that did not end well for Sony,
if you take a look at the articles online or the Wikipedia article.
DAVID MALAN: I vaguely do remember people
being a little bit upset about that.
COLTON OGDEN: Yeah, but companies do make mistakes.
I mean, also in the news this past week was a zombie load exploits affecting
some of Intel's hardware.
That I find particularly scary.
And, in short, in this case, with the zombie load attack,
is it possible to essentially convince the CPU, the brains of your computer,
to leak information in ways that you didn't intend?
And this is problematic if one application
is able to see information from another application.
And, in fact, in this case here, thankfully, it
seems to have been the good guys, the security researchers, who uncovered
this first and reported it to Intel.
It's not known if it was actually exploited,
but they actually had a compelling proof of concept,
for which there's a nice video online.
If you Google zombie load Intel, you should
find at any number of articles which showed them
visiting various websites in a browser.
And then, in a little command line interface,
where they had written a program that was just running behind the scenes,
they were able to log all of the host names
that were being used by the browser to access those web pages,
effectively leaking information across processes, which should not
be possible on a system.
DAVID MALAN: Yeah, it's pretty chilling.
I mean, in that same article they talked about--
this might be host names now, but this could be your security--
this could be your tokens.
This could be your passwords.
This could be any bit of--
your card numbers, what have you, any bit of information
that is going to potentially lead to a massive security vulnerability for you.
And it's scary when it's hardware, too.
I mean, hardware is supposed to be the stuff that doesn't need to be updated,
but that's just silly and naive.
I mean, running on today's hardware is essentially embedded software
or firmware, as it's typically called.
And most people, frankly, probably aren't
really in the habits of updating their bios in the PC world, or that low level
software.
Apple, thankfully, takes care of this for users.
And, so, who knows how often these things are actually discovered?
But, when it's baked into hardware, that even
puts it a little more out of most people's reach.
COLTON OGDEN: Yeah, no, this is pretty frightening, because, I mean,
this transcends just what might be one person's physical machine.
This could easily apply-- and CS50's own infrastructure is a big part of this--
to virtual machines hosted in the Cloud, because these all eventually run
on physical machines.
But, you know, one physical machine that might be running since CS50's code
with x other company's code--
x company might find a way to get access to all of our credentials,
or whoever other company, right?
Because it's all, you know, at the hardware level.
DAVID MALAN: Absolutely, it's frightening.
COLTON OGDEN: There was something interesting that I saw, which was--
and this is one of the coolest, cleverest ways I've seen of, again,
abusing a system, finding a way into a system that you shouldn't have,
and that's with Google Drive.
So, somebody released, on GitHub, a program that actually allows folks--
because here's the thing with Google Drive.
You can store, in your Google Drive, unlimited Google Docs.
There's no quota cap on Google Docs.
But this is only for Google Docs format.
But somebody found a way to encode arbitrary information,
arbitrary binaries, as Google Docs.
And, well, that essentially led to them having
unlimited disk space in Google Drive.
DAVID MALAN: Yeah, and I would say this is
more of a theoretical convenience than a practical one,
because there's some overhead in running the software.
But, yeah, it's kind of a brilliant sort of hack,
if you will, or exploit, or work around, when really it's
just kind of taking advantage of the design of the system.
Like, normally, you're supposed to use Google Drive, and Dropbox, and iCloud,
and those other kinds of file based services by dragging and dropping
your files, whether it's a text file, or binary file, or video file, or program,
or whatever, into the drive or up through the browser, and it gets saved.
But, of course, it takes up some number of bytes, or megabytes, or gigabytes,
and that counts against your finite quota.
But, for reasons that maybe the staff of Google
who wrote Google Docs didn't think about this, or didn't think anyone
would be crazy enough to try this, it's really kind of cool.
You can take any binary file, convert it to text using something
like Base64 encoding, which is similar in spirit to Bas10, or Base2,
or Base16, which are decimal, or binary, or hexadecimal, respectively.
But just turn it into text, and then automatically paste it
into one or more Google documents, and then
reconstitute it later when you actually want to download the data.
I mean, frankly, this is probably more annoying than anything,
and Google could clamp down on this pretty quickly.
They could probably say, you know, if you have a million Google Docs,
you're probably not using them for Google Docs purposes.
So, they could put some thresholds in there,
but it would be fascinating to be privy to the chats going on
at Google, if someone was like, oh, we knew this was possible,
but we just didn't worry about it, because it's not that useful,
or if minds were blown and, wow, that's such a clever sort of exploit.
COLTON OGDEN: Yeah, no, if folks are interested,
they can go to GitHub.com/StuartMcGowan/UDS and see
exactly what's going on.
I imagine, probably very soon, it will no longer be a relevant codebase.
I have to imagine Google's going to find a way around it.
DAVID MALAN: No, this is one of those this is why
we can't have nice things situations.
COLTON OGDEN: Yeah, no, but it's a very fascinating experiment.
Another company-- another big company is Microsoft.
That's a little bit of a segue there.
They released a series of patches recently for some vulnerabilities
that apparently exist on older versions of Windows,
for operating systems such as XP and Windows 2003, among many others.
DAVID MALAN: Yeah, so, for those of you still
running Windows XP from like 20 years ago, this is for you.
COLTON OGDEN: Yeah, 16 updates targeting at least 79 security holes
in Windows and related software, which is awesome that they're actually
being proactive about doing this, and they're not
doing this on the heels of an exploit that
comes out from some nefarious actor--
DAVID MALAN: Granted, but it's also terrifying that, since the last update,
there have been 79 security related bugs fixed.
And those are the ones that have been fixed.
Let's just imagine how many have not yet been discovered, let alone fixed.
COLTON OGDEN: Right, there was one I remember reading that was a day 0
vulnerability that they had just fixed.
And there was another fix for remote desktop services, which
is built into various versions of Windows, including 7, Windows Server
2008, R2, and Windows Server 2008.
So, pretty crazy that--
and all of these computers may have been compromised,
may not have been compromised, at least to folks' knowledge.
But, at the very least, now, people are running this software.
They can rest assured that a small chunk of potential vulnerabilities
are at least taken care of now.
DAVID MALAN: Yeah, well, and for those unfamiliar,
worms are among the most scary of malware attacks,
whereas a virus, for instance, is the kind of thing
that you have to sort of accidentally or foolishly
click on a link that opens some software and runs it,
or you have to open an attachment that actually is infected with software.
A worm is, by definition, self propagating.
So, once that process or that program is running, perhaps unbeknownst to you
on your computer, it can spread, via a network connection,
to another computer, or another computer, or another computer,
if all of those computers are themselves vulnerable.
And, in this case, too, if your system's not already patched,
you are in fact vulnerable.
And, so, this frankly really got me thinking
about a trend, which is a good thing in recent years,
especially in the Apple ecosystem, which is essentially compelling people
to automatically update.
Auto update, dare say, used to be more of an opt in thing, not on by default.
And, to be fair, you do in some contexts still have
to opt into it on Apple's platforms.
But it's getting more and more in companies' interest
to sort of compel users to update, and this
is helping to narrow the number of systems that are actually vulnerable.
Because, if you're auto updating on a schedule,
at least you're with a lower probability of running the older,
more vulnerable stuff.
So, it's a good thing, generally speaking, to have auto updates on.
COLTON OGDEN: I know Windows 10 is the particular offender in this realm,
because they are hyper-aggressive about making you automatically update,
and they make it really difficult for you to actually get out
of that behavior.
DAVID MALAN: Yeah, no, this is very true.
And it backfires in terms of UX or user experience.
I remember years ago, when the Xbox One first came out,
we had one here in the office for students to use.
And the first thing we tried to do was set it up around the holidays,
and everyone was so excited that we had the brand new Xbox One
and wanted to play some game, maybe a soccer game or something like that,
on it.
And, so, everyone plugged it in and, just like Christmas morning,
everyone's ready to start, and then--
downloading, downloading.
And then, like, no joke, an hour or more later,
was the Xbox finally ready to let us play a game, by which point
Christmas was over, or whatever the day was.
And, so, it really kind of got in the way of a good user experience.
But, maybe that protected our system from being compromised.
So, it really is a trade-off, which is thematic in computing.
COLTON OGDEN: Yeah, trust and trade-offs,
if we had to boil down CS into two words--
DAVID MALAN: Yeah, I think that's pretty apt.
COLTON OGDEN: Well, somebody actually requested
we talk about this, which is kind of a cool thing.
Careers and technology would be the topic here.
DAVID MALAN: Yeah, so we got this question from one of our listeners.
I like these.
Can you talk about careers in tech in a future podcast,
maybe what areas have more job openings in the next few years,
what skills are in demand, and what areas may decline in the future, also
maybe the interview process?
So, a bit of a loaded question--
I think we can touch on this a little bit
here and certainly welcome other such questions.
I mean, it's hard to go wrong nowadays, certainly,
in bolstering your technical comforts and your technical skill expertise.
It's so much easier these days to find access
to high quality educational content for free on the internet.
You don't need to necessarily go through formal schooling
or pay for these actual programs.
With that said, it's tough to predict these trends.
I mean, there's certainly things that are in vogue these days.
Python, for instance, is a language that's
very much in vogue these days for web programming, for data science
applications, for interactivity.
JavaScript is another one that's perhaps even more popular
and trending these days, both on the client side and the server side.
And then there's the whole, like, operations world,
technologies like Docker, and virtual machines,
and so forth, that are really transforming how systems
are hosted in the Cloud and elsewhere.
So, there's a lot of exciting trends.
But, frankly, I think, rather than even chasing these trends,
I think you can't really go wrong in studying, really first
and foremost, the fundamentals and focusing on having a strong software
background with procedural programming, with classes like CS50,
functional programming, object oriented programming,
as by taking other classes, and then keeping an eye--
that really opens doors, I think, to all sorts of entry level and higher level
software jobs.
COLTON OGDEN: Yeah, problem solving I think ultimately--
DAVID MALAN: Absolutely.
COLTON OGDEN: That's probably the number one skill that I
would say people should focus on.
DAVID MALAN: Yeah, and then certainly, at a lot of the bigger tech companies,
certainly in the software context, are--
the interview process really focused on problem solving.
Generally the types of questions you might have are generally
language agnostic, or the interviewers often
don't care what language it is you're using to solve a problem.
Frankly, your syntax doesn't necessarily have
to be 100% correct if it's more of a Whiteboard kind of conversation,
or even just like a Google shared document on a telephone call or video
conference that you might have.
The goal really is to get a sense of how people think
and how they approach programming.
I mean, frankly, I, when we've interviewed folks
even for part time or full time roles here on CS50's team,
for software oriented roles, what I really want to do
is get a sense of what it would be like to work with that person in a room,
in front of a whiteboard, with his or her laptop
off to the side, where we're just designing the solution
to a problem, even independent of code.
And, so, I think, being able to have really robust design conversations,
being able to understand, as you know, the trade-offs between doing something
or something else when it comes to designing a system--
that's, I think, one of the best ways to prepare yourself for this.
COLTON OGDEN: Yeah, I think, given our experience here at CS50,
and based on just what I've read, it seems like the model
that big companies have taken in recent years,
or maybe even not recent for a lot of the larger ones, the whiteboard sort
of model, and the problem solving based model, I
think even smaller companies are probably adopting this a bit more
than they used to now.
Because people are getting a lot more of an influx of software developers
looking for work.
And, so, I think we see this thing pretty commonly.
DAVID MALAN: Absolutely.
COLTON OGDEN: And it does ultimately boil down to,
not what language you might be comfortable with,
but, you know, the ultimate the core problem at hand,
which is what CS50 tries to teach.
It's not-- we advertise ourselves-- you advertise
the course as not a course on programming,
per se, but ultimately on problem solving.
DAVID MALAN: Yeah, absolutely.
And, speaking a little more practically here,
at Harvard we have a tradition, thanks to some former teaching fellows,
of holding a prep and practice for tech interviews every year.
So, if you actually Google or go on YouTube and search
for CS50 prep and practice for technical interviews,
odds are one of the recent years' videos should pop up
where CS50's own Tommy MacWilliam, a former head teaching fellow,
actually leads folks through a discussion of how
to and not to format your resume, how to prepare for an interview,
how to conduct an interview.
So, you might want to check that out.
A very popular book here on campus, too, is
one called "Cracking the Coding Interview,"
or Cracking the PM, product management, interview.
Those, on Amazon or other websites, might be of interest as well,
just as a nice, thick reference book as to where you could begin.
Frankly, it could take you weeks, months to go through everything
in those texts, but it'll give you a sense
of how you might go about preparing.
But, in short, in terms of the opportunities themselves,
I would say hard to go wrong in the DevOps world,
knowing one or more programming languages,
knowing a little something about how you can run an application using
Cloud services of any sort, certainly version control, and GitHub,
and GitLab, and other such products.
And then also security, just being one who
can help companies understand and analyze threats
to their system, who can chase those things down,
who can help secure systems--
I mean, there's no lack for need in the security space as well.
COLTON OGDEN: Yeah, having technical literacy in this day and age--
I think that is incredibly useful.
We're only getting more automated.
DAVID MALAN: Yeah, absolutely-- so, a lot of exciting
opportunities out there.
And I think, if you just get to first base with some of the fundamentals,
and taking one or a few classes, or experiences, or boot camps,
or the like, can you really then bootstrap
yourself there onward until you really feel like you're hitting home runs.
COLTON OGDEN: Awesome.
I like how that ended, some solid advice there.
DAVID MALAN: Thanks, I don't know if that metaphor works.
But it sounded kind of poetic.
COLTON OGDEN: Well, thank you for coming here to do this podcast with me.
DAVID MALAN: Oh, well thanks so much for having me.
COLTON OGDEN: Episode 5, zero index of the CS50 podcast--
what are some takeaways that you would recommend from the discussion
here, since we like to end with a few takeaways?
DAVID MALAN: I know.
I worry the theme too often is be afraid, be very afraid.
But I think, hopefully more constructively this time,
are there things you can be mindful about.
And, honestly, thinking about technologies from first principles,
even in the context of virtual kidnappings,
god forbid, understanding-- well, wait a minute.
How is this happening to me?
Don't necessarily take things that you see on a system at face value.
Consider what sequence of steps might have led you to see this symptom
and then decide for yourself, in an informed way, yes, this is a threat,
or no it isn't.
And I think just knowing how to defend yourself as well-- don't get yourself
into the situation of things like ransomware attacks
or vulnerable WhatsApp applications on your phone.
Make sure your auto updates are on, which is probably
a net positive in general, even though updates can be rolled out
that are themselves buggy.
That's probably the lesser evil--
so, staying on top of your system and not just using things out
of the box the way you receive them.
In fact, a certain someone comes to mind as
to whose iOS is not always up to date.
COLTON OGDEN: I was going to make a comment about that
when we got to auto updating.
Yeah, I have a bad habit of not updating my stuff as often as I should.
DAVID MALAN: Yeah, so I'm going to send you a link to episode 5 of the CS50
podcast and see what happens there.
COLTON OGDEN: All the talks that we've had in here
have convinced me that maybe it's time to start
taking that a little more seriously.
DAVID MALAN: All right, well, thanks so much for tuning into the CS50 podcast.
Looking forward to chatting with folks further.
COLTON OGDEN: Likewise-- thanks for tuning in.