Large Integer Value
Hi Guys,
A friend of mine asked me a question and I gave him few answers but I don't know if there is some really good explanation for the question. This is the question he was asked in an interview. So I was hoping if any one of you could shed some light.
Question is: Suppose you have a function in which you have an integer variable that is assigned to 0. After some time it's values becomes very large. How will you debug that?
This is the question. He did not mentioned any what is the code inside that function.
Any guidance would be appreciated.
Thanks
A friend of mine asked me a question and I gave him few answers but I don't know if there is some really good explanation for the question. This is the question he was asked in an interview. So I was hoping if any one of you could shed some light.
Question is: Suppose you have a function in which you have an integer variable that is assigned to 0. After some time it's values becomes very large. How will you debug that?
This is the question. He did not mentioned any what is the code inside that function.
Any guidance would be appreciated.
Thanks
That seems to be an incomplete question to me. What's the interviewers definition of large? Too large for an int?
Last edited on
That's true. Even I feel that this is an incomplete question. Some answers that I suggested to my friend are: May be this variable is assigned to some reference variable and that reference variable's value is changed somewhere. Other possible answer could be, we can debug it using some tool like gdb (this seems to be a bad answer for debugging integer values). I am really confused, and I think that there should be some explanation for this question. May be someone on this forum have some idea about this.
You should choose data types that will be able to hold what the problem is...you don't choose an int if you know you are going to have data up in the trillions...
Anyway, as for debugging...I don't really see any way you could debug that without either using a debugger or just print it out every so often and see if it loops around or drops when you are adding numbers to it, etc. The question is still sort of vague though...
Anyway, as for debugging...I don't really see any way you could debug that without either using a debugger or just print it out every so often and see if it loops around or drops when you are adding numbers to it, etc. The question is still sort of vague though...
Tell your friend to go running and screaming away from that job.
Job interviewers often come along with a list of really dumb questions, but when they are that vague and unenlightened, you don't want to be working for that company. (Even if it is MS.)
The correct response would have been, "Get a bigger zero." Then smile wryly, and say -- knowing nothing about the code, functional requirements, any recent changes in requirements, and operating environment, then the question might as well be, "How much peanut butter is enough on a PBJ?"
(Job interviewers often don't have a clue about what they are talking about. So they get lists of stupid questions and answers to help them gague the interviewee's knowlege and skills.)
Job interviewers often come along with a list of really dumb questions, but when they are that vague and unenlightened, you don't want to be working for that company. (Even if it is MS.)
The correct response would have been, "Get a bigger zero." Then smile wryly, and say -- knowing nothing about the code, functional requirements, any recent changes in requirements, and operating environment, then the question might as well be, "How much peanut butter is enough on a PBJ?"
(Job interviewers often don't have a clue about what they are talking about. So they get lists of stupid questions and answers to help them gague the interviewee's knowlege and skills.)
I agree.
Technical interviewers are too often there to see how much the candidate knows. The problem is that there is no way to quantify that absolutely, so the interviewer can at best only gauge how much the candidate knows in relation to the interviewer him/herself. If the candidate is deemed to know as much (within x% on the low side) as the interviewer, then the candidate is given a thumbs up.
This works great if the interviewer is one of the best technical folks. Problem is, that's not the case most times, so you end up hiring someone who is average at best.
Technical interviewers are too often there to see how much the candidate knows. The problem is that there is no way to quantify that absolutely, so the interviewer can at best only gauge how much the candidate knows in relation to the interviewer him/herself. If the candidate is deemed to know as much (within x% on the low side) as the interviewer, then the candidate is given a thumbs up.
This works great if the interviewer is one of the best technical folks. Problem is, that's not the case most times, so you end up hiring someone who is average at best.
Topic archived. No new replies allowed.