I’ve always wanted to test how well that would work for software interviews:
- print some pages with the source file of a toy project
- give the interviewee a pen and just ask “tell me all you can about this code”
I’ve always wanted to test how well that would work for software interviews:
- print some pages with the source file of a toy project
- give the interviewee a pen and just ask “tell me all you can about this code”
I got the job and later confirmed it was a class that was actually in the software I would be working on, not some toy class he came up with.
He also asked me a handful of technical questions and had me go over some source code I brought in, but that was about it. At one point he even said, "I know enough to know you can do the job, but now I'm curious what you really know." And asked me some no pressure really low level questions. When I said I didn't know the answer to something he'd spend a couple of minutes explaining the concept to me.
I walked out of that interview having learned a few new things about my field. A couple of them have stuck with me over a decade later.
And the guy was a grizzled veteran who was the lead on some massive mainstream projects I pretty much guarantee you've heard of. He's probably the most knowledgeable programmer I've ever met.
I've never had anyone try going over actual with me since, in probably a couple dozen interviews, and I don't understand why. It seemed very effective.
Apparently three quarters of previous applicants hadn't even managed that, so it was a great filter for non coders.
Just make sure the code is linted and idiomatic unless you want the poor interviewee to be bogged down by a bunch of irrelevant details.
I'd caution against a toy project however. Just find something small and contained. Toy projects typically don't have enough warts to lead to a really interesting conversation.