Interviews: Getting to know what you don’t know

Three years ago, I got into an interview into a company that was looking to hire a .NET developer for the first time. It was mainly a Java software house and, until that point, they have not had a requirement that called for a developer who mainly worked on the Microsoft stack.

Having had worked on .NET for a year and a half with both Windows forms and ASP.NET development up my sleeve, I was pretty confident that I knew enough to be able to get the job. That is, until the interviewer presented me with a problem that appeared pretty basic at the onset: write a function that would get the factorial of a given positive integer.

I wrote mine with an ordinary for loop. I was pretty sure it worked. Until the interviewer continued.

"Now rewrite that using recursion."

I froze. "What?"

"Use recursion." And right then and there I didn't know what to do. Now, some of you might think that recursion is so elementary that anybody with the amount of experience I had at the time would've known it, but obviously, I did not. I hadn't graduated with a Computer Science or Computer Engineering or Software Engineering degree: I was mainly a hobby developer until I took it seriously and tried my hand at the software development industry.

I was able to muddle through with most of it (thanks to Google for the most part) but until that day, I hadn't heard of what later appeared to me as a very basic software development concept. I was floored.

Fast forward to last week. This time I was trying out for a position with Microsoft itself; there were openings for their Shanghai and Copenhagen offices, and a hiring team from Redmond was sent to Manila. I easily passed the first two screening interviews, so I was pretty sure I'd make it to the last one.

In came the first interviewer with the first question: find if a given string is a palindrome, e.g., it's the same spelling whether spelled forwards or backwards. So I gave the following answer:

  2. public bool IsPalindrome(string s)
  3. {
  4. return String.Reverse(s) == s;
  5. }

Guess what: that answer is wrong. I tried to find out why, but my interviewer didn't care to expound and showed me the door.

Ironically, on the evening of that interview, Stack Overflow Podcast 23 came out and Joel Spolsky tells a story of how he was shocked to find out that using strlen() to find the length of a string degrades the algorithmic performance of a certain piece of code, when his code was reviewed by a senior developer. Turns out I had precisely the same problem: reversing the string adds to the complexity of my solution because it needed to traverse the whole string again. For a few thousand characters it would be perfectly fine, but for a string with millions or trillions of characters (e.g., a DNA sequence) it would've been very, very slow.

And I didn't know that considering that I've been on the industry for six years already.

Despite not getting the offer, I am nonetheless thankful for being able to experience a Microsoft interview. It merely affirms the lesson I learned back in the "recursion" interview: interviews are a great way to assess your abilities, and to find out what else you need to learn.

In a profession that thrives on learning new things, this information is quite invaluable.

About Jon Limjap

Jon Limjap has been programming since he was 12 and hasn't stopped yet. He was gone for a while in iOS and Java land, but is now back in .NET searching for unicorns and hunting down dragons.
This entry was posted in Industry Talk and tagged , , , . Bookmark the permalink.

