"Why not just bypass the bullshit challenges and just _have a conversation about code_?" Because talking and doing can be different? _Do_ they actually write test cases? Do they write documentation? Do they make output machine parseable? etc. I want to see what work product looks like even if the work product is simple. (which is also why the homework I assign is nothing ridiculous like 8 hours nor do I timebox it)
Talk about that stuff. People sometimes spend extra time polishing a code challenge than they do in their day-to-day. People can lie to you in code just like they can in conversation.
Sure, you know that their ability to do it is there, but you still don't know that they will and you still don't know that if they didn't they could learn. You can get that information from having the right conversation.
What testing tools do you use? What's your approach to testing? What pitfalls have you run into with testing?
What projects have the best and worst documentation that you've used. How does this affect the work you do? How do you make your code usable to others?
What's your opinion about input and output of functions? Separation of concerns, etc?
Or the best question of all: What books about programming have you read and liked and why?
You can't stare at somebody's code and know if you'll like working with them. More importantly, weedout challenges are a solution for the wrong problem. If you're worried about wasting your time bringing in the wrong people to interview, maybe focus on getting better indicators on the kinds of people that you (want to) bring in.
"People sometimes spend extra time polishing a code challenge than they do in their day-to-day. "
Maybe thats because they are under resourced in their day to day, and don't get a chance to do things nicely despite complaining to management about it constantly.
A lot of people have the "get it done so I can get out the door" mentality and cut corners which they obviously wouldn't/shouldn't do during their interview process.
Though them not doing it and spending the energy to "complain to management constantly" might be a problem too. I'm sure we're all familiar with terrible management practices, but some people are complainers and some people are pushovers and you don't want either (or at least you don't want to bias your team towards one or the other).
Being able to calmly explain a process problem and demonstrate why is a critical skill. If you're in a company where that's a waste of time, don't complain, just leave. If you can't fix or guide people, your code still won't get shit done.
I think a lot of people, ourselves included, think that we're in the business of writing code, but this is actually a mistake. We're doing business Operations, yes, with the capital-O. The only difference is that our tools to get the job done are "our software, our people and other people's software" instead of just "our people and other peoples' software".
Developer is the right title for us most of the time.
"You can't stare at somebody's code and know if you'll like working with them." Sure...and there's not mutual exclusion between the two. Looking at someone's work product is simply another set of data points. I'm not judging someone's fit for a position simply based on a code work product. Or a resume. Or one cultural fit question. I'm using them all to paint a picture and weighing the pieces to determine if I think this person will perform well under the complete circumstances (work/life balance, work required, what team they're on, etc.) Simply put, I've found several different kinds of work products have helped determine positive fit in the past for me.
