For dev/tech hiring, the answer is straightforward: deprecate person-to-person interviews in favor of work-sample testing. Take a simple project your team has built, carefully carve out some functionality from it, document it, and then have your candidates implement that functionality. The sample should be runnable in its incomplete state and should be accompanied by some record of what good output is.
Evaluate candidates on code that they write for your hiring process (not on what they've posted on Github).
Additional tips:
* Pre-interview every candidate with someone clueful whose job is to (a) sell the company to the candidate and (b) to over-answer questions about the interview process. A surprising amount of interview jitters come from candidates not having visibility into the process.
* Try to eliminate phone interviews entirely. They don't add value, but do amplify noise. Companies routinely evict candidates from the pipeline based on assessments of "confidence" or "passion" or "comfort" from phone interviews. Don't work for companies that do that.
* Never interview a candidate with more than one interviewer. Interviews are incredibly hostile experiences in the best of circumstances. Ganging up on candidates ensures that you can't possibly be in the best circumstance.
* Have lunch with candidates if you like, but don't make lunch a Q&A with the candidate. Train your team not to treat it that way. Be clear with the candidate when the metaphorical "red indicator light" goes on to say that they're being assessed, and when the light goes off so they can regroup. Assume even the most clueful and experienced candidate will need routine opportunities to regroup.
* Do not allow team members to contribute feedback based on "culture fit". Set aside that "culture fit" is often as not a fig leaf for a variety of discriminatory practices: it's also bad engineering. "Culture fit" allows any engineer to discard all the data you painstakingly collect on a candidate based solely on non-falsifiable gut-feeling assertions.
* Script your interviews. Your engineers will hate hate hate hate hate you for doing this (trust me, even if they start off thinking it's a good idea, they'll stop thinking that after they've done two of them), but you'll start generating actual data based on your candidates so you can make apples-apples comparisons and optimize your interviews instead of just occasionally changing the color of the rubber chicken you're waving around at candidates. Scripted interviews are also a forcing function for the development of objective standards for hiring, which will keep your team honest.
When I was at Matasano, we got minimal value out of campus interviewing, but a lot of value out of Internet outreach.
Things that make well-engineered interview processes tend to have a side effect of minimizing bias. The reason is that subconscious biases are already the biggest source of noise in your screening process anyways, so improving your screening will tend to require you to minimize bias.