Implementation of my division algorithm in C++

Hello guys, I have written a new approach (in C++) towards dividing two large numbers, input is dividend and divisor, and output shall be quotient and remainder. The algorithm and source code in C++ is presented here "as-is", anyone can use it, without any warranty to the damage(s) that may happen. The source code in text format is well documented and is self-explanatory.

ALGORITHM:
INPUT : Dividend, Divisor
OUTPUT: Quotient, Remainder

static int cnt;
if (dividend = divisor)
   return quotient = 0, remainder = 0
else if (dividend < divisor)   
return quotient = 0, remainder = dividend 
else  
{
   static int residue = dividend;  
   while(residue >= divisor)
{
residue = residue - divisor;
cnt++;
}
}
return quotient = cnt; remainder = residue;

The source code in C++ can be downloaded from HERE

My 5 Golden Rules about Interviews!

Hello friends! Let me talk something about my previous post first! My previous post addressed the interview issues regarding the language questions. However, we all know that there are less language questions than that of ((Data Structures, Problem Solving, Algorithms, OS, Networks, etc.))(From now onwards, called 'BUNCH') These are the most important among all of the topics and is the topic of my discussion in this post too.

RULE 1. "Know Your Enemy( The host)":

You need to understand that the techie on the other side of the table who is going to interview you, is a technical person in the company, has sound knowledge of the Bunch(even if you doubt the 'soundness', there is no harm in assuming it!!), He knows answers to all the questions which he is going to ask you very well(obviously, but answering the problems you know answers already isn't a big deal, so this shouldn't give you the impression of his knowledge on the subject!).

RULE 2. "Host isn't The Champ":

I hope you have understood the rule 1, now you know that what your host is, so make it very very clear in your mind that "Nobody learned from birth, it is this world which have given you all the knowledge or whatsoever" and the host is no exception at all, so rule 2 is that host isn't the champ, he was like you once, you will be like him some day, please don't misunderstand me, I don't mean that you underestimate him, I just want to make sure that you feel confident, feel standing on your feet, have poise, and don't shake."

RULE 3. "If you know the answer beforehand, pretend as if you solved it right now"

That should be fairly simple idea for you guys, you have done it many times before with your friends, family etc., you remember/noticed it or not, but ya true, sometime we pretend in giving some answer so well that the other person can't catch. This happens often in puzzles, we solve so many puzzles that we remember the data in the question as well as the answer, or atleast the way to solve it, and we pretend too! Fair enough, go ahead, keep doing it, the only thing that changes here in the interview is that you have to do the same thing in a very formal and sophisticated manner.

RULE 4. "Understand why the problem has been given to you"

That sounds stupid, isn't it? Really not, as will be clear soon. The problem has been given to me because
No. 1. I am being interviewed.
No. 2. Host want me to solve the problem, or atleast I try it hard.
No. 3. Host want to see how easy/tough/fast/late I give up, means I fought.
OK, fine, bottom line is that the host has given you the problem to check the following:
1. How fast you solve, even if you solve it!
2. How efficient is your solution(in terms of complexity).
3. If you haven't solved it, did you quit early?
4. If you haven't solved it, how long you fought with the problem to find the solution?

RULE 5. "NEVER EVER GIVE UP"

My interview experience advocates this principle of never-ever-giving-up.

I found this principle applicable everywhere, let me make it more clear to you guys, many times, such situations happened before me (including interviews, friends etc.) that this golden rule helped me. Never giving up gives you a sense of fighter, that reflects on your face, you don't really have to pretend it though, but remember one thing actions and feelings go together, by regulating the actions, we can indirectly regulate the feelings which are not in our direct control. So guys, be wise, and never give up.

BOTTOM LINE:

"No matter how hard the given problem is, no matter you have heard about it before or not, no matter nothing, fight with a problem to solve it like a tiger goes for its hunt, and never ever give up. The host want to see how hard you tried!"

Cheers!
Rajendra

A bit from my Interview Mantra!!

Surprisingly, a sudden turn from my pot! I am going to talk about my interview experience and want to share a bit!
In my little yet good experience, interviews want to know that you know the language (a little bit) and that you understand data structures and/or algorithms (ie programming techniques not necessarily language specific) and more importantly can see how you combine both. They also like to see that you can think.

While I doubt there are "standard" questions, I would suggest studying some data structures and thinking about what you can do with them (I think lists, queues/stacks and binary trees would be the most likely).

To show you can think, they will usually ask you to manipulate/work with the structure to do something slightly out of the ordinary (that is, they will assume you can create/traverse the structure but will have you solve a problem with it).

For Example: One that I have experienced before (more than once) relates to finding the midpoint of a linked list.

It is also good to understand how different data structures vary (eg difference between doubly & singly linked list, queue and stack) as well as differences in simple algorithms (eg post-order/pre-order/inorder traversal of trees, different search and sort methods).

A lot depeneds on the type of position. If you are going for a graduate/entry level position, they often want to gauge what you know. This means they will talk to you before asking questions and ask you your strengths. Try to sell the ideas listed above that you understand, to prompt for a question in that area (to confirm your story). For example:

Q: What areas did you study at School?
A: I completed courses in Software Engineering, Artificial Intelligence and Data Structures and Algorithms. During the Data Structures and Algorithms course my major project required me to design a simple program to store University Enrolments. Focusing on optimizing search times rather than Add/Delete times, I decided to organize my data in a Binary tree....etc

In this way, you claim "I know about BT's" and you should get a question on one. As with School, ultimately the prospective employer wants to know what you know not what you don't know.

Of course, different companies, different countries possibly different story, but in my experience: Always sell your knowledge, and try (not always possible) to steer interviews toward areas you know. Most important though, be confident but not cocky and don't just make things up if you don't know (even if the interviewer is only a human resource manager).
Cheers!
Rajendra