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

The "On-Site Preparation" 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 important preparation tips for both the interviewer and interviewee. For the interviewee, Jem covers practicing without a computer, and the importance of focusing on process versus individual solutions. For the interviewer Jem drives home the importance of empathy and what helps identify the best candidates for the job being hired for.


Transcript from the "On-Site Preparation" Lesson

>> Nice job. Congratulations, you're moving on to the next round. You're now on to the on-site. The on-site is, when people think about interviewing, they think on-site, they think whiteboarding, that's what they think of. Nobody thinks that the other steps. But like we said earlier, most people won't get to the on-site.

Even if you do, it's going to be a bit challenging and we're going to try to solve that today. But really, getting to the on-site is an achievement in itself. You should be proud of yourself if, even if you bomb completely. That's okay. At least you have the opportunity to interview with some really good engineers, hopefully that really good engineers.

And hopefully you take something away and you learn something from that. So if you made it this far, give yourself a round. Nice job. You made it to the outside. Now let's talk about the things you want to prepare for, for the onsite interview. practice writing code without a computer, on a piece of paper on a whiteboard.

If you have one, you have a fancy house or something I don't know. I don't have room in my tiny San Cisco partner for whiteboard. So I do things on piece of paper. And all the exercise we're going to do today during the on-site portion. I want you to do on a piece of paper because that's how you'll be doing it real life or whiteboard.

If you happen to have one your fancy, but do all these paper because generally there won't be any computers help you there's no linters. There's no internet to look up and honestly it slows you down. Writing a piece paper is more flexible because I can draw, I can cross stuff out and I can think a bit more flexibly.

And that's what you'd be doing things. I get whiteboard anxiety. I know someone standing there watching me, so it's better just to like practice solving problems and saying them out loud. Another tip is to go over general sample problems. Kind of like the ones I'm gonna give you or ones you can look up online.

Practice doing those without a computer and don't focus on the solutions, focus on how you got there. Cuz I promise you probably won't see the same questions over and over again. You'll see some, there's always be something you haven't seen. It's important to learn how to break down a problem and say What are they looking for in the specific problem?

How would I break that down, how would I explain that to somebody? Because at some point, you're gonna get stuck, you're gonna get stuck and you're gonna get freezed, and you don't know what to do next. And practicing helps alleviate some of that. Ask your friends to test you.

Do a video chat, call a stranger. There are actually companies out there that will Live interview you as practice. Take advantage of that. It is a different scenario. You're like, I aced this. I got all these questions right. I nailed them. Jem, he doesn't know he's talking. I'm way smarter than him.

I solved all these problems, no problem. And then you get up to the whiteboard and there's two people watching you and you're like, aah. How do I implement binary search? I know how to do this. I've done it before, but you just freeze up. So get someone else to test you.

It changes your perspective on things.And if they will ask what style of technical questions Is it going to be? Is it going to be Html, CSS, we're actually building something. Is it going to be high level component design like I'm designing a component that other engineers will use?

Are they going to be algorithmic questions? Usually, the interviewer will tell you and they'll tell you kind of what to expect, like some algorithms some of this or they'll be. They're all just relevent JavaScript problems that you're gonna solve. Try to get assessment ahead of time. If it's a lot of algorithms, study algorithms.

If it's a lot of JavaScript questions, make sure you know JavaScript foundations, things like that. Just try to like ask at a time. It'll help you get rid of some of the nervousness if you know what's coming. So, this is something you will do in your career. As an engineer.

You may not ever do a phone screen or have to create a code tests or even talk to a candidate on the phone. You will interview someone, if you haven't already. What I really want you to take away as the interviewer is empathy. Remember what it's like to interview and remember how much it sucks.

And try to be the person that gives the best possible interview as possible. Yes, that's possible with you. You figured it completely wrong, you want them to walk away saying, that was a good experience. I learned some things, clearly I have some learnings to do before I'm qualified to get this job.

But you want to walk away with that experience? Not that Jen was a jerk,he didn't help at all,he was typing on his computer all the time. He's I think he's on Twitter, making fun of me maybe, like, yeah, which I want to know. Like, you want them to have the best possible experience because interviewing sucks and we can do better.

It's just a We get there on the other side of the table and it's like we forget what it's like in all the hours of work. It's like to get to where this person is. And remember that you are one of seven or eight people, maybe even 10 or 20 that they're gonna talk to you in the day.

So don't try to stand out and remember interviews are not about showing how smart you are. You're trying to say is this person Good to work with. Do I understand the way they think? Do I agree with the way they solve problems? Is it a way that I think will fit in with this company?

The first thing to do is make sure they questions are relevent to the role. Are these questions that you've had to solve in a real life scenario? If so it's probably a good question. These are this is a problem you've had to solve before. But if it's an arbitrary algorithm problem that's fine if you want if you look for someone to memorize problems and solutions, but it's not gonna really tell me how they think it tells me they're good at memorizing algorithms.

I want questions that you've run into edge cases. How do I render a list with a million items, or something like that? How do I paginate something? Things that we've done as UI engineers. These are relevant to being a UI engineer. Have backup interviewers, again, empathy. They spend a long time and a lot of work, and a lot of stress and anxiety to get to the on-site If you're like, we're gonna reschedule because blah blah blahs out sick or react to pull someone at the last minute who was not prepared to give an interview their heads down a problem.

They're going to Google some like JavaScript interview questions real quick have backup interviewers. Let them know that their the backup or have ideally have two people do an interview. I always recommend to people. Doing an interview because one, it eliminates bias. Two I didn't like that guy. He's an Eagles fan.

I don't like Eagles fan. But developers say well, I thought they did pretty well. I think you have a little bit of bias. But generally try to have two people. If your company has the size of engineering to do that. It really helps get up more even A more even interview.

Book the room for the entire day. Again, you're stressed out the mechanics stressed out, they're sweating, they're nervous, they may have got the problem right they may have gotten wrong they don't know yet you won't know until finish. But having them move around and grab their backpack and all this stuff and shuffle around.

That's not helpful. Have them book the room for the day. Make sure you have plenty of time for breaks, bathroom, lunch, if they're there all day. Make sure they have drinks, snacks like anything they need to make them comfortable as comfortable as possible. Because again, interviewing sucks, but you can help make it better really easily just by being friendly and giving plenty of time.

But above all, remember, it is not about you is about the person on the other side of the room. There's an old saying that A player's hire A players, B players hire C players, C players hire D players and so on and so forth. Because known when we interview we often like this person smarter than me.

I am intimidated by that. As your ego gets in the way, and I say these things because i have been guilty of this and asked trivia questions. I have given poor interviews in the past, because my ego is in the way. No, you want to work with people that are smarter than you, because they'll make you smarter.

They are not going to make you look bad. That is what you are worried about, but they are going to make you smarter. Ideally, everybody's smarter than you and they help raise you up because you want to be the best interviewer you can. That's why you're taking this course, right?

So again, you can discard everything else I've said if you remember empathy. Just remember what it's like on the other side of that. And it's really hard to do especially when you've been with the company for a couple of years cuz you're like, I don't even remember what it's like to interview.

But if that's the case, go out and interview and remember what it's like, You will come back with a lot more empathy.

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