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

The "Phone Screen Overview" 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 goes over the phone screen phase of the interviewing process from both the perspective of the interviewee and the interviewer, describes best practices, and gives a list of requirements that lead to a better screening process.


Transcript from the "Phone Screen Overview" Lesson

>> At the some point in the interview process, you're going to have to do probably a phone screen or a code test. A lot of companies that I've interviewed before do phone screens because it's a good chance to have an engineer talk to another engineer. So usually it's over video or it might just be over telephone.

But, really, it's a chance to kind of meet your first reach out on both sides. You meet the kind of person you're gonna be working with. You meet and you kind of understand what sort of questions do they ask. How do they word questions? How friendly are they?

Do they joke around a lot, and like kind of relax? Are they very, very stiff and vary by the book. And all these things will depend and it's a good chance for you as the candidates to get a feel for the company, it's a good chance as the interviewer to get a feel for the candidate.

Are they at ease when they code? Are they relaxed? But hopefully, you'll give them the option of the phone screen to code test. A lot of times, I prefer the phone screen, we get right to it. I don't spend any extra of my time doing code test. Phone screens generally, say 30 minutes to an hour, somewhere in there.

And they're done live coding. So, some people that get a little nervous, it's good to practice these things which we're gonna do in a little bit. But really kind of get the nerves out life code it's really helpful to kind of see how someone works through a problem when I'm giving a phone screen.

As the candidate for phone screen, when you're in the middle of it ask questions. I really want someone to ask me questions like hey, can I do this? Should I do this? Is this the right way? Not too many questions for it's like well now I'm just solving the problem for you.

But I want someone to ask me questions cuz that's how it is in real life. No one assigns your projects and like good luck see you in a month. No, you have the dialogue and that's what I want it with the coterie and that's what you should try to establish with the interviewer.

Are they helpful? Or are they dismissive. Are they friendly and outgoing, you're like, I understand, phone screens suck, interviews suck. And they're friendly, or there always like, this is a waste of my time, I can't believe I'm doing this. Why, doesn't this person understand what I'm talking about?

These are things you should vet out during the phone screen, so ask questions. Talk out your solution, especially if you get stuck. It does not help anybody. If you're sitting there thinking inside your head. You have to talk out loud in any interview. That's what you have to do you want to establish here's how I'm thinking about a problem.

And you might be absolutely right the interview say yeah, good thinking. Yeah, no, I think you're on the right path here or they might be like you're way off course. And the way you're thinking about the problem is completely wrong. And here's a better way to think about it.

But either way, you can't get there unless you talk out loud and talk about how you're thinking about the problem. And get comfortable in the environment. If using code pen or code tests, there's a lot of them. Ask ahead of time, they'll generally send you a link to the environment you're gonna be using.

They'll say it's a CodePen link, or something like that. Get comfortable, understand the debugging scenario there. Some environments, you can debug. Some environments, it's challenging to debug. But understand that, are you gonna be running the code live? Is it gonna output something, or is it just, they wanna see how you code?

That's not necessarily gonna be executable. As the interviewer for the phone screen, are you in a quiet area? Being in a quiet area is just respectful, they took an hour of the day as busy people to do this phone screen the least you can do is give them something quiet, not people find ping pong in the background.

I once had a terrible call and this wasn't the phone screen, this was recruiter, but I was like, I can barely hear you. It's like, my name's blah, blah, blah I'm with blah, blah, blah company. I'm like, I can't hear you. Sorry we're in a WeWork. I'm like, cool, we work with the glass walls.

But that's not my problem. Your job is to have this conversation with me, the least you could do is be respectful and be in a quiet area where I can hear you. That's not too unreasonable [LAUGH]. And the only thing to ask on their phone screen is, is the problem well worded?

Are they gonna spend 15 minutes or are you gonna spend 15 minutes of that an hour or 45 minute time explaining the problem to them? If so, that's probably not a good problem. They should be very clear and very concise about what they need to do, what they need to execute on, what you're looking for.

Ideally, two three minutes at most. It should be a very straightforward problem. Does the candidate know what the requirements and restrictions are? Did you say hey, you can't use jQuery, you can't use React, you can't use any libraries. It's just pure vanilla JavaScript. Or hey, you can import whatever you want, whatever gets the job done.

But does the candidate know that? Make sure they know when you're giving that interview or you're given a phone screen, what exactly you're looking for. And did you leave time for question at the end? You should always leave time for question at the end, always. Again, you're not even trying to establish.

Can they solve this problem? We're trying to understand how do they think? Are they capable of moving on to the outside world? We'll establish, can they solve these problems? What we're really trying to get to how they think about a problem, how they approach it, do they ask a lot of questions things like that.

But it's these dialogue, so the dialogue needs to go back the other way. Leaves time for questions at the end. Make sure it doesn't matter if you're like, we got 45 minutes and so we ran out of time. Again, it's about respect. It's about empathy. If I'm talking to someone I want to know, well, how long have you been at the company?

I want to know what the SEC is. What team are you on? Are you even the UI engineer, oftentimes they may not be you might get a generic general engineering question. You might get a front end question. It might be someone that it's their first time giving a phone screen.

All these things, but you wanna give time for questions at the end because again, it's about the dialogue between two people. Yes.
>> Is it good practice as a candidate to ask the interviewer what type of questions they're gonna ask?
>> Yes. And we'll talk about that for the on-site.

The phone screen, they may not tell you or they might tell you. I know it's not helpful at all. Some companies will say, hey, it's a frontend focus question so you're gonna be building something. Or they might say, it's a general CS problem, kind of a leaked code style general CS problem solving.

It doesn't what's the language. But that's a great question, asked what language can I code in? Some places, they're like our problem is in Python. I'm like cool, I don't do Python, I'm a JavaScript engineer. But that's a great question you should ask this ahead of time. And generally you gonna get two types of problems, they're gonna CS style general Leech ODZ medium around there or your gonna get specific UI problems like build carousel or something like that.

Which, 45 minutes, I think?

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