←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 1 comments | | HN request time: 0.212s | source
Show context
bargainbot3k ◴[] No.42148454[source]
I’ll act as a counter-balance on this topic. I have conducted hundreds of technical interviews across varying levels of experience - from interns and juniors all the way to PhD grads and those with lots of years under their belt. I have extensive hands-on experience in multiple fields and passable knowledge in others. If a candidate has worked on something in the past, a good position for me to be in is to know more about what they’ve done than they do. A passable position is one where they can walk me through what they’ve done and I pick up as I go along, piecing it together in my head with what I already know. I very rarely have pre-canned questions, instead I opt to come up with examples on the fly based on how the conversation (and it is a conversation) is unfolding. If the candidate is gold, I will usually have a first offer prepared for the candidate before the interview is over, and I do not cheap out on the offers. Candidates have historically reached out to express they enjoyed the interview even if an offer was not presented. I believe in respecting the candidate, respecting that people can be nervous and shy one day and social the next, that people interview differently, and that more interview rounds does not necessarily yield a better result. Prerequisite for this is you have to enjoy talking to people, put your bullshit ego aside, show your hand where you think it will help the candidate, and know what you’re talking about and what you don’t know. People can learn, people can adapt. Every so often, I accept candidates that would otherwise be rejected on the understanding that no “system” is ever perfect, certainly not one that involves people. It saddens me to see coding challenge, especially automated ones, because it shows laziness on part of the interviewer. However, it is a skill that must be attained and practiced like any other. And no, I haven’t used the return key since the 8th grade. AMA.
replies(2): >>42148485 #>>42150127 #
1. sfink ◴[] No.42150127[source]
Agreed.

I can't claim to be always be good at it, but this is what I strive for as well. I like talking to a candidate about something they are experienced or even expert at, and asking questions until I find the boundary of their ability. It can be very illuminating what happens when they hit it -- some get defensive, some get enthusiastic.

Defensiveness might just mean they're being interviewed and I failed to adequately put them at ease. But usually when we're neck-deep in some specific topic, both of us will kind of forget that it's an interview -- especially since the topic is more in their area of strength than mine.

Otherwise, defensiveness often means they never actually wanted to understand the problem they were working on, they just wanted to use it to get a degree or ship something by throwing it over the wall and forgetting about it. Even someone who is heartily sick of their PhD topic (as in, everyone who is over 1/3 of the way to getting one) will be relieved to discuss the ideas behind it, the reasons why it caught their interest in the first place, when they don't have to do the work of coming up with rigid results and writing them up.

Enthusiasm is usually a good sign, though even there I have to watch out for excessive enthusiasm where they care more about the problem itself than the benefits of solving the problem, and are likely to waste resources in unnecessary pursuits of perfection.

Oh, and finding the limits of someone's knowledge doesn't require a genius, which is fortunate since I am decidedly not one. 3-year olds can do it just by endlessly asking "why?" You'll probably need to be a little more sophisticated than that, which is good since you'll be able to evaluate their ability to explain things to you in the process.

I do like the return key, though.