I admit I have a love/hate relationship with the first calls in an interview.

They’re intense.
The sheer amount of them makes them extremely exhausting.
They’re also super fun.
And they matter a lot.
And because they matter, I think we should try to do them well.

I’ve just been through a hiring week for a React Frontend developer and got positive and constructive feedback about those calls, so I figured I might share how I do them and why I do them that way. I’ll also share some feedback I got from applicants and how I will change those first calls because of it.

I hope it helps you make your initial screening even better, or at least you can avoid my mistakes.

 

Why the first call matters (and why it should be fun every time!)

The screening calls are inefficient by nature: unless you’ve some magic crystal ball, you’re going to talk to a lot of people and almost all of them will not be hired. And because there are so many, you might feel a bit like a quality assurance worker on a production line, inspecting every tenth item. Whenever you feel that way, it’s good to remember two things.

First, among all those people is your future colleague. On any given call you might be talking to that person. And this is your only chance to leave a good first impression. (The impression starts earlier, but that is for another time.)

So on those calls your job isn’t just to “weed out the chaff”! In fact, your most important job is to excite your future colleagues so they stick around for the interview and are eager to come on board.

How do you do this? Simply by giving them a taste how it feels working with you.

So … how does it feel working with you?

Is it this?

You’re already the fifth person I’m talking to today
and by the way there will be two more after you
and chances are you’re not going to make it anyway.

Maybe that’s how you feel (and I get exhausted, too!) but it’s definitely not how you want them to remember you. Here is the kind of energy that I want to get across:

I’m having a good day because I’m meeting you and I suspect you are an amazing person. And by the way, you might also be a better developer than me and I appreciate that you take the time to talk to me.

Maybe you’ve a different idea of what energy to project. That’s fine. But you’ve got to project positive energy in some way because you want to hire the best person for the job. And the best person doesn’t need to work with a bored, exhausted colleague.

They deserve better and they will find better.

At some point it becomes a question of endurance: How can you keep up a positive attitude? That’s the second point to remember:

You’ll be talking to a lot of really interesting people.

That is one of the fun things about remote people in general: they come from everywhere! So chances are pretty good that you’ll meet people you’d never meet otherwise. From cultures you have never encountered, parts of the Earth you will never set foot on.

On this round of interviews for example, I talked to a Jain, heard from life in Lagos and learned that growing up in St. Vincent and the Grenadines—which apparently I should visit some day—makes for a happy childhood. And that was just me doing my job. How amazing is that?

Think about it this way: you’re globe trotting at high speed. You should be able to make that fun, right?

For me then the trick is to remember this in every call (I get to talk to interesting people!) and to channel that energy to make this a fun call for both of us.

But no matter how you do it: you gotta make the first call count, every time.

How the calls look like at the moment

For each call, I reserve a full hour. How long they last depends: We might conclude things after 20 minutes or run into overtime.

If it becomes clear quickly that this isn’t going anywhere, I try to not waste both our times. If it looks like we find common ground, then the call usually goes on a while, as we dig into details.

So, how does the agenda look like? I never outlined it in this detail, but here’s how I end up doing it:

1. We laugh together
2. I explain the purpose and rough idea of the call.
3. Do you have any questions?
4. My opening question: What do you want?
5. We alternate questions
6. I ask my introspection question
7. Feedback

I’ll shortly explain each part and what its purpose is.

We laugh together

That’s right, we laugh. In the first minute or two, I’ll make every effort to get a good laugh out of my conversation partner. How I do that depends on the mood of the person I’m talking to. If she’s extremely nervous, I can be quite silly. If he’s quite reserved, I reach for the dry self.

The purpose of course is to help the applicant loosen up and overcome some of the nervousness they often hold. Nothing relaxes someone super nervous more than a touch of silliness from my side. And nervousness doesn’t help either of us.

The other purpose is setting the stage.

I’m trying to leave an impression of cooperation, mutual interest, experimentation and fun, as opposed to confrontation or self-interest. Laughing together is, I think, a good start on that journey.

I explain the purpose and rough idea of the call

No magic here. If you’re on an interview, you are probably a bit anxious because you don’t know what to expect—even if a previous mail outlined the call. So I try to clear things up early.

Do you have any questions?

I give them the opportunity to ask questions, to clarify the process, or initiate a conversation. I wait, so that it’s clear that it’s not just a fake courtesy.

With this I’m simply trying to reinforce the idea that this won’t be a monologue by them about their CV.

 

My opening question: What do you want?

I ask what they want. From this job, or any job. How would their ideal job look like, in terms of team, tech, processes, setup, company goals, anything.

My intention is to understand early what they’re after. Part of what makes remote interviews of devs fun is the diversity of people you encounter (even though by and large they’re male—would love to drive a change there). And everyone has different ideas how a job should look like.

Simple example: One applicant told me they expect to know exactly what they’ll work on for the next three months. Well. That was good to know! Saved us both some time. (While we work with quarterly OKRs, in our tiny dev team it’d be straight out lying to promise that nothing will change in three months.)

At this point, 10 to 15 minutes have gone by. If there is a mismatch that’s clear to both of us, I’ll end the call.

We alternate questions

I explain that I’d like to alternate questions, to make it more of a conversation.
And then we talk, and I make sure the tables turn after each question.

For me, interviews have always been a two-way street no matter at which end of the table I sit. We both need to figure out if we can team up for a common goal.
So on the one hand it’s just a matter of fairness to make sure we get an equal amount of question time.

On the other hand, since I’m interviewing for a remote job, I desperately need to know if this applicant will ask questions. It’s so important that I wrote a separate article just about the need to ask questions, but the gist is: A remote dev will not make it without being intentional and without a desire to understand.

What are questions I ask? Here are usual topics:

• Why did you quit your last job (or why do you want to)? Helps me understand what they want from a job.
• Things that stand out in their CV like strong opinions, weird formulations or proudness
• What were growing pains of a project that you encountered? engageSPARK is a product company, so maintaining software matters.

We’re now 30-40 minutes into the call. I’ll cut this short if I see red flags.

I ask my introspection question

As the semi-list piece, I ask one of these weird introspection questions.
I’ll need a separate article on that, but there are long lists of such questions when you search. Pick one that you can ask well.

Why do I ask this? Definitely not for some deep psychological reason. It’s not much of a filter either: Very few people can’t comprehend the question and basically every answer is an answer.

So, why?

It gives me an impression from a different angle. I’m never quite sure what I’ll get when I ask. Some people surprise me with self-irony I didn’t sense before. Others help me understand what they need to have a productive day. The answers are all over the place, but they tell me something every time.

What’s next

I explain the next steps of the process so they know what to expect.

Feedback

As the last point from my side, I ask for feedback about this call and the process so far.

My intention is of course to improve our interviewing process and learn how I can make those calls better. Often I get nothing, and that is fair. Most applicants feel quite pressured to be pleasant.

But when I do get feedback, it tells me a lot. I learn how to make things better,
but I also learn how the applicant gives feedback and that they will. That matters because I need people who give me and others feedback more than I need everyone to be pleasant.

So what feedback did I get?

There was the simple kind:

• Your chair makes noise. (I didn’t realize. Moved less after.)
• There was a lot of background noise. (That’s fair. On that particular call I couldn’t get a call booth.)
• You twirl your hair. (I do. A habit I picked up. Hard to change.)

Then there was the positive kind:

• I liked that we changed who asks the question. (I also got that from someone who had a hard time coming up with questions in the first place.)
• I’m usually very nervous but you made me feel relaxed. (Glad to hear! Can’t seriously talk with someone who is stressed out.)

And the helpful, overarching kind:

• I was confused by the interview process. (From people that made it further.)
• I expected to look at code in the first call, not later.

The first point is easy to address (working on it already).

The second point I got multiple times, and I see the advantages of doing that.
But as the time management recommendation goes:

Whenever you say that you’ll do more of something,
you also have to say what you’ll do less of.

The calls are already long enough, and I will not extend them—because then I would invest too much time up front. I might do less questions, but every part has its purpose and I think has served us well.

But, then we like experimenting, so we can fail and learn. Next time we hire developers, I might just look at some code in the first call. Already curious how that will go.

Hope that helped you make your calls more worthwhle, more enjoyable. Let me know how you do them, and what you’re experimenting with!