Interviewing for Front-End Engineers

Prescreen Javascript Questions

Jem Young

Jem Young

Interviewing for Front-End Engineers

Check out a free preview of the full Interviewing for Front-End Engineers course

The "Prescreen Javascript Questions" Lesson is part of the full, Interviewing for Front-End Engineers course featured in this preview video. Here's what you'd learn in this lesson:

Jem reviews and has discussions around common questioned used by larger companies to screen for baseline knowledge on JavaScript.


Transcript from the "Prescreen Javascript Questions" Lesson

>> After the initial call or even during the initial call, towards the end, or maybe it might be a separate call, you might get a series of prescreen questions. Usually these are the larger companies that wanna kind of vet you out before you get started, because interviewing someone takes resources, it takes manpower.

It takes people that have to take time out of their day to do these things. So they wanna give prescreen questions, say, is this person at least a little bit qualified to be a front-end engineer? So I consider these base line questions for JavaScript knowledge. So let's fire them off.

What is the difference between const, let, and var? Anybody?
>> Scope.
>> More.
>> More on that?
>> Yeah, yeah [LAUGH]
>> Var is global, generally. Let is a little bit more narrow, and const is fixed. You'll get yelled at by some JS lent rule if you try to change it later.

>> Okay, that was okay.
>> Okay
>> So have that each other. It was okay. Scope is a good way to finding it. Var, I wouldn't say is global, its global to whatever scope it but it's not gonns leak outside. But yes, const, it's not immutable, people say it's immutable, but we probably have different definitions of immutable.

You can't point a const to a different pointer. But you can modify that, you can add objects, or you can add properties to an object, things from array. We can't change that pointer. Let, you can change the pointer, but it's only gonna be scoped to whatever the closure is.

And var is hoisted to the top. So const and let, if you try to access them before they're gonna throw a reference there, var will just throw undefined. Pretty simple. These aren't trick questions. It's just how fast and how comfortably do you answer these questions? Okay, there are wrong answers, but there aren't as many wrong answers to this.

It's just like, does this person feel confident in their JavaScript knowledge? That's it, not a trick. And as the interviewer, you're not trying to trick them. These aren't trick questions. These aren't like one of trivia questions. These are just like, do you know what you're talking about? Someone explain prototypical inheritance to me?

Anybody, anybody at all.
>> I just did.
>> [LAUGH] All right, what's a prototype? Nobody, this is funny engineering. All right, nobody. Yeah, take a shot.
>> I'll take a shot. So when an object inherits from another object, if that object that it inherited from has some functions or properties, this new object, it will have those.

>> Yeah, I'll take that. Again, not a trick, JavaScript has a prototype, a baseline prototype of the object. Everything inherits from the object, so you can do all sorts of things. Everything in JavaScript has a prototype, it has a baseline object that it inherits from. And when you create a new object based on the other object, you can either inherit all those properties, which you will be default, or you can overwrite them with your own and so on, and so forth.

The analogy I usually use, it's not the best one. It's pretty good, is parents with children. Do you have one parent with brown eyes, you have another parent with brown eyes. The child could have brown eyes, or it could over write it and have blue eyes, something like that.

Again, I'm not looking for too much detail or depth, it's just, do you know what prototype is in JavaScript? Because it's underneath everything we do, and I expect you to have some baseline knowledge about that. It doesn't have to be in depth, but don't fumble on it [LAUGH].

Don't guess. If you're guessing, that's pretty easy to tell. And a lot of times with these questions, if it's a recruiter or things like that, they're not necessarily super well versed in UI engineering, they might be, you never know. But they're gonna have kind of a general answer, and they're looking for something that falls in that range.

Again, it's not a true or false or right or wrong. It's just talking about what does this mean in JavaScript?
>> It's the current scope you're in which can change and if there is no scope, that is the global window, object usually?
>> Perfect answer, exactly right. I considered the global context of everything that is available to access.

So all the objects and functions are available to you that are not locally defined. Yeah, and if you haven't thought about this kind of high level abstract questions, yeah, that's okay. That's what this course is for. What's the data structure of the DOM?
>> Tree.
>> Yes, it's a tree, that's it.

[LAUGH] Again, not a trick question, just have you thought about this before? What is a stack? It's a data structure, right, yeah.
>> LIFO, FIFO. Last in, first out versus first in, first out.
>> Which one is which?
>> Stack is LIFO, cue is FIFO
>> Yes, LIFO, FIFO, Last in, First Out is the stack, First in, First Out as a cue.

Think about if you need a mental model. You're standing in line, that's a cue. The first person that gets there's first one that leaves if it's a fair line Stack is, it's reversed. It's like you get line and then actually it's people in the back that go first.

You're like, what, scammed again? I hate going to [INAUDIBLE]. How you create these structures in JavaScript?
>> Bulk and bush with work for Stack.
>> Yeah, it is an array pop and push shift. Yeah, how can you tell if an image element is loaded on the page? This one is a little more nuanced but there's an onload element of Images You can just say is it on, has it loaded?

It'll fire that call back. All right, what are call() and apply()?
>> It's a way to call another method, but usually use it if you have to change the scope you're calling with. I can't remember which is which [INAUDIBLE] I put.
>> I never can either. That's okay.

All I would wanna know on this question is their ways of changing the scope of the calling function. Yeah, and call is a series of arguments and applies an array of arguments. Nice, we don't necessarily need to apply as much anymore, because we have props or we have array spreading, things like that.

But it'd be good to know. What is event validation? So traditionally, if you have event handlers in HTML, you could apply an event handler to every single element you wanna have. Or using event delegation, you could say I wanna have one event listener, and that's at the top.

And when you click on something, it just bubbles up to the parent that handles the event. That's an event delegation. I would want someone to know this cuz event listeners are really expensive on a page cuz every time it renders, gotta be like did something happen? Did something happen?

So it's better to have one event handler versus 60 for performance reasons. Event delegation. If you said something about bubbling, that's also good to use. What is a worker? A worker is something you would use in a browser to offload computationally expensive work. Three different thread cuz JavaScript is single threaded, if you have something that's like tactically prime to 10,000, numbers, something you want to do that and workers you're not blocking the UI, cuz there's only one thread in JavaScript.

And that's when you use one as well. All right, those appreciate questions. These are questions that I've been asked, that you may get asked and that I can consider good baseline knowledge of JavaScript. I know the HTML ones are a little tougher because we don't actually think in that way, so those can be a little dicey.

But in general, I would expect everyone to know these questions off the bat, just kind of pop them off. Again, not looking for precise correct answers. I just want that they have some knowledge of what they're talking about. But importantly, why I didn't ask is I didn't ask trivia questions.

I didn't ask what object plus array equals, which I've been asked in an interview. I don't know why. That doesn't tell me anything. It tells me they have some weird funny knowledge. But you know what's funny is, you get trivia questions and someone be like, I read this weird trick about JavaScript.

We'll hack the news. I'm gonna ask that to somebody. Is that relevant to the job? If they know that, does that inform you of anything that they can do other than they know some trivia questions? So if you're the interviewer, don't ask trivia questions. Ask questions that you know.

I see what I'm gonna face, its's even real close, real closer, closer. You're probably thinking your interview is easy, but that's because you already know the answers to them, that's it. That's my big rat. Everybody says my interview, my questions are easy. My Christian questions are easy, my interviews easy.

That's cause you already know the answer. If you didn't know the answer, would you be able to solve your own interview questions? Probably not, if we're being honest, probably not. If I'm being honest, I've asked questions that I wouldn't even know the answer to right off the bat.

If so, is that a valid interview question? This is something I really want us to take seriously as an industry. Don't ask trivia questions. Don't ask weird algorithm questions that aren't relevant. Ask questions that you would know the answer to or is necessary in your day to day working.

That's not much to ask, right? That was the application, the initial call. That was a lot. That was a lot of information already. CATSA process interviewing is a grind, it's about stamina, it's about endurance. And as the interviewer, what I wanna do is I wanna make that process as easy as possible.

Interviews are not gonna be easy, rhey're never gonna be easy. They shouldn't be easy. We get paid a lot of money for we do, but at the end of the day I'm not like bruised or bloody and sweaty. Maybe my back hurts from eating too much free food as I'm leaning over my computer.

But at the end of the day we get paid a lot of money to do what we do, interviews should not be easy, they should be fulfilling. Interviews should be like a first date, pretty awkward, a little challenging, you have to put your best face forward. At the end, do you think if it works out, you're yeah, that was really satisfying.

I think we got to know each other. I think I wanna continue on this journey with this person. There you go on a second date. That to me is what a interview should be. It should be challenging and rewarding at the same time, but it shouldn't be frustrating.

Not too much to ask, right?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now