Seldomly Asked IT Interview Questions

I've done my share of interviewing in my previous job, and one thing that I really hate is that nowadays, there's not much that you can ask without the answer to the question being plastered all over the internet. Sure, there's merit in being able to answer a textbook question with a textbook answer, but as experience tells me, that's never any guarantee of skill, so it kinda defeats the point.

After leaving my old company, I realize that I won't be doing any interviews anytime soon, so I figure I might as well share some of the standard questions that I have developed for my own interviews:


1. Define overloading and overriding. (if the interviewee can answer that) Why do we overload? We can use the same function name again, but why should we? Why can't we just create another, more specific name that describes the parameters involved? What are we trying to achieve by overloading?

For this question, I don't really expect a sure answer at first. (Surprisingly, very few people get it right anyway) The battery of succeeding questions in designed to clue the developer into the most possible answer very discretely. This is to test if the interviewee can go beyond what he knows and use the context clues to formulate a solution to the problem.

2. Explain database normalization. (if the interviewee can answer that, and by god he should be able to) Name one possible instance where not normalizing database design can be advantageous.

This question tries to test the ability of the developer to perform a reversal of perspective. There are actually a lot of possible answers to this question and I'm sure I'm not aware of each and every one of them. Quite frankly, I don't care as long as the developer can justify his answer. Many interviewees find this harder than the first question, but to be fair, you can actually find the answer on any database book. They just don't elaborate on the idea too much, or at least not as much as industry experience - which is what matters most of the time.

3. (For more senior proggies) What's the difference between AGILE and Waterfall? What are the ideal scenarios where the two can be used to their full potential.

Developers tend to have biases. By presenting a question like this, I am forcing the developer to try to act fairly between too very polarized ideologies. This is also usually the question that brings out the level of passion and argumentative attitude of a developer - something you're likely to encounter a lot when he's already working for/with you.

4. (At the end of every interview) Do you remember the names of your interviewers?


This last question started as a fun bonus a few years back when we got bored of what we were doing. Interestingly, it also measures the degree of observance of the interviewee, specially if we deliberately mention the interviewers' names throughout the session. Being able to answer this question is usually a plus, but we don't really weigh it against the subject if he can't answer (personally I'm poor with names)