DEV Community

Tris Revill for Doctolib Engineering

Posted on

Remote Interviewing Tips for Developers

I have been interviewing developers and engineers for years. Either for onsite positions or remote ones. Over the years I have realised that not many people share developer-specific tips for interviewing remote. This isn't about passing the interview technically speaking, but about how you can develop the "interviewing" skills that are going to help you ace your interview.

Remote interviews can give you a huge advantage, you are in your own environment. If you are well prepared you will ace it.

Preparation and practice is key.

Stay cool, Keep smiling, Keep your energy high. Video kills energy so look into the camera and talk to your interviewer.

After a few goes's this will help you!

TURN OFF ALL YOUR NOTIFICATIONS

Seriously, everyone can tell when you stop paying attention in an interview because you just got a notification about a new awesome post on Dev.to ;)

Even though you are probably at home in front of your computer, remove as many distractions you possibly can.

COMMUNICATING CLEARLY IS KEY

Get your camera in line with your eyes.

Make sure people can see your face, avoid backlighting.

Get a headset.

Make sure you sound good.

Look into the camera.

Respond to the interviewer by looking at them.

PRACTICE WHITEBOARD & PAIR CODING INTERVIEWS

Pair coding and whiteboard interviews are both pretty standard for most dev jobs these days. You are still probably going to have to do one during your full remote interview process.

The technology has got way better since I started doing this 8 years ago. There are many cool collaborative pair coding and whiteboarding tools. But let us be honest, they are all a bit of a nightmare the first time you use one!

Practice makes perfect.

This is going to make you look like a pro in the interview.

I hope this helps and if you want to know more...

YOU CAN FIND ALL MY REMOTE INTERVIEWING TIPS OVER ON MY

What are your top tips for interviewing?

Top comments (1)

Collapse
 
fwuensche profile image
Flavio Wuensche • Edited

Nice! There's an article about Optimizing for Usefulness that I really like and one of the examples it uses fits perfectly to your question:

Another useful heuristic that I’ve learned is the idea that debugging activity is indicative of broader programming ability. Or, to put this more accurately: a programmer with good debugging skills might not be a great programmer, but a programmer with bad debugging skills can never be a good one. It took a while to come to this realization, but then all sorts of useful implications presented themselves. One useful implication is that in order to become a better programmer, it pays to work on your debugging skills. But a more useful implication would be that we could use this insight for hiring.

As a result of this idea, we reconfigured our screening tests at my previous company and gave all candidates a buggy program to debug as a first test. If the candidate had real trouble debugging, we cut the interview short. It made our hiring a lot more efficient overall.