15 Responses to Interviews: Getting to know what you don’t know

  1. Pingback: Becoming the un-OFW

  2. eric says:

    about the microsoft interview… don’t worry…. i know a friend of mine who used to worked for microsoft (redmond) before, with more than 10 yrs experienced and he tried for the same position you are applying for… guess what he’s not accepted… ang labo… to think that he’s the most qualified applicant in the philippines as mentioned to him by the interviewers… but he’s over qualifed… turns out that no one from the philippines is accepted… racist ba?

  3. LaTtEX says:


    OVERqualified? Ang labo naman nun! If they can’t find anyone from the post they would’ve been better off hiring the overqualified one (the fact that he already worked in Redmond should’ve given that clue).

    I dunno what the interviewers were looking for, really. I surmised they were looking for geniuses, but if they turned down a genius then there must be something else. Not sure if it’s racism, but I’d hate it if it is (and, knowing Indians, they do tend to favor their countrymen).

  4. miles says:

    In python:

    def factorial(number):
    if number == 1:
    return 1
    return factorial(number – 1)

    what did your loop solution look like?

  5. Vinko says:

    People seem to agree with your solution in general terms, seems like it must be a specific .NET idiosyncracy, have you found out something?

  6. Vinko says:

    Well, either that or the guy just didn’t like you and thus just dismissed you without explanation

  7. trashvin says:

    i am just curious , did you come out with a “better” solution that may be more acceptable to the guys in Redmond after the interview?

  8. LaTtEX says:


    Better check out the thread Vinko linked to in StackOverflow. Personally, I didn’t pursue finding out anymore.

    Sometimes, you just get satisfied that you know that you do not know. šŸ˜‰

  9. Jasper says:

    I know its been a while since this post was made and almost as long since the last comment was made, but I would like to share my thoughts and questions.

    Inefficient code isn’t wrong unless a good/the best/a certain speed was a requirement stated in the question, so to me it makes little sense that you were shown the door over that little issue.

    However, if I were your interviewer, I would most definitely show you the door if you showed me that exact code, as there is a major problem with it. A problem that makes your code plain wrong: string comparison.

    In Java, strings are objects, not primitives (magical objects, but objects nevertheless) and in Java, if you use “==” to compare two objects, you won’t actually compare the two objects, but you will compare the addresses of the objects. To actually understand that it helps to have some lower level language experience (eg C) and know how Java behaves in relation to it, but it is a fact that if you are learning Java and you come to the subject of strings, one of the first things you will be taught is that you should not compare string using “==”.

    The thing is, the code might appear to work. This is because of how Java works _internally_. To save memory, it might not make a new string if both strings contain the same contents, in which case the “==” will indeed give the expected result. However, it gives no promise as to such behavior, so it might just as well make a new string (if not now, perhaps in a future version of Java), so the function you gave might just as well return that the string is not a palindrome, even if it is.

    Simply said, the provided function _might_ work as you expect, but it doesn’t _have_ to, so it’s just plain wrong. No sense talking about the efficiency of your code if there is such a major flaw in it…

    If you the code you gave here does not match up with the code you gave your interviewer, this whole rant makes no sense at all, but it should just match up. Honestly, though, it makes a whole lot of sense to me if that error was the reason you were shown the door, seeing that an inefficiency would not exactly constitute much of a reason to be _that_ convinced you aren’t qualified for the job…

  10. Jon Limjap says:

    Hi Jasper,

    Thank you for that thoughtful comment. :)

    In C# strings are objects as well, but with a special caveat: its == operator is overloaded to perform a .Equals() comparison instead of an address comparison.

    This ensures that someString == someOtherString will compare string values.

  11. Jasper says:

    I know, that’s a true, my personal language of choice is C++ and as such I know the merits of operator overloading (and still don’t understand why Java doesn’t have it).

    However, the only language you mentioned was Java, so I assumed that was what you were working in. Now, I see that you also mentioned .NET, which still does not pin down a single language, but I also realise there is no Java.NET due to some law suits Microsoft lost even before .NET was cooked up.

  12. Wow this is a great resource.. Iā€™m enjoying it.. good article

  13. the senior menace says:

    Hi Jon,

    I’m surprised and glad to read about interviewing and recursions in your blog. My post-Cormant assignments seems to include, as a matter of necessity, interviewing developers I will work with. When it comes to interviewing developers, candidates can’t cheat an on the spot programming exercise, and write-a-recursive-factorial-function is one my favourite questions. Afterall, when you’re looking for a magician, you’d like to see their magic, so when looking for good developers, you’d want to see them code.

    Joel Spolsky wrote a very nice article “The Guerilla Guide to Interviewing” ( where he says that “all good programmers should be able to handle recursion and pointers (or references for the c# audience)”. This has nothing to do with idiosyncracy and neither it is about particular set of skills, it’s all about aptitude. It takes a good amount of aptitude to understand recursion and pointers, that is why they make for excellent interview questions.

    In any ways, if you’re interested, here’s my solution (in javascript)

    function factorial(n)
    return n<=1? 1: n * factorial(n-1);

  14. Warren says:

    fwiw (even if late to the party), I believe you were told it was “wrong” because (at least in English) palindromes have to ignore spaces, punctuation, and capitalization.

    Had you first stripped non-alphanumerics from the string, and either all-uppercased or all-lowercased it, then I bet you would have gotten a better response.

    There are likely better ways yet of doing it, but that’s a start :)

  15. Pingback: Palindrome detection efficiency | Questions

Comments are closed.