C++ interview Question
Pages: 12
I have collected interview question and added this forum. Please feel free to add more question for making good collection
closed account (z05DSL3A)
| Disch wrote: |
|---|
| so where are the interview questions? |
You don't want that asked in a interview. :0)
ooops I tried to add question but did not sucess .
I also try to attach Question in the article but did not sucess. Can anyone help me ...
I also try to attach Question in the article but did not sucess. Can anyone help me ...
so I am doing copy pasting but not happy like that. i was planning to attach document which will be more useful...
at last I create my blog and post my question and further i will update blog and create new blog
The possible existence of such lists is why I feel that interview questions that test knowledge are not useful.
Anyone can know the answer without actually knowing the answer simply by reading the list and
memorizing the answers.
When I ask a right/wrong question such as "What is a pointer?", my goal is not to find out if the candidate
knows what a pointer is. My goal is to figure out how much C++ they know. If they can't answer the
question at all, then obviously they don't know C++. If they can, then as the interviewer I've learned
nothing about the candidate.
IMO the best questions are the ones that don't have right/wrong answers. For example:
"Given a head pointer of a singly-linked list, your job is to give me an algorithm that will
determine whether or not the list is coherent (ie, there are no "cycles" in the list). You
can assume that all pointers point to nodes."
Then I ask the candidate to think for a minute and come up with any solution to the problem.
I then proceed to ask about runtime efficiency, memory efficiency, and other questions that pop
into my mind as they are giving me their solution.
The idea isn't to see if they come up with the optimal answer; indeed, I prefer if they don't. My goal
is to see their thought process. If they come up with the optimal answer immediately, it either means
they are very smart or they heard the question before -- I can't tell which.
Anyone can know the answer without actually knowing the answer simply by reading the list and
memorizing the answers.
When I ask a right/wrong question such as "What is a pointer?", my goal is not to find out if the candidate
knows what a pointer is. My goal is to figure out how much C++ they know. If they can't answer the
question at all, then obviously they don't know C++. If they can, then as the interviewer I've learned
nothing about the candidate.
IMO the best questions are the ones that don't have right/wrong answers. For example:
"Given a head pointer of a singly-linked list, your job is to give me an algorithm that will
determine whether or not the list is coherent (ie, there are no "cycles" in the list). You
can assume that all pointers point to nodes."
Then I ask the candidate to think for a minute and come up with any solution to the problem.
I then proceed to ask about runtime efficiency, memory efficiency, and other questions that pop
into my mind as they are giving me their solution.
The idea isn't to see if they come up with the optimal answer; indeed, I prefer if they don't. My goal
is to see their thought process. If they come up with the optimal answer immediately, it either means
they are very smart or they heard the question before -- I can't tell which.
Questions and answers in an interview would be based on the type and number of requirement and the type and number of applicants.
My view is that prepared questionnares and answer guides are widely used in en-masse hiring where quality of job and the person being interviewed is not on the highest priority.
Even people with good thought process are forced to correctly answer knowledge based questions because those are thought to be the criteria to judge a person on his C++/java skills.
e.g. a person with 3+ years of experience working in C++ is still asked to write a program to implement a sorting algorithm and swapping two values without using a third one and that too over the telephone....!!
And there are enough chances of him being rejected or being paid lesser than those who answered these questions even though he may have more problem-solving and learning skills.
This happens because most of the hiring in service industry is not probably based on job requirements, but instead being done to maintain the number of resources skilled in technologies being used for the projects undertaken by the company.
Such an industry profiles the (human) resources under categories such as technology / experience / expected salary, not in terms of adaptability / willingness / skills.
Counter arguments are most welcome.
My view is that prepared questionnares and answer guides are widely used in en-masse hiring where quality of job and the person being interviewed is not on the highest priority.
Even people with good thought process are forced to correctly answer knowledge based questions because those are thought to be the criteria to judge a person on his C++/java skills.
e.g. a person with 3+ years of experience working in C++ is still asked to write a program to implement a sorting algorithm and swapping two values without using a third one and that too over the telephone....!!
And there are enough chances of him being rejected or being paid lesser than those who answered these questions even though he may have more problem-solving and learning skills.
This happens because most of the hiring in service industry is not probably based on job requirements, but instead being done to maintain the number of resources skilled in technologies being used for the projects undertaken by the company.
Such an industry profiles the (human) resources under categories such as technology / experience / expected salary, not in terms of adaptability / willingness / skills.
Counter arguments are most welcome.
there are couple of things during interview process and working enviroment.
When you appear for interview they still ask very basic question which you do not use in day to day life when you are working large code base system.
these question always embrassed you as you know all question but you could not recall .Sometime these basic question are start up for question for any interview and if you stumble
in basic question than it would be difficult for further discussion with interviewer.
Sometime these basic question impress interviewer and help to get through interview.
I collected this question from various site and find best answer and put together in one place .So you can quickly go through basic question.
But Another hand, it is also depend on the interviewer when they look for approach and not for the solution as jsmith mentioned in reply than these question will not help you but it will recall all basic question.
When you appear for interview they still ask very basic question which you do not use in day to day life when you are working large code base system.
these question always embrassed you as you know all question but you could not recall .Sometime these basic question are start up for question for any interview and if you stumble
in basic question than it would be difficult for further discussion with interviewer.
Sometime these basic question impress interviewer and help to get through interview.
I collected this question from various site and find best answer and put together in one place .So you can quickly go through basic question.
But Another hand, it is also depend on the interviewer when they look for approach and not for the solution as jsmith mentioned in reply than these question will not help you but it will recall all basic question.
I agree about prepared questionnaires. The advantage to them is that it gives a common yardstick by which
to measure many candidates, particularly if there are multiple interviewers in question. But, in order to be
useful, the questions have to all have clearly right and wrong answers -- no room for interpretation, because
the point is to normalize the scores amongst all the interviewers. At that point they are equivalent to a college
exam.
Which is an acknowledgment that not all interviewers are the same. Indeed, I think Arthur C. Clarke's statement
that "any sufficiently advanced technology is indistinguishable from magic" applies here, albeit in a slightly
different way. An interviewer who knows everything there is to know about OO programming in C++ but has
never once used or written a template can easily benchmark a candidate's knowledge of classes, inheritance,
virtual functions and the like, but wouldn't have a clue how to interpret an answer that involved template
metaprogramming. So if that interviewer asked the question: "Design a polymorphic data structure in C++",
that interviewer is looking for answer involving a base class and derived classes and storing pointers to the
base type in the container/data structure. Which is an OK answer, perhaps.
But another candidate might say: "Well, I could do it that way, but since that way forces me to know all the types
I'll hold in the container at compile time anyway (because I need to inherit the base type), I could use a
boost::variant instead, which avoids the tight coupling associated with inheritance." The candidate could then
go on to talk about how boost::variant works and how boost::static_visitor works, and the pros of using it
over virtual functions. Meanwhile the interviewer can only sit there and listen because the answer is well beyond
their expertise. The candidate could be the smartest candidate in the world, or the candidate could make up half
of it as long as it "sounds right" to the interviewer.
Which of the two candidates has the best chance of being hired? I don't think it's clear. Maybe the company
doesn't use templates for some reason. Maybe they don't use boost. Maybe they never heard of boost.
Maybe the first candidate gets hired because chances are, from the interviewer's perspective, the interview
went smoother because both candidate and interviewer were "on the same page" which better fostered a
two-way conversation. Maybe the second candidate gets hired because the interviewer was so impressed
by "how smart" the candidate seemed. (I've actually had candidates look at me, the interviewer, in awe and
tell me how smart I am. It was just "magic" to the candidate.)
The bottom line is that the knowledge level of the interviewer is important, because the interviewer at best
can only measure the knowledge/ability levels of the candidate up to the knowledge/ability level of themself.
Anything beyond that becomes indistinguishable from magic -- the interviewer just can't know right from wrong,
good from bad.
to measure many candidates, particularly if there are multiple interviewers in question. But, in order to be
useful, the questions have to all have clearly right and wrong answers -- no room for interpretation, because
the point is to normalize the scores amongst all the interviewers. At that point they are equivalent to a college
exam.
Which is an acknowledgment that not all interviewers are the same. Indeed, I think Arthur C. Clarke's statement
that "any sufficiently advanced technology is indistinguishable from magic" applies here, albeit in a slightly
different way. An interviewer who knows everything there is to know about OO programming in C++ but has
never once used or written a template can easily benchmark a candidate's knowledge of classes, inheritance,
virtual functions and the like, but wouldn't have a clue how to interpret an answer that involved template
metaprogramming. So if that interviewer asked the question: "Design a polymorphic data structure in C++",
that interviewer is looking for answer involving a base class and derived classes and storing pointers to the
base type in the container/data structure. Which is an OK answer, perhaps.
But another candidate might say: "Well, I could do it that way, but since that way forces me to know all the types
I'll hold in the container at compile time anyway (because I need to inherit the base type), I could use a
boost::variant instead, which avoids the tight coupling associated with inheritance." The candidate could then
go on to talk about how boost::variant works and how boost::static_visitor works, and the pros of using it
over virtual functions. Meanwhile the interviewer can only sit there and listen because the answer is well beyond
their expertise. The candidate could be the smartest candidate in the world, or the candidate could make up half
of it as long as it "sounds right" to the interviewer.
Which of the two candidates has the best chance of being hired? I don't think it's clear. Maybe the company
doesn't use templates for some reason. Maybe they don't use boost. Maybe they never heard of boost.
Maybe the first candidate gets hired because chances are, from the interviewer's perspective, the interview
went smoother because both candidate and interviewer were "on the same page" which better fostered a
two-way conversation. Maybe the second candidate gets hired because the interviewer was so impressed
by "how smart" the candidate seemed. (I've actually had candidates look at me, the interviewer, in awe and
tell me how smart I am. It was just "magic" to the candidate.)
The bottom line is that the knowledge level of the interviewer is important, because the interviewer at best
can only measure the knowledge/ability levels of the candidate up to the knowledge/ability level of themself.
Anything beyond that becomes indistinguishable from magic -- the interviewer just can't know right from wrong,
good from bad.
agree and always nice thought :) jsmith.
So another request Please have a look on my question and provide me input ....
My intention was writing some code and question which are very common so that you can easily
revisited all basic stuff although yo do not use day to day life.. and might be useful for interview
So another request Please have a look on my question and provide me input ....
My intention was writing some code and question which are very common so that you can easily
revisited all basic stuff although yo do not use day to day life.. and might be useful for interview
Wouldn't it be more useful to ask questions about stuff that you DO use daily? I mean, if an applicant claims to know/use the STL, a few questions could confirm/disprove the fact and gain a little insight into how well he or she knows the STL...
jsmith,
"Given a head pointer of a singly-linked list, your job is to give me an algorithm that will
determine whether or not the list is coherent (ie, there are no "cycles" in the list). You
can assume that all pointers point to nodes."
Great question! But I'm assuming that if all pointers point to nodes, then it is not coherent because a coherent list must have a null pointer at the last node. But let's assume that you meant to say that all pointers either point to nodes or are null.
(a) I would start by asking them how many cycles you could have, and where they could possibly appear in the list.
(b) Then I would ask them to do it the easy/obvious way--O(n^2) time.
(c) Next, I would ask them to do it in O(n log n) time.
(d) Since you did not say that it had to be done non-destructively, I would also ask for how it could be done in O(n) time--but you must not change the node structure or allocate additional heap memory.
(e) Finally, I would ask how it could be done in O(n) time, using additional heap if necessary, but the list must be in the same state that the end of the algorithm as it was initially.
BONUS 1: How to do it in O(n) time without allocating any additional heap memory AND without modifying the node structure AND by having the list in the initial state at the end (tell them they will have a system memory map to look at in advance).
BONUS 2: Same conditions as bonus 1, PLUS must not use a for, while, do-while, goto, or inline assembly jump of any sort.
The funny thing is that you can answer these questions by asking new questions. So jsmith, do I get hired?
"Given a head pointer of a singly-linked list, your job is to give me an algorithm that will
determine whether or not the list is coherent (ie, there are no "cycles" in the list). You
can assume that all pointers point to nodes."
Great question! But I'm assuming that if all pointers point to nodes, then it is not coherent because a coherent list must have a null pointer at the last node. But let's assume that you meant to say that all pointers either point to nodes or are null.
(a) I would start by asking them how many cycles you could have, and where they could possibly appear in the list.
(b) Then I would ask them to do it the easy/obvious way--O(n^2) time.
(c) Next, I would ask them to do it in O(n log n) time.
(d) Since you did not say that it had to be done non-destructively, I would also ask for how it could be done in O(n) time--but you must not change the node structure or allocate additional heap memory.
(e) Finally, I would ask how it could be done in O(n) time, using additional heap if necessary, but the list must be in the same state that the end of the algorithm as it was initially.
BONUS 1: How to do it in O(n) time without allocating any additional heap memory AND without modifying the node structure AND by having the list in the initial state at the end (tell them they will have a system memory map to look at in advance).
BONUS 2: Same conditions as bonus 1, PLUS must not use a for, while, do-while, goto, or inline assembly jump of any sort.
The funny thing is that you can answer these questions by asking new questions. So jsmith, do I get hired?
Last edited on
What I meant was that they didn't have to worry about seg faults as a result of bogus, non-null pointers.
Assume that the pointer dereference is valid if the pointer is not null.
The majority of candidates--even good ones--are only going to come up with the N^2 solution during
an interview. If they have trouble answering b) then there is little point to asking for better ways, and
certainly during an hour interview they won't be able to answer all of the questions.
But CodedoC, you didn't answer my question.
Assume that the pointer dereference is valid if the pointer is not null.
The majority of candidates--even good ones--are only going to come up with the N^2 solution during
an interview. If they have trouble answering b) then there is little point to asking for better ways, and
certainly during an hour interview they won't be able to answer all of the questions.
But CodedoC, you didn't answer my question.
| jsmith wrote: |
|---|
| The majority of candidates--even good ones--are only going to come up with the N^2 solution during an interview. |
WTH, dont all good candidates know some basic binary search tree or hashtable concepts ? I would have thought O(n log n) would be the basic "decent" answer.
I looked up the "elegant" solution online and man it is beautiful :)
Exactly. Candidates are under pressure. They are nervous. Things that seem "obvious" aren't so simple
under stressful conditions. Most candidates feel that if they give a wrong/unworkable answer, they won't
get hired.
under stressful conditions. Most candidates feel that if they give a wrong/unworkable answer, they won't
get hired.
Pages: 12