Interviewing for Front-End Engineers

Phone Screen Coding Solution

Jem Young

Jem Young

Netflix
Interviewing for Front-End Engineers

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

The "Phone Screen Coding Solution" 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 talks through his solution to the exercise, and what the solution was looking for in terms of understanding the participants knowledge - from pitfalls with performance, to understanding document fragments, rendering and not being dependent on any particular framework.

Preview
Close

Transcript from the "Phone Screen Coding Solution" Lesson

[00:00:00]
>> All right, how was that? For some of you that was probably a bit challenging. For some of you, crushed it. Rolled through it easily. So in the interest of honesty and fairness, I also did this code challenge. I did not do it before. I wrote it up, but I didn't solve it until I was solving the same time you were.

[00:00:21]
Here is my solution. So here's the general blah, blah, blah. I don't modify this. I created this. So every other solution I will live code after I've done but this one I'm a slow typist. So just trust me that I did it. I didn't cheat. I even here I left up my Google queries because I also need help.

[00:00:41]
I don't remember these things. I'm not perfect. I had to look up this stuff too. So my solution was I created a class. And I know that it takes an element of some sort, it takes food data doesn't matter on the order. And I'm just creating those in the scope.

[00:00:55]
I created a function called render list. Actually did this last cuz it's probably the last thing I need to worry about. But what I did was I knew that I needed to create a list of items. And I didn't want to do that in this one function. So I created this separate function called createFoodItems.

[00:01:13]
Now, on this question, was this challenging, or was it sort of in the middle? Sorta in the middle, challenging? For a lot of people, and this is generally the kind of the style of code question I like, it's are you very, very, very dependent on frameworks or do you understand kinda the basics of can I create an element, can I create an end listener and things like that?

[00:01:35]
That's why I like to ask this question. Is I don't care about specific framework knowledge or expertise. You could be the world's leading a react expert. Can you create an HTML page that renders stuff into the dom? That's it. And to use that I had to use create element, which is my go to, yes, I'm using a <div>.

[00:01:53]
Don't judge me if I use a list or something like that a better element. But am using <div> because it's a code test and I'm limited on time. I just added the image, you can use the name doesn't really matter. I add the class list, I'm adding the item name of the class.

[00:02:06]
Don't know I'm gonna do with that I just did it just in case. And I'm returning that element that I created. So next thing I did was after I created this function was I created a document fragment. This is if you're giving a solid code test or answering a solved code test like this.

[00:02:23]
Create a document fragment cuz what that does is it creates a copy of an elements. And then I can just insert things into that fragment piece of document. And then once I'm done inserting, I append that to the actual dom. What's the advantage of using document fragments, instead of just appending straight into it?

[00:02:44]
Cuz I also could have done something like. In the forEach I could have said this.brute.append child. And then I could have called this. I hope that works. I could have done something like that. But why did I use a document fragment? Anybody, anybody at all?
>> You're appending a bunch of times.

[00:03:19]
>> Yeah.
>> And this one you're just appending once.
>> So what are the implications of that?
>> You're doing more stuff with the dom, when you're appending, so some sort of performances.
>> Yeah, that's exactly right. If we're appending, that means we're constantly updating DOM which means it's rerendering, between performances it's gonna be degraded.

[00:03:37]
Versus if I only append once, it's one render and then I'm done. That's something I look for. I want people to understand document fragments or just the performance implications of constantly rendering to the dom. Not a magic trick. It's just kind of good knowledge to have, in understanding like how does rendering work?.

[00:03:57]
And once I'm done, I append that child and I append that document fragment in so it's one render. Then once I was done, and just in case, I know there's some skeptics out there. This is my console log, I threw a lot of errors while I was doing this.

[00:04:11]
And I'm giving this course and I still write errors. I open my developer tools just to see what errors are getting thrown. This is real life, no one's perfect. So the last thing I did was I ran a little bit of trouble cuz I had to remember how event listeners worked.

[00:04:26]
But I added an event listener to the root and then I extracted the target. And the target is the thing that is being clicked on when you have an event listener or click event listener. And now, I said remove, which I have to look up as well, document remove element.

[00:04:40]
Just .remove, I should probably should have known that but I had to look it up too. But the reason why I added it to the root and not the actual child element itself, which I also could have done, was event delegation and this is what event delegation looks like.

[00:04:57]
It means there's one event listener rather than however many items I have here. And it's good to think in terms of that way, because let's say I had a list of 1,000 things. You'd see your performance slow dramatically down. And of course, when I click it removes everything from the list, one at a time.

[00:05:16]
That's an example of a code test. And I consider it a fairly reasonable code test for a general UI engineer. Now if I needed a, say angular engineer, I might ask a question in angular and have you solve that that way, or react or something like that. If I'm saying I want a UI engineer, don't really have specific framework in mind, I'll ask a question like this sure.

[00:05:39]
Because I don't necessarily want a language or framework or a library specific expert. Cuz what if we switch to, what's a new framework that just came out.
>> Svelte.
>> Yeah, let's say we switch to Svelte instead of React or something like that. Then all that React knowledge, it's worthless.

[00:05:57]
So I want a general UI engineer. If you understand something like this, then I know you can learn something else. But if you only spend your entire career coding one framework, you're probably not gonna be as flexible in your thinking, that's might not be what I'm looking for.

[00:06:10]
Nice job, all of you who completed it. If it was a little challenging, don't worry, it throws people because you get so used to all the heavy lifting that the libraries do for you that going back old school can throw you for a loop. But once you see it, hopefully you understand it's not too tricky.

[00:06:26]
And I didn't ask anything like create a web worker and start multi threading or anything like that. Just things you can look up. So that was a phone screen.

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