Technical interviews

I started to enjoy technical interviews, but I agree with many of my peers when they say they’re exhausting. It happened to me more than once to screw up an interview because I was tired and when I tried to schedule more than one interview in the same day I always underachieved in one of them.

I like them because I feel clever when I succeed at hard interviews, but it’s also a waste of time because the process is always almost the same. That’s why I think using some sort of standard score would be helpful. In fact an ideal solution would be to use using university exams scores to hire the most promising programmers, but it would imply an overly biased choice.

Technical interviews process is rewarding when you’re able to solve problems and quizzes. When and if you get an offer it feels like you’re going to be part of a group of people who can solve those same problems at least as good as you did.

That’s also the reason why I feel dumb when I fail, but that’s part of the game, and what I end up saying is that that’s probably why I still don’t build rockets at NASA.

The thing that I completely disagree with is the whole A, B, and C players thing. They say: As hire As and Bs hire Cs. Well I think that’s not totally correct because if your interview process includes problem solving you’ll end up with results that are precisely measurable and you can just adjust the complexity of the problem to get As, Bs, or Cs.

Next: A terminal music player based on afplay written in Haskell