Thanks,
Al Pacino
Hang out here for the month of November. Read all the posts. When
people ask a question, see if you can figure out the answer without
peaking at what others have posted. If you can do that, you'll do
well. (And if no one else has posted, you can be the first and help
some poor fellow who is stuck.)
Michael
I recomand to decide first what area are you interested in. GUI? MFC?
cell phones?
here are lined list problems
http://cslibrary.stanford.edu/105/
http://www.careercup.com/ has quite a few questions.
But the problem is that many standard c++ interview questions are
unlikely to come up here.
There is a pool of about 100 c++ questions which unimaginative
interviewers feel compelled to ask.
What's the difference between a pointer and a reference?
When and why should a destructor be virtual?
It's not enough simply to know the answers. The OP should have
actually planned a response in advance.
Paul Epstein
I'm not sure, but if I were the interviewer, there'd be a lot of
questions which would be off topic here. Questions about design
and such, for example. Or the tools he'd used and was familiar
with. There'd also be questions designed to determine how he'd
react in front of something unknown---does he know how to find
information, and can he learn? And I'd also try to determine
whether he'd fit into the team---questions for which there is no
right answer.
On the other hand, a lot of questions here are about real
subtilities of the langauge. Things I wouldn't bother too much
with, because if your code depends on them, then it probably
isn't very understandable anyway. That doesn't mean that such
questions aren't interesting; I would consider the fact that
someone would ask such questions---that he wants to know more
than the minimum required---very positively. But I wouldn't ask
them myself on an interview question unless the role was that of
a C++ guru. And if he's just graduating, he wouldn't even be
considered for such a role. (Perhaps wrongly: I've known at
least two people who would have qualified for such a role even
before graduating.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
A more likely question than anything from that doc is whether he
is aware of its existence, and uses it.
That link seems to be broken.
Seems like the server is a bit flaky, it worked (for me) when I posted
the link but now it does not. Until it gets up again the following
address works: http://www.coders2020.com/cplusplus-explained/index.html
While not fully up to date, it is from 2006, yours was from 2005.
--
Erik Wikström
This is simply false. The probability that he would be asked a
question which the doc answers is over 75%. The probability that he'd
be asked about his awareness of the doc < 5%.
Paul Epstein
Are you sure? My experience is that I'm often asked questions
concerning the documentation that I use: have I read X, what did
I think of it, what did I learn from it? Asking some trivial
detail from the FAQ is senseless---if the programmer knows of
the existence of the FAQ, he can find the answer anytime he
needs it; if he doesn't then he can't. And since no one knows
the answer to all possible questions, it's far more useful to
ascertain that the candidate knows how to find the answer to
something he doesn't know than the test his knowledge on some
necessarily restricted subset of possible questions. At least
when it is a question of details---you obviously do want to find
out if he has some inkling of the more important points.
Well, I've had quite a few job interviews and I do feel fairly sure --
I stand behind my estimated probabilities. You're operating under the
false assumption that interviewers think carefully about their
questions. Instead, most interviewers just ask from the same
standardised pool of questions. For example, they usually ask "What's
the difference between a pointer and a reference?" That's a bit like
asking "What's the difference between a bicycle and a textbook on
algebraic geometry?"
Paul Epstein
Coincidentally the answers are alike too: one can understand the former but
not the latter :-)
Best
Kai-Uwe Bux
Actually,I am very agree with you. If you want to pass a interview.I
think the mosr
important thing that you should do is to build a solid base.
I think I can recommend you some books about C++.
Thinking in C++ Vol1.2
Absolutely C++
Effective C++
More Effective C++
Exception C++
If you want to learn algorithms and data structure,the best books are
The art of computer programming Vol1 2 3.
--
Ian Collins.
> That's a bit like
> asking "What's the difference between a bicycle and a textbook on
> algebraic geometry?"
What's a bicycle? :)
--
-kira
Yes, but I'm talking about the general case, not specifically you.
Also, the fact that people have sometimes given you a script, and
assumed you would just follow it, is certainly evidence in my
direction. If most people in your position thought of original
questions, no one would give you a script.
Paul Epstein
--
Ian Collins.
> >>> Well, I've had quite a few job interviews and I do feel fairly sure --
> >>> I stand behind my estimated probabilities. You're operating under the
> >>> false assumption that interviewers think carefully about their
> >>> questions. Instead, most interviewers just ask from the same
> >>> standardised pool of questions. For example, they usually ask "What's
> >>> the difference between a pointer and a reference?" That's a bit like
> >>> asking "What's the difference between a bicycle and a textbook on
> >>> algebraic geometry?"
> >> Do they? I've conducted scores, maybe even hundreds of interviews over
> >> the years and I've never followed a script. On the few occasions I've
> >> been given one, I've ignored it. Asking from a fixed set of questions
> >> isn't an interview, it's a quiz and a waste of both party's time.
> > Yes, but I'm talking about the general case, not specifically you.
> > Also, the fact that people have sometimes given you a script, and
> > assumed you would just follow it, is certainly evidence in my
> > direction. If most people in your position thought of original
> > questions, no one would give you a script.
> The script didn't contain any C++ questions, only HR related ones. I've
> also been on the receiving end of a fair number of interviews and only
> about half the interviewers followed a script. These days I'd be
> reluctant to work anywhere where they did, it's indicative of company
> cultures I dislike.
That's a point, too.
I'm independent, so I interview a lot. A few (very few) places
have given me a written test, generally designed just to weed
out the obvious bluffers. Other than that, I've never had any
really detailed programming questions concerning C++; the most
frequent question seemed to be whether I was familiar with the
Design Patterns book, and which patterns in it I'd actually
used.
Obviously, of course, I haven't interviewed for beginners
positions, so maybe the situation is different for them. I have
done interviews myself, for several different clients, and
except for a few simple questions to weed out obvious bluffers,
my questions have never concerned language details. (By simple
questions, I mean things like: "Why would you declare a
destructor virtual?" When the answer is something along the
lines of "What do you mean by virtual?", and the candidate
claims four years experience with C++ in an OO environment, you
don't have to interview any further.)
--
James Kanze (GABI Software) email:james...@gmail.com
Common language specific Questions I got asked post graduation:
What is the differance between a virtual destructor and a regular
destructor?
Lots of Find the error in the following code: <insert bad programming
here, usually some memory leak>
What is a linked list? What is a "chained" link list?
What is the output of <insert arithmetic involving int and float
combinations>
Give me the syntax for private inheritance
What compilers have you used?
What debuggers have you used?
How would you debug the following <insert problem here>
Additionally frustrating is interviewing with some managerial person
whom got thier questions from an IT guy and screws up the verbage or
doesn't understand any black and white answer they don't have written
down. So, when you explain "How I would do it" answers, be sure to
know how to explain it well or they will most likely discount it for a
wrong answer.
Be prepared for the common interview questions like:
why do you want to work here
what did you like about your last job
what did you hate
give me an example of some conflict you had
blah blah blah
I've also found that putting a link to my ftp or http site with demo
code to be very valuable, as the silly mangerial staff will usually
foward that to a real engineer whom will then push hard for your
hire...if you have well written and readable code that is...
You will also find that most entry level positions involve more
debugging other peoples garbage code than writing your own. So, be
prepared for it. Developing skills in communicating and convincing
arrogant programmers that think they are smarter than you is
essential. Doing it in a way that allows them to retain their pride is
even better.
I've just recently joined the the civilian world and had all those
interviews...
I really dont understand all of those tests... 4 pages of inheritance
to see if you can draw a flow chart... all those trap Q's... things I
will never use that were invented for the only reason of supplying Q's
for interviews...
And there were the testers that asked me a few global Q's about my
knowledge and than the task of coding something... anything... with
MSDN and internet and afterwards a code review.
Simple, fun and effective.
> .... If you want to pass a interview.I think the most important thing that you should do is to build a solid base.
> I think I can recommend you some books about C++.
> Thinking in C++ Vol1.2
> Absolutely C++
> Effective C++
> More Effective C++
> Exception C++
> If you want to learn algorithms and data structure,the best books are
> The art of computer programming Vol1 2 3.
>
I'd recommend Dewhurst's "C++ Common Knowledge" for starters.
--
Paul M. Dubuc