The "Technical" part was just trivia. Never-mind that I was sat in front of a computer and could have googled everything asked, I chose not to do that.

So yes, I stumbled when asked "what does the using keyword do". I explained how it relates to IDisposable, disposeing the object at the end of the block scope and avoids needing try/finally blocks.

But clearly that wasn't the script, because they kept asking "Are you sure it doesn't do anything else? Are you sure isn't used anywhere else?".

Eventually I realised they were talking about "using System.Linq" etc, and all they wanted to hear was the word "namespaces".

Talk about interviewing by numbers, had I wanted to I could have googled every question and given them perfect descriptions.

What could they possibly have learned from that interaction? I learned I didn't want to work there, so it helped me I guess.

But I find implementation things more helpful (in person, not by phone!), because it's not about whipping out the right answer, it's about watching how the candidate thinks and approaches problems. It's about how they work not the end result.

I like the "write a function to multiply" because it can be extended to any level. If someone aces the positive numbers case you point out negative numbers, if they ace that you can talk about efficiency, or bounds checks, exception handling, efficiency or whatever else you think they'd like to talk about.