Are there any specific skills/Keywords you would look for to help differentiate them from a regular front end engineer/Prototyper for general POC engineering
Depends on if you are expecting them to also be the UX designer as well. There are a lot of UX designers that can prototype and there are a lot of software engineers that can prototype. The latter may be able to create much more complex prototypes, but will likely need guidance from a UX/UI designer as to what they should be building.
When do you feel its appropriate to ask for a code sample for review
For UX prototyping, that's not technically an issue, since it's merely a prototype to convey a particular UX rather than any sort of software engineering. Sometimes (often) speed will trump code quality. And often code used to prototype may have no relation to the code being used to develop the final product.
What questions would you ask during the first phone interview that would help cull out the "pure engineers" to find someone who understands what a Usability prototype is trying to accomplish that is different than a engineering/POC prototype
I'd simply be straight forward with them and point out that you are in need of a UX designer with prototyping skills. Most engineers that don't do UX will quickly say so.
Are there any items that you would feel are red flags?
Hard to say without knowing the broader context here. Prototyping in and of itself is useful, but I'm not aware of your bigger project plan and process.
ADDENDUM:
Some additional comments per the updated question:
looking for a prototyper with User Experience design skills rather than a Interaction Designer with prototyping skills
I think once you find someone with a bit of cross-training, it doesn't necessarily matter which world they initially came from. It sounds like the key aspect you are looking for is someone that knows a bit of code, and knows a bit of UX/UI. And that's a good thing, IMHO.
Prototyping is a specialty that doesn't need to be perfect code, as stated quick is better, but it also needs to be sustainable so it can be iterated on quickly
Yes and no, IMHO. We all strive for sustainability, but ultimately, prototyping is messy. At least with UI prototyping, I find you can go a few iterations, and then it's more often better to just toss and rebuild as after the 3rd or 4th iteration, you now have something entirely different than what you started with.
I consider prototyping as throw-away as wireframing. The idea is to communicate ideas quickly so you can get to the actual coding sooner than later.
Candidate should be able to defend their code decisions and why decision X made the prototype quicker and allow for iteration even though its not how you would do it in a production environment.
That's a good point. And maybe that's a good question to ask. "What coding decisions would you make at the prototype stage vs. production stage and why?"
HUGE CAVEAT:
I emphasize the 'throw-away-ishness' off prototype code because I truly feel that's what it should be in an ideal world. Prototypes are to communicate complex interactions and flows to both business owners and developers. It's a way to communicate across all the stakeholders.
And that's where its responsibility should end. At that point, dev needs to start slinging real production code, and all teams now need to focus on the real-code and the iterations there.
Alas, I know that's often not how it works in the real world. I've been on prototyping teams where we make it explicitly clear that CODE IS FOR DEMO ONLY, NOT PRODUCTION and yet 6 months later we look at the trash that comes back from the off shored code-mills and there's our prototype code, complete with comments "FOR PROTOTYPE ONLY". Sigh.
Even worse, I've heard stories of dev teams taking Axure generated code and trying to build something from it (shudder!)
But, in either case, that's not the responsibility of the prototyper, and would still value speed and creative thinking over pristine code frameworks at the prototyping stage.
ONE LAST THOUGHT:
Final thought: be sure you are looking for people in an appropriate salary range. I see craigslist posting looking for UX people that can do PHP and JS at $20 an hour and cringe to even think about the type of people they're going to get applying for a gig like that. While not universally true, you do get what you pay for and for someone with a bit of UX skills and a bit of coding skills, you likely need someone that has experience, so be sure to pay accordingly (I'm in no way trying to imply that Chris is right or wrong about this aspect, merely pointing out that there still seems to be a lot of companies out there who don't realize what it takes to get good skill sets to apply)