A) Give them a &quot;take away&quot; project... or bring them into the office to DO a project. Make it simple. Have them write &quot;login&quot;. Don&#x27;t be specific, tell them the exercise meant to be vague. Tell them that there are some things they may want to &quot;hint at&quot; or be a skeleton. If they are back end, you want just the api... front end just the UI (they can create static json for responses). Do they encrypt, did they leave hooks in for password reset, were they writing code that was going to be hard to I18N?<p>The white board is a terrible way to get a sense of a persons ability to code. Does your design team ask candidates to come in and &quot;design&quot; on the whiteboard? Why would you pull an engineer that far out of context to see what they do.<p>I have seen interviewers bring in &quot;code samples&quot;, sometimes with bugs in them. &quot;Read this and tell me what you think it does&quot; becomes a great question, or what is this for. Syntax highlighted code printed in color may speed this exercise along but isn&#x27;t required.<p>References help, but really your calling someone they expect to give them a golden review. Linked in is your friend here, some &quot;outreach&quot; may get you a different perspective than the people they have listed.<p>B)Short of someone being lazy, or unwilling to learn, there is more than a bit of bullshit in &quot;corporate culture&quot;. There have been several occasions in my career where I heard that my immediate boss didn&#x27;t want to hire me as I would be a &quot;bad culture fit&quot;, usually followed by a promotion. Culture is code for &quot;status quo&quot;.<p>Lastly: Talk to your HR department about terminating bad employees after 90 days. No matter what you do, sometimes you just get it wrong, and getting that person out is better than dragging it out.<p>EDIT: I should have mentioned that rather than focus on &quot;culture&quot; you should be finding out if the person cares about your product.