re: Coding challenges in interviews VIEW POST

re: We did take-home tests for awhile at my last company. We found that when the market is strong, experienced developers don't want to spend time on t...

Thanks for your insight, Drew! There's a lot of value in testing communication skills with a pairing exercise.

I'm curious about why candidates would prefer pair-programming over a take-home test if lack of time is their main issue. It sounds easier to spend a couple hours working on some code over the weekend instead going in for an on-site interview.


Our entire process (minus commute) was less than four hours.

Personally, I feel like taking something home is a chore, whereas collaborating during an interview feels engaging and gives me a glance at the company’s culture. As they say, an interview is a two way street.

If you can optimize your entire interview process to be respectful of a candidate’s time, you will get more great candidates to say yes.

We solved this with:

  • one remote tech screen (30 mins)
  • on-site culture convo (30 mins)
  • on-site pair-programming (45 mins)
  • on-site whiteboard session (45 mins)
  • on-site debrief with hiring manager (30 mins)

All of the on-sites happened on the same day. Through the process, you met two random employees, four developers, and the hiring manager.

This helped us get to the offer stage ASAP and let the candidates interview the company throughout the process.

That sounds very efficient, thanks for sharing!

code of conduct - report abuse