I think this perspective is overly simplistic. But then you might have meant it that way, so the rest of us can fill it in with our sundry biases. So, here's my chance to make my biases obvious. :-)

Hiring a programmer who has built stuff is like hiring a contractor who has shown an ability to do carpentry work. It's swell when all you need is the carpenter equivalent of a programmer; but often there is more involved than just nailing lines of code, classes and modules together from someone else's specification.

So, having a criterion of having built stuff is not sufficient, although I think it is reasonable. What qualifies as "stuff" is pretty subjective, though, and probably can't be anything but subjective. As I mentioned above: biases abound.

You also need to make sure they are able to figure out what to build and how, and sometimes what not to build -- whether that means they buy it, or it is a superfluous component.

You need to make sure they can think about what they are doing, rather than just being able to do things. The couple of outside projects I've become involved in so far, and some of the code I've read for other projects I'm not actively working on, suggest that some people don't do enough thinking. They've built plenty, but they didn't appear to build it with any goal but to build version 1 and be done. Think the software equivalent of a contractor coming in to fix what the first carpenter screwed up, because the first carpenter didn't care once the house passed inspection.

The code I've dealt with inside of organizations I've worked for is, if anything, worse than the code outside. But just looking at the end product wouldn't indicate anything is particularly wrong, excepting that maybe improvements to the site tend to occur only once every geologic era. Sometimes this can be indicative of quality of the developers; sometimes it is indicative of the quality of the management. Either way, it may not reflect on the developer you are talking to.

Depending, the developer may be able to think at many levels, and might be able to think lucidly about their work from a business strategy perspective. And depending on the organizational culture, this can either be a wonderful thing, or the most undesirable thing imaginable.

But this is all based on some amount of personal bias based on the kind of work I would want to be doing. I know there are places where programmers are expected to be nothing more than carpenters given specifications by the system analysts to turn into code. In these cases, I can see showing just an aptitude for building things to be enough. But I don't think these cases are common enough to warrant a single best practice.