Why? Seems like a straightforward thing to bring up during an interview.
Newsflash: people lie in interviews.
Of course they do. But that's why you ask them to describe some of the things they've done, in detail, and ask probing questions about why they did it, how they did certain things, and problems they had. If they can't, then maybe they're lying. If they can, then either they're telling the truth, or they're exceptional liars.
If their spare-time coding also includes contributions to open source, take notes: it should be pretty easy to check up on after the interview since those kinds of things are usually pretty public.
Unless you are a complete moron it does not matter how bad you are at writing code, what matters is how willing you are to learn to improve.
If that were the case, experience wouldn't mean squat during a software engineering interview. I've done a few interviews as the interviewer, and I wouldn't even consider an applicant who codes poorly, especially when there are so many people who are already more than competent. If they are just lacking experience, that's fine, if the position isn't too advanced. But if they're actually bad coders... no, sorry, but they're just going to be a burden. It's pretty tough to judge a person's ability to improve in a 45-60 minute interview.
Just give them a basic coding aptitude test in their specialist language (on paper, no IDE) and see how they do.
While that's certainly applicable for some jobs, many employers may not find that so useful. I wouldn't say I've interviewed for tons of coding jobs, but I've never had anything approaching a "basic coding aptitude test." The interview questions were usually coding-related, and yes, I've written code on whiteboards during interviews, but most of them are more about critical thinking and problem solving than basic coding ability.