Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. Today I'm going to be answering a few front-end developer interview questions. If you're not familiar with the front-end developer interview questions repository on GitHub, I would recommend that you take a look at it, especially if you are either hiring or looking for a job as a front-end developer. It is a very well put together set of questions that a ton of people have contributed to. In fact, there's 135 contributors. I've talked about it on the show before. It is under the HTML5 boilerplate user on GitHub or the organization rather on GitHub. So it's at github.com front slash h5bp. You'll find it there. It has a ton of stars. It is quite popular and there's a ton of really good questions on here, including general questions as well as pretty specific questions. Today we're actually going to cover one general question and one specific question. I want to start by saying that most of these questions have multiple answers. There's no one right answer. And that's also even more true because what may be right today may not be right next year or even as soon as tomorrow. So the questions on this repository are more to get an understanding of how you think rather than to quiz you or to get you to answer really specific information. Of course, there are specific questions, like I said previously, that test your knowledge about a given subject. But again, those questions quite often have more than one simple answer. There are some questions that have essential content responses that you should know if you are looking for a job in this field. But most of these have quite a few different answers. So this is mostly an opinion is what I'm saying. What I'm going to tell you is mostly an opinion. However, this first question does have a pretty specific answer. So you can walk away with some actionable knowledge from today's episode of Developer Tea if you didn't already know the answer to this question. The question is a JavaScript related question. And it's very simply, what is the difference between call and apply? And specifically on the on the repository, it's the dot call and dot apply. And that kind of gives you a little bit of an idea of what these are. These are actually methods that you can use to call and apply. And you can use them to call and apply. And you can run on a function object. So you could say, set a variable foo equal to a function, and then run foo dot apply or foo dot call. Now, why would you want to do this? Why would you want to call a function this way, rather than actually just calling the function like you normally would, by saying foo with parentheses? Well, it turns out that JavaScript has a very strange way of dealing with a keyword called this. The keyword this in JavaScript refers to the owning object. It may be similar to, in other languages, the keyword self. However, if there's not a particular function that owns the object that you've created, then this refers to the global context or the parent context. And it gets a little bit confusing if you aren't controlling this more explicitly. And that's exactly what the .call and .apply methods allow you to do, to pass in the first argument to both of those, which is the context on which to execute that function. So if you had var foo equals function, and then you do something inside of there with the keyword this, you can control what that particular keyword refers to by using .call. So foo.call and the first function parameter would be the object that this refers to. So getting to the question at hand, what is the difference between .call and .apply? Let's imagine that your function takes two or three arguments. If you wanted to pass in arguments when you are using the .call function, you would pass them in as you normally would. So for example, let's say var foo equals function, and there's maybe argument one and argument two. Well, then when you do foo.call, you would say foo.call and then you pass in whatever the object that you want this to refer to is, and then you would pass in argument one, argument two. .apply works very similarly, except instead of passing in your arguments as regular arguments, you pass them in as an array of values. You pass them in as an array, which is a single argument, technically speaking. So syntactically, you would simply wrap those arguments in square brackets. .apply is a set of arguments that you would probably want to use. If you are using a set number of arguments, you would probably want to use .call. A simple mnemonic device to remember which one is which. Just remember that .apply starts with an A, and that's the one that you pass in an array. So .apply is a set of arguments that you would probably want to use. If you are using a set number of arguments, you would probably want to use .apply. And in fact, array ends with a Y, and so does apply. So the one that begins with an A and ends with a Y is the one that you pass an array into. .apply takes an array, and then .call takes a arguments list, a regular arguments list, like you would pass into a regular function call. And that's it. That's the simple difference between .call and .apply in JavaScript. So we'll move on to the second question right after a very quick answer break. What if you could learn to build anything in one month? Well, with onemonth.com, you can. Just ask any one of the 20,000 students who have learned to code on onemonth.com by building real websites and applications complete with payment systems, security solutions, and full stack deployment. You can start without any prior experience in just 15 minutes a day for 30 days all online. That's because one month hyper focuses on applied techniques that you use immediately in the apps you are building as part of the program. So if you have any questions, feel free to ask them in the comments section. .apply takes an array, and then .apply takes a version of the program. So if you could learn .apply takes an array, and then .apply takes a version of the program. So if you have any prior experience in just 15 days or 30 days, you can start with a version of the program. One month's courses are the easiest way to learn new tech skills, including Ruby on Rails, Python, content marketing, growth hacking, and more. And the best part is, if you get stuck, there's always someone there to help you out while you learn. Yes, that's a real person, not an automated computer. So enroll now at onemonth.com front slash developer T and get 25% off your first month. Now, normally access to all courses costs $99 and access to one course usually costs $49. But with the special URL, you get full access for just $74 or one course for $37. That's less than $3 a day. Or if you do a single course, it's just over $1 a day. Enroll now for 25% off your first month at onemonth.com front slash developer T. So the second question that I want to cover today is a little bit more ambiguous. It has multiple answers. And that's why I think it's interesting. I think it's a good question to ask a potential hiring candidate. And I'm going to approach it the way that I would answer the question. So the question is this, if you have five different style sheets, how would you best integrate them into a site? So the question is referring to having five separate style sheets that you have to integrate into a single site. Now, I would start by asking a few questions in order to clarify the intentions of that particular style sheet or those particular style sheets. For example, if you have five different style sheets, how would you best do all five style sheets apply to the entire site? Or is there a style sheet for the home page and maybe a secondary style sheet for the admin pages and another style sheet that applies to, you know, the secondary pages that are public facing? What are the reasons for having those separate? If there aren't any good reasons to keep those separate, then I would most likely approach this problem as a separate style sheet. So I would start by asking a few questions. By finding a way to merge all of those style sheets into a single style sheet using something like Gulp or Grunt or even a front-end tool like CodeKit. And the reason I would choose to do that is because it's much faster to load a single resource than to load five separate resources on a given page. Now, if there is a good reason to keep them separate, then the real question is, is there a way to dynamically load the ones that we need to load, when we need to load them? For example, very few people are going to see the admin interface. So there's not a good reason for me as a public facing user that will never see the admin interface to actually load that style sheet. It's just extra weight that I don't need to see. Some frameworks already have this built in. Of course, you could solve this using a front-end tool like the one that Rebecca Murphy and I discussed called ScoutFile. And what ScoutFile does, they load these tools in style sheets and other JavaScript files using JavaScript, and it loads them in asynchronously from your website loading. So it does it really fast and it allows you to set really long caching times on these front-end files. If you had this kind of tool, you can use JavaScript to determine which ones need to be loaded for a given page. So for example, you could have a Scoutfile for only your admin pages that loads in your admin your admin pages that loads in your admin CSS and keep that in the header of your site or however you want to handle that. But find a way of loading in these things dynamically, of loading in only the things that you need to load in. Now, there are a few caveats to this approach. First of all, if you are merging five style sheets, it's possible that that would end up in a very large CSS file. And unfortunately, there is a limit to the number of selectors or rules rather that Internet Explorer will load. And that's Internet Explorer version six all the way up through nine. In fact, it has a hard limit at 4095 rules per sheet. Now you can solve this simply by separating your sheets into two sheets. And there are tools to do this. Specifically, there's one called the Internet Explorer. And it's a very large CSS file. And it's a very large CSS file. Bless CSS. And that one has a gulp and a grunt module that you can use to automatically make sure that your CSS follows these rules and loads properly in Internet Explorer. Now, another question that I might ask is, if all of that CSS was still necessary, is it possible that some of that CSS is left over from a previous design, or perhaps it was brought in as part of a framework or a plugin, and it could be stripped out? Is very possible that some of the CSS is no longer being used, and therefore can be removed entirely, which would speed up the load time of those CSS files, and perhaps more importantly, would make development in the future much easier to accomplish because it becomes much easier to reason about the code when there is less code to reason about. I hope this has been a helpful exploration of these two questions. And I hope that you can see the subjective nature of some questions when you sit down for an interview and the objective nature of other questions. Ultimately, if you are being interviewed, it's important that you can form an opinion and be able to back up your reasoning for that opinion. There's no shortage of opinions in web development, and it is a skill to be able to form an informed opinion about a given subject. In the CSS loading example, you have to take into account the number of questions that all different kinds of trade-offs and move forward. It's important to be able to make a decision based on your formed opinion and explain why your opinion is what it is to be able to back up whatever you choose to do, given a set of circumstances. If you are able to form an opinion and act on that opinion, that is a skill that makes you hireable as a web developer. I hope you've enjoyed this episode of Developer Tea. I hope it has provided some value, if it has, please consider giving us a review in iTunes. This is the best way to help Developer Tea out. Of course, I appreciate every moment that you listen to this show. This show is here for you, and I am so happy that I have so many awesome people listening. You can always reach out to me on Twitter at at developer tea or email me at developer tea at gmail.com. And until next time, enjoy your tea. you