Wrapping Up

[00:00:00]
>> Congratulations. This is one very long very difficult definitely not one to take lightly course. There's just a just dump truck full of knowledge here. And if you feel you just got hit in the face with a book, that's probably because it's pretty close to that right? So what I'm trying to say is don't expect all of this to sink in.

[00:00:24]
Some of these concepts you'll probably never ever think about ever again. And some of them you might find yourself thinking about frequently. One of the most important things though, here is that you've been exposed to these things, right? So now that if you come, to a time much later where you need something that a bloom filter could solve, you might not be able to remember exactly what a bloom filter is implemented like or how to make it work, all that kind of stuff.

[00:00:47]
But you now you know that there's a data structure out there is, that you can, contain a lot of information in one very small memory footprints right? And that kind of pattern matching ability is actually really what I want you to have to know that these things are out there, that you know where to find them, you know how to Google them, those kind of things.

[00:01:11]
And more than anything I really hope that you took away the science of trading off, right? The idea of do I have enough CPU? Do I have enough memory? Is this code more readable? Is this code less readable? Do I always wanna use as less memory as possible?

[00:01:24]
Do I always wanna have the fastest algorithm? These are all the kinds of things that I continue to want, you just need to be thinking about and hopefully the message that you walk away with is write readable code first, then worry about performance later. That's the mantra that I choose to live by when I'm writing code.

[00:01:44]
Yeah, spend time trying to solve problems. Don't try and spend time anticipating problems that you may never have. That's in general, generally you wanna have problems before you solve them because typically you will not solve the correct problems. And only when you need really raw performance should you really be dropping down into these really low level constructs.

[00:02:07]
But instead, it's just good for you to know one how things work. And then if you ever did need to drop down into these low level constructs that you know where they are and how to find them. So thanks for sticking with me. Hope everyone here enjoyed the course.

[00:02:23]
And yeah, I'll take any last questions we have before we wanna sign off.
>> Like you said all about balance all that stuff. That's not what's happening for me. I'd like, I just got invited for Amazon interview out of the blue.
>> Congrats.
>> Found myself in a predicament, essentially I build some stuff, I build websites.

[00:02:41]
But in big companies, tech interviews are focused on computer science more than what you build. And I've been grinding for ten hours a day solving lead problems. I guess the question is what impresses you on the interview?
>> First thing you kinda just have to know and embrace is you're not necessarily in control of your entire interview.

[00:03:01]
For me, that kinda takes some pressure off, I don't know it. For me it just, that helps me realize that, I can work on the things that I'm gonna work on and realize that the other parts are just gonna happen, however they're gonna happen and I lack control in that situation.

[00:03:17]
So that's the first thing. The second thing is that it's really gonna depend on who your interview is. Some of them are just looking for a checklist, all right, he found this problem. She did this, they did that right? And they're just going down their checklist. And so frequently you can kinda tell cuz they're fishing for specific answers.

[00:03:36]
In that case, I just asked a lot of questions of the hem to try and figure out what they're looking for and me that helps a lot. And then for me, I don't know, there's some interviewers and I think that are more like me, which is just like, actually don't really care if you can, pathfinding maze, right?

[00:03:56]
We don't path fine mazes at Microsoft, right, what I do, I mean, I guess the Bing Maps team does but I shut down. [LAUGH] What I care way more about is that you communicate that you're telling me what you're thinking that you're collaborating, you're thinking out loud, you're asking good defining questions.

[00:04:19]
All right, you're asked me to pathfinding, this maze. Can I go out of bounds? Are there extra walls? What color's the floor? I don't know, it's just really defining the problem space of that you're looking into. And that's the kind of person that I wanna work with that's gonna fully understand a problem and then devise the correct solution.

[00:04:40]
So yeah, ask a lot of questions. Another like really good pro tip with interviewing with those big tech companies is if you're having a hard time solving part of it, just make a huge assumption about it and ask if it's okay, right. So if you're saying I need to navigate this in 3D space, can I just invent a black box function that gives me the correct coordinates to go to?

[00:05:02]
I don't know, I'm making stuff up now. But something like that, where you just say like, you cut off a huge portion of the problem. You make an assumption about it. It's like, Hey, can I have this function? A lot of times, they'll be like, Yeah, sure. I don't care.

[00:05:13]
You can. You can assume that about your code, right? Then you don't have to solve problems for Ray you can kind of work and make them work against themselves. So
>> Okay, yeah, that makes sense. Just to try to simplify. Okay.
>> Always ask what metrics are going for right?

[00:05:31]
Am I supposed to be going the fastest? Am I supposed to be the most clearest thing? His memory a concern like asking a bunch of questions like that, about what metrics they're most interested in. That's also impressive and useful to you. So that helps, too.
>> So metrics, and you also mentioned, consider the cost of algorithms, right?

[00:05:51]
>> Yep.
>> He said I think, Okay?
>> Yeah, a lot of times will ask you like, what's the big O of this? I mean, again, I don't talk about bingo too much when I'm working at Microsoft, so I don't really care if you can come up with bingo but lots and lots of companies do so you should really drill down into that read up more on and do some exercises on defining the big old problem.

[00:06:15]
>> Okay, thank you.
>> Other questions.
>> I have one in the same vein is Victor's coming from someone who doesn't have a computer science background who went to a boot camp primarily for front end development. And you have a lot of experience with the larger companies that, I'm looking to try to interview for.

[00:06:41]
Do you have any recommendations or any advice for any approaches towards problem practice, leak code and whatnot that you find is very helpful leading into interviews?
>> Okay, yeah. So when I'm solving a computer science the problem, what are my kind of my steps?
>> Yeah, exactly.
>> I try and reasoned it out in English first, kind high level steps of, I'm gonna do this, I'm gonna do this, I'm gonna do this, then I'm gonna return this.

[00:07:13]
And then at the very least, the whoever's interviewing knows that you understand the problem and knows that you understand the solution. And then at that point, you're just in the semantics of syntax, right? So I found some people have been really effective with like, cool. I'm gonna create three functions.

[00:07:30]
I'm just gonna pseudocode this does this, this does this, and this does this. So even if you run out of time, it's like okay, I was interviewing Shawn and he got through the first two functions. I didn't finish the third one, but he obviously got with a third function was supposed to do.

[00:07:45]
That's I mean, it's not gonna work for everybody, right? It depends on what kind of jerk you're interviewing with, right? A lot of them will just say, cool, that's good enough. Obviously he knows what he's talking about. Some of them will be like I don't wanna name and shame the companies too much, but one of them in particular is just me like no, you had to read every semi colon or I'm not gonna count it.

[00:08:09]
But your best shot for sure is making sure that the full solution Is down however you choose to do that. My personal style is just to write the function signatures, the return types and the kind of high level comment of this is what this is gonna do. And then I go back and fill it in and that works well for me to both one, explain what my intentions are, and for me to organize my thoughts.

[00:08:35]
Well, thank you friends, please, do and redo these exercises. Cuz again, they are difficult. And the more you do them, the more they're gonna sink in. So yeah, thanks for spending some time with me learning some computer science. If you'd like to let me know on Twitter, star, the repo on GitHub, that's always fun too.

[00:08:58]
And be sure to share this with other people as well. Hopefully it can be helpful for them as well. All right. Thanks, everybody. Talk to you later. Thank you very much. Thank you. Yep. [APPLAUSE]