 So, my talk is Fizz Buzzkill, and we'll talk about that in a second, but this is related to the concept of questions you might get in an interview. I am Russell Anderson. I am a husband and a father. I live here in Nashville in Inglewood. I'm a Christian. I'm also a terrible golfer, though it's probably my favorite hobby. It keeps me humble, very humble. And I'm RealRealRuss on Twitter. I work for a company called Simply Agree. It's a startup here in town, and we are workflow software for attorneys, specifically transactional attorneys at this point. I am a front-end developer, and I think that you can all glean from this weekend that that is a multitude of tasks and tools. I've been doing it full-time about five years, and I have no sort of outside computer science schooling or anything. I'm completely self-taught, but really I'm mostly colleague-taught. I've kind of leaned on a lot of really nice, really good people at the jobs that I've been fortunate to have to kind of teach me what I know. And I've mostly worked, like in everywhere that I've worked, I've used JavaScript, but it's always been in the context of a framework or library. Back in the day, that was jQuery and Backbone. It's been Angular. It's been React, but it's always been in this context. The irony of the picture that I chose here is that if the apocalypse were to happen, I would not be able to use any of these actual tools. I would want to build software and be completely useless. But the inspiration for this talk is there's a designer that I follow named Brad Frost, and he wrote a post last year actually called Why I'm Not a JavaScript Developer, and he basically took a list of front-end interview questions specific to JavaScript that is on the HTML5 boilerplate GitHub. And he sort of took every question and wrote kind of a smartass remark to it. So for instance, he said, why is it called a ternary expression? What does the word ternary indicate? Ternary means it involves three things and strings them all on one line so it's harder to read. And then he said, create a loop, so this is the FizzBuzz question. Create a loop that iterates up to 100 while outputting Fizz at multiples of three, Fizz at multiples of five, and FizzBuzz at multiples of three and five. So this is a actual kind of standard coding question. And his response was, that sounds hard, and for some strange reason I'm suddenly jonesing for Dr. Pepper. And so it was funny I read it and I was like, oh, yeah, that's funny. But it was like, it was funny, but then I thought I don't know that I could answer those questions. Like I use JavaScript every day and I build software with it, but these seem kind of basic and I don't know the answer to them. So and I figured that I'm probably not alone in that. Like you can actually build a lot of awesome stuff with the tools that you can use and not completely understand the tools themselves. So I thought a good talk idea was to take some of these questions and just try and answer them and answer them like succinctly as if I would have to be in an interview and maybe give some real world application to them. But before I jump into the questions themselves, I kind of want to address the point of like, are interview questions, are they a good idea? I think that this is definitely something, and if you're a junior developer and you're going to be going to a lot of interviews and you're going to probably doing a lot of code tests and things like that. Or if you're a hiring manager looking at it from the other way, you should know that a lot of times putting people on the spot with things like this is essentially creating a adversarial relationship with the person that you're interviewing. And that really may not be what you want to do. You might want to be in a position where you want a person to feel comfortable with your company, with your team. So I'm not necessarily a proponent of asking a bunch of arbitrary code questions in interviews. I figured it doesn't hurt to know the answers. So let's get started. We'll start with, this one is kind of a softball. And I guess I'll preface this by saying, if you're a senior dev in here, you're probably, this is old turf for you, but hopefully maybe there's some new things that you hadn't ever known exactly how it works. I learned something this morning just from researching this. And if you are a junior or a beginner, hopefully this will sort of answer a couple of questions for you. But this one is pretty basic, but it was one that I couldn't succinctly answer. Explain event delegation. Event delegation is JavaScript as it relates to the DOM. It basically means that if you attach an event listener to a DOM element, that listener is not only firing on that DOM element, it's actually firing on every children in that. So for instance, if you have a navigation, and so you've got an unordered list, and you've got list items, and then you've got anchor tags inside that navigation. What you have if you add an event listener to the UL, in essence, you're actually adding event listeners to all of the children as well. So it's something to, and this happens through a process called event bubbling. So it's sort of the inverse of the idea of delegating down. Bubbling is when it comes back up. So events on an element will bubble up to all of their parents. So when you click on that A, you're actually clicking on the LI, and you're clicking on the UL, and you're clicking on the body, ultimately. So that's the concept of event bubbling. So how it actually works out in practice, ways that I've found it useful are, for instance, if you have live edits to a form that you want to track. And you've got a form with a group of inputs in here. I may have to go over here to scroll. But you've got all different types of inputs, and you want to maybe test when they blur out of one of these inputs or they key up or something like that. Well, you could go through and you could target each one of these individually. You could grab all of them by a specific tag, and then you could do the special loop over them in order to add an event listener to every single one. So that would totally work. And then you'd have one function that would, you would probably have to create a different case for what type of thing it is in there. But you combine to it. But you can also just simply bind to the parent. So just grab the form itself. And everything inside of it that can change, that can fire a change event, is going to fire a change event. And so your form would run. And then in here you might have some sort of switch based on the name of that element or something like that. And this kind of demonstrates for us, this wasn't part of the questions, but it's sort of a bonus tidbit. You'll notice that when I'm listening to kind of a more universal event on looking for child elements that would trigger it, I want to use event target, not event current target. And so that's a bonus little tidbit that the difference between target and current target whenever on an event listener is that target is the actual thing that was clicked, whereas current target is what you attach the event listener to. So if you've ever wondered what that is, I had to answer that question like just last week. So that's a little bit about the DOM. Moving on, next question. Explain why the following doesn't work as an iffy. Well, in order to answer that, I actually didn't know what an iffy was. So what is an iffy? Iffy stands for immediately invoked function expression. So if you actually ran this code the way that it looks right now, you would get a syntax error in your browser. And what you would want to do is basically it's the idea of an immediately invoked function expression is basically I write this function and I run it. I just want to write it and then run it immediately. But you can't do it this way. And the reason why has to do with kind of another related question is the difference between writing a function as a statement or as a definition and writing it as an expression. So in JavaScript, any time there are sort of you have statements and you have expressions, expressions result in a value. And that's the concept of an expression. So if you assign a variable and try to attach a value to it, that will be read and interpreted as an expression and it will create a value. This creates more of sort of like a reference, but it's not an actual value. So you can't just run it. In fact, if you sort of tried to run this code immediately, this is how JavaScript is reading it. And it's like, this doesn't make any sense to me. You wrote this thing and then later on, you're trying to call a function that you doesn't have a name. This is weird. So instead, you need to, but there are a lot of benefits and I'll call it again into the benefits of the second of writing it this way. How can I write it that way and get it to run immediately? Well, you can make that function an expression simply by putting parentheses around it. So now that this is in parentheses, JavaScript is gonna interpret whatever is inside that parentheses to be an expression, not to be a statement, and then it can run immediately. So this is called an immediately invoked function expression. So I guess that begs the question, why would I actually need to use this? Well, in a lot of situations, and this is probably, if you're working within a framework or something like that, you may not need to. You may never end up in this situation. But the next time that somebody asks you to build them a simple webpage, then this is gonna be relevant again. You do it in order to control variable scope. So if you wrote this function, that function is not gonna be available. The variables inside that are not gonna be available outside of that function. And actually, the guy who's, Josh Mock is speaking right after me. He wrote sort of the best blog post that I found on this concept. And of like why you might wanna control that scope. And it used to be, I think for software developers, it used to be more of an issue because we were writing a lot of things with jQuery and there were a million jQuery plugins that could be in our application. And they all had very dumb and plain naming conventions. And I was like, I wanna use dumb and plain naming conventions in my application. So this is how you do it. And it kind of relates to another question on this list, is that why in general, is it a good idea to leave the global scope out of a website and not touch it? And it's because you can't predict the future. So 27 years ago, Robert Zemeckis predicted that the Cubs would win the World Series in 2015, and boy was he wrong. He was a year off, what an idiot. But seriously, you don't know, especially if you're building that web page for your friend, what they're gonna wanna pull in, what kind of libraries, and you wanna control your variable names so you never have collision within your scope. It also allows you to maintain independence, and it makes it easier to write your own code. You call things whatever you want, because it's self-contained. So that's a little bit about scope. Kind of adding on to that concept is this word, which is probably my favorite JavaScript word, which is hoisting. Explain hoisting. And before I wrote this talk, I actually had no idea what this was. I had observed it, but I had never quite understood it. It means that all variables that are declared using var, so this was kind of a specific problem. I'll get into how it's been addressed a little bit. But all variables using var are declared at the top of any given function scope, whether you really know it or not. Whether you sort of like it or not. And this actually includes the functions that are written as statements. Hold on, where were they? So the top example, this would include those as well, those are hoisted. So this is kind of an example of what you might see. But this is, I used to try and do this all the time. I would say, okay, I've got a variable and under this condition, I want that variable to be this. And in this other condition, I want the variable to be this. And I would just be like, well, I haven't created this variable anymore. I'll create it here, and then here, I'll create it. And then maybe I have another case where I don't need to create the variable. Yay, I've saved memory or something that thought myself in my head. But if you use a linter or something like this, you will probably notice that this chokes. This does not like you to write it like this. It would say something like action is already defined on line six. Because this is in reality what is happening behind the scenes that you don't even know about. But JavaScript is taking that var and it is creating var action up here at the top. And then what it's seeing here is that you're trying to declare this variable that's already been declared. Not only are you assigning it a value again, but you're declaring it again and it's like, what are you doing? This is what JavaScript is actually doing to your code. If you write functions as statements like this, those functions are actually all being hoisted to the top, the entire function. This is sort of why, and I had never really understood this, but sometimes I would write a function and I would try and call it, and it would say that it was undefined. But then I would move it in another place in the code and it would work. But then other functions didn't seem to work that way. Well, it all boils down to whether you write them as statements or assign them to variables. So, yeah, liners will kind of bark at you about this because it's sort of not clean code and it's. But it actually works in the browser. Browser hasn't had no problem with it. But it means, what hoisting means is that technically this works. You can have your whole if statement, you can assign value to it, assign a different value, and then declare it further on down in the code. And this is totally fine for JavaScript and actually in the browser. So, this is pretty absurd. This is one of the reasons why people say that they hate JavaScript and whatever, and we have bad reputation, whatever. So, in walk, this has kind of been addressed with ES6 and the idea of constant and let. So constant and let are ways of assigning variables that are not hoisted. They are actually even more than scoped within the function that you're in. They're scoped within the block that you're in. So if you're just in this if statement, you can have variables that are scoped within there that the outside part of the function will have no knowledge of. I would say that this makes more sense, like the more that I develop of wanting to control this, kind of initially I was like everything can know about everything, I don't care. But this is really good for kind of performance and things like that to scope things as closely to where you want to use it as possible. And it sort of gives you more control. And again, I mean your colleagues might not like you, but if you want to use like var x equals this and var y equals that, you can and you can use it all over. There's a really good article about it by the German Dr. Axel Rauschmeyer about this. Variables and scoping in ES6, I would highly recommend checking it out. So I guess the question is sort of after knowing these things, what do we do with the knowledge of hoisting? Like does it actually change the way that we write our code? And I'm really, I'm not gonna touch this one. This is like, I think that this has been pretty well argued ever since constant and let came out of like which ones you should use. But I do see a value in declaring things as closely to where you're gonna use them. And I think part of my original intention here is what I learned about hoisting was hoisting constant and let give you block scoped variables. And hoisting was basically trying to fake that the whole time. So constant and let are basically solving the problem that's existed in the JavaScript of we want to do this and we can't. So we use hoisting to sort of fake it. So I'll probably be writing constant and let mostly but. So speaking of, I've used the word declare a lot. There's another question of what is the difference between a variable that is null, undefined or undeclared? So we'll start with undeclared, it is not simply a short live show on Fox. Anybody ever see undeclared? Yeah, if you like freaks and geeks, you might check out undeclared. It's not as good, but it's, you know. So undeclared is basically when you try and use a variable that you've never sort of used before. You've never written out var foo equals or const foo equals. But you try and use it in some kind of manner. So that's a pretty simple concept of what is undeclared. It's just you forgot something somewhere or you ripped out some code. In my case, you ripped out some of your co-workers code and now it's not working. So that's undeclared. Undefined is a little bit different. Undefined means that you've declared it, but it doesn't have a value. It has not been assigned a value. So these are all up here at the top are all kind of examples of ways that you might get undefined. So if you just declare a variable, don't assign a value. If you have an empty object or you try and grab something on an object and it's not there, you'll see undefined. Same goes for like the index of an array if nothing is there. Or if you run a function and the function doesn't return anything. So that which is totally fine to do. Undefined is not always undeclared is sort of something's gone wrong. But undefined you could get for all kinds of reasons. And it's not necessarily an indicator that something has gone wrong. The cool thing is with constant is that you can only use constant. Whoa, look at that. You are forced with constant to assign a value to it whenever you declare it. So that may change actually the way that you want to use things. Because in a lot of situations I don't want to do that. I want to create a variable and then have it change depending on situations. But that is kind of nice because you'll never sort of have the problem of a constant being undefined. And then you have, yeah, I've got this whole list of important information. It's also falsi, which kind of plays into that it's not necessarily an indicator that something's wrong. You can definitely use it in some kind of logic condition if you're looking for falsi. No is a little bit different and it's kind of nuanced. But no is a value. It's just not a value, you know? No is actually the interpreted as having a value. That value is no, it's a nothing value. It's a way of sort of creating a placeholder assignment for something that would have maybe other values. You see this all the time, especially like if you're dealing with an API, you might have something on an object that's returned from your API. You might see the key there and the key's value is null. And that's completely right. And if you ever have a situation where you need to sort of zero out of value, null is a great tool in order to do that. Because the idea of zero as a number, well, that's actually a value. Or zero as a string, well, that's certainly a value. So you can use null instead. Yeah, look through my notes here. So finally, what the question is, how do you go about checking for any of these states? Well, the first one is kind of easy. Undeclared will usually find you. I say usually, but it doesn't always find you. Because if you're trying to assign a value to a variable that hasn't been declared, JavaScript will totally let you do that. And it will go ahead and attach that value to the global scope, which is really bad. So essentially, all that stuff that I talked about about not touching the global scope, JavaScript will let you just do that if you leave off the word var. So be careful. Use a linter, that's what I would advise for there. And this is another one of the reasons why people hate JavaScript, but whatever, haters. Now, if you want to check for undefined, this also kind of sucks. Because if you check, you can use type of, it's really handy to check for like if it's a number or if it's a string or whatever. If you try and do use type of, it will return undefined as a string. Which is like frustrating, because all of a sudden, we're dealing with this information that is in a different type than what it actually is. So you can't use type of this inequality checks, because you've got this word undefined as a string. Undeclared variables will also return undefined if you try and type of them. Now I'm beginning to see why people hate JavaScript. And if you, so the preferred method would be to use a triple equals. To check if something is undefined and not in a string, by the way. Even though that doesn't make any sense, because, yeah, anyway. So because if you look for undefined as a string and check it against undefined, even though this is what the console spits out, it will fail. So yes, check for undefined with triple equals and the reserved word undefined. With null, type of null actually returns an object. It will say that you have an object. This is a bug in JavaScript. This is a literal bug in JavaScript that they are not fixing because they have higher priorities. And by they, I mean me, because it's a community. Like it all falls on all of our shoulders. So, but you can also use the triple equals with the reserved word null in order to check for null. And then finally, like this triple equals thing is just, it's always a great question. But what is the difference between double equals and triple equals? And so here's an example. Foo is undefined, bar is null, and foo double equals bar is true. Yeah, that makes sense. Essentially, what you have when you use double equals is a check for equality and JavaScript sees null and undefined as both sort of having no value. And says that those are equal, even though they are not the same type of thing. So triple equals is always going to check for equality and type. And if anybody here has like done any sort of like, recent learning, everybody loves audience participation, right? How many people have been told always use triple equals, no matter what? You've been lied to, you've been lied to people. The reason people tell you that is because they don't think you're smart enough to understand it and use it correctly. But you can absolutely use this correctly. And if you know what you're doing and you want to use the double equals go ahead and use it and put a little comma above it for the rest of your developers to like not go in and change your PR or be mad at you. Because you know what you're doing. So that's pretty much it. I'm gonna skip the event loop because it really deserves its own talk. I just had it in there because I thought that, yeah, never mind. I knew I was the only one who knew what I was doing. I just had it in there because I thought that, yeah, never mind. I knew I was not gonna have time for that, but just in case. So anyway, you guys, since you're at this talk, you are hired. Hopefully you get a boss just as fun as Kimmy Schmidt's boss, wherever you go to work. And there are a ton more of these up on HTML5 boilerplate. It was a fun exercise for me to just go through these and be like, which of these can I not answer quickly and I cannot answer well? But I just want to sort of say at the end of this talk, I've been doing this for about five years and I'm now sort of like the senior guy on my team and everything else, but it doesn't really account for a whole lot necessarily that you can answer these questions like super well. My encouragement to anybody at this conference who's sort of like me, feeling really overwhelmed and really like, I just don't know how I'm gonna actually apply this to my application coming the next day. I just really encourage you to just keep moving forward, building whatever it is that you're building. Just build good software. I think a lot of times as developers we focus on the tools that we're using, the best way to use those tools, the most efficient way, which I totally get and I totally love to do, but we lose sort of focus on like that we're here. We're getting paid to deliver badass software. And if we just focus on that, then the tools we use in the decisions and the learning is gonna come alongside that and happen as well. We don't have to learn all this stuff first and have all these perfect answers or even really know the perfect terminology for what it is that we're doing in order to make awesome software. And I am a pretty good example of that because I won't say that I can make software without knowing whatever it is that I'm doing. So anyway, that's the talk. The slides are up on my website if you wanna have them. And then I've got two minutes, so I will take questions. Are you a pilot? Am I what? My brother-in-law is a pilot, and I thought that, I mean, that's admittedly a very douchey picture, so I apologize. But the other one that I had was me inside the head of a dinosaur. That was my original picture. And yeah, anyway, I would love to be a pilot because I thought it was awesome. But other questions? Yeah, yeah, I mean, I think that that is like, that's a really key piece, is understanding that the questions themselves are sort of arbitrary sometimes when you're trying to test. And I understand the desire to use them in order to kind of vet people. But I think that maybe better questions to ask would be like, how do you handle a situation where you've said that you would meet a sprint deadline and you realize that you're not gonna meet that deadline? What do you do in that situation? Or what do you do when your designer comes to you and you've already had something scoped out and you are already two weeks into a sprint developing something and your designer wants more changes? How do you handle that situation? Like kind of more, I think what you can probably dig deep if you come up with sort of clever questions about how a person actually works is hopefully they're gonna use the technical stuff in their answer. And that's gonna give you the vetting that you need. So that would be my hope. I think that the thing about interview questions like that is that, yeah, I mean, it's creating this adversarial situation. I just did one recently, like a last month. And it was with, my first initial interview was with two people that were on the dev team, not with a hiring manager. So I kind of immediately knew, they're weeding me out here. And then they had me do a code test and I was like, man, I got this, no problem. Like if they put me up to a code test, it'll be no problem. And I was like panicky, I was like, ah, you know, and that's really just not how it doesn't really mimic actual work behavior. You'd never be in a situation that you would be up under the gun like that. So it's not necessarily a good indicator, but yeah, Ryan was mentioning like a code challenge that a prospective employer gave that was was a homework assignment and it was basically they gave you JSON and they gave you either an API endpoint or a blob of JSON. And they were like, just just make a UI out of this. Like that could be something really cool as long as it doesn't sort of take so much of the person's time that it wouldn't be worth it for them. But yeah, yeah, that's a great point, right, totally. I think I'm officially out of time, but I'd love to continue this conversation with anyone after the session. So thanks everybody.