Technical interview performance is kind of arbitrary
With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do &#x2F; desire to learn. This is a learn everyday field and if you&#x27;re interested in what you&#x27;re doing, you&#x27;re going to do a lot better at it. It&#x27;s hard to apply yourself mentally to something that you don&#x27;t have a good level of interest in. Given that it&#x27;s a learn everyday field, people with that level of interest will realistically be able to learn anything they need to do solve the problem you&#x27;re hiring them to solve.<p>The only real differentiating factor is your tolerance for ramp up time. I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. If I&#x27;m hiring full time, that&#x27;s something I&#x27;ll tolerate. If I&#x27;m hiring a contractor, I&#x27;m going to be uneasy about paying high hourly rates for him to learn the job.<p>The single most effective way that I&#x27;ve found to interview for &quot;interest&quot; is to just get them talking about something they&#x27;ve done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride. Doesn&#x27;t really matter what the problem was, if it was a business problem, code problem or hardware problem. The important thing is the level of attention to detail in addressing it.<p>I&#x27;ve been using this technique for about 8 years now and while I don&#x27;t make it the exclusive criteria for hiring, every person I&#x27;ve ever hired who has passed that part has ended up in my &quot;great hire&quot; category.