Showing posts from November, 2014

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 kno

Inception-Like Programming

When the moving Inception  came out in 2010, everyone thought that it would become the next Matrix sensation. It did not. However, the plot was interesting. In essence, folks in a dream (level 1) have a dream (level 2) where they have a dream (level 3) where they have a dream (level 4) where some action happens. 4-levels of dreaming. Now a dream by itself is already a very abstract entity, hard to grasp the concept most of the time. Never mind 4 levels of dreaming. It just so happens that a programming problem that I stumbled upon requires kind of the same paradigm of abstraction in order to solve it. Here is the problem gave to me by a friend at Microsoft: In the game 24 , you get four numbers and try to use +,-,x,÷ and () to make an equation using all four that equals 24. For example, if I gave you 4, 4, 6, 9, you might write: (4 + 4) x (9 - 6) = 24. One nifty thing about 24 is that it is actually the product of the run of the first four positive integers: 1 x 2 x 3 x 4 = 24.

2^(3^(4^(5^(6^(7^(8^9)))))) - Part III

The trilogy comes to an end! The solution to the problem has been posted on the IBM ponder this page . If you use the hint from the previous post, you'll notice that all you have to do is keep getting the last ~12 digits of the results of the exponentiation (basically one of two more than 10), and keep using those digits to raise the inner numbers, repeating the process all the way from 9 to 2. The ModPow function is your friend here. Code: using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Numerics; namespace IBMPonderThisOctober2014 {     class Program     {         static void Main(string[] args)         {             BigInteger result = 1;             for (int i = 9; i >= 2; i--)             {                 result = BigInteger.ModPow(i, result, 1000000000000);                 Console.WriteLine("{0} => ...{1}", i, result);             }             Console.WriteLine("\nSolution: {0}", result % 10000