The one gap in technical interviews!

I've been doing interviews at Microsoft for over 15 years now. When I looked at the system that tracks all the interviews that I'd participated in, I counted at least 500. First, let me make something clear: interviewing a ton of candidates does not make you into a great candidate yourself. If you look at my own performance as a candidate, looks pretty average: 6 attempts, 3 hires, 3 no-hires. I guess I'm one of those who feel way more comfortable on one side of the table than the other.
I believe that in a good interview process, not only the candidate is learning along the way, but so is the interviewer. I love open discussions with candidates about technical problems, and it is very rewarding to me to discuss different technical ideas with folks who bring to the table different perspectives.
Some other day I read an article that gave me an instant epiphany with regard to something so obvious that I have ignored in all those years interviewing candidates. As you may know, most of the technical interviews is about asking the candidate to write: either a code, algorithm, design, etc. Which I must say is unquestionably important.
However, when you join a massive company like Facebook or Amazon or Microsoft, in the beginning you won't spend the majority of your time writing code - what you'll actually do is read code. No one will ask you to write a mergesort, or a trie class, or design the classes from the get-go. 80% of your time will be spent reading code. That was an eye-opening to me - so obvious and yet, most of the interviewers out there (like I was) are obsessed with writing skills, but not reading.
Recently I started applying this technique, and it was great, felt really much more pragmatic than before - and indeed, reading, understanding and modifying somebody else's code requires a different set of abilities, great abstraction skills, and (above all), focus. And patience :)
Even like simple reading questions can lead to very interesting, deep technical conversations, ones that are much more likely to happen in real life. I recently asked a candidate to read, comprehend, and propose extensions and improvements to the code down below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace CodeReadingInterview {
 class Program {
  static void Main(string[] args) {
   string[] array1 = {
    "interview", "coding", "computer science", "carnegie", "mellon", "microsoft"
   };
   string[] array2 = {
    "questions", "interview", "science", "redmond", "weather", "microsoft"
   };
   string[] array3 = {
    "interview", "microsoft", "bing", "arts", "internet", "computers"
   };
   int n = 6;
   for (int i = 0; i < n; i++) {
    for (int j = 0; j < n; j++) {
     if (array1[i] == array2[j]) {
      for (int z = 0; z < n; z++) {
       if (array1[i] == array3[z]) {
        Console.WriteLine(array1[i]);
       }
      }
     }
    }
   }
  }
 }
} 

What does this code do? What's its time complexity? Can it be reduced to O(nlogn)? Can it be reduced to O(n)? What did you like about this code? What didn't you like? What would have made the comprehension process easier/faster? What suggestions would you make to it? Did you find any bugs? How would you fix these bugs? And so on so forth.

Moral of the story: if you're interviewing a candidate, sure: continue to ask writing questions, but also balance the interview loop out with code-reading questions too.

Happy Thanksgiving Everyone!!!

Marcelo