By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,852 Members | 2,240 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,852 IT Pros & Developers. It's quick & easy.

help on C++/programming interviews...

P: n/a
Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...

Btw, could somebody also point me to some good C++ and programming/data
structure/algorithms interview problems?

Thanks a lot!
Nov 4 '06 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Mike wrote:
Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...
I'm afraid to say that if you have to resort to cramming for an
interview, a competent interviewer will very quickly see past the
superficial knowledge you pick up. Even if they do not, you will
probably fail at the job.

Go with what you know.

--
Ian Collins.
Nov 4 '06 #2

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@individual.net...
Mike wrote:
>Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms?
I
do have those big textbooks but I found they don't provide a fast
overview...
I'm afraid to say that if you have to resort to cramming for an
interview, a competent interviewer will very quickly see past the
superficial knowledge you pick up. Even if they do not, you will
probably fail at the job.

Go with what you know.

--
Ian Collins.
This is a bad answer. I am not applying for a pure programming job, although
programming might be 25% of my job. C++ is one portion of this and I need to
pick it up after several years of experiences in other stuff. What's wrong
with cramming and what's wrong with asking for help on cramming more
efficiently? As a colleage student, how much real-world C++ programming
experiences do I have aside from several classes at various stage of my
schoolding? Don't waste other people's bandwidth and time if you don't
intend to help.
Nov 4 '06 #3

P: n/a
Mike wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:4r*************@individual.net...
>>Mike wrote:
>>>Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms?
I
do have those big textbooks but I found they don't provide a fast
overview...

I'm afraid to say that if you have to resort to cramming for an
interview, a competent interviewer will very quickly see past the
superficial knowledge you pick up. Even if they do not, you will
probably fail at the job.

Go with what you know.

This is a bad answer. I am not applying for a pure programming job, although
programming might be 25% of my job. C++ is one portion of this and I need to
pick it up after several years of experiences in other stuff. What's wrong
with cramming and what's wrong with asking for help on cramming more
efficiently? As a colleage student, how much real-world C++ programming
experiences do I have aside from several classes at various stage of my
schoolding? Don't waste other people's bandwidth and time if you don't
intend to help.
What's wrong with cramming? Wasting either your time by getting rumbled
or the employers time discovering you don't have the experience you
appeared to have

The advice stands, go with what you know. If C++ is only part of the
job, they are probably more interested in the other 75%. If you do
succeed in cramming in some facts, the interviewer will assume you know
more and dig deeper.

--
Ian Collins.
Nov 4 '06 #4

P: n/a
Hi

Ian Collins wrote:
What's wrong with cramming? Wasting either your time by getting rumbled
or the employers time discovering you don't have the experience you
appeared to have

The advice stands, go with what you know. If C++ is only part of the
job, they are probably more interested in the other 75%. If you do
succeed in cramming in some facts, the interviewer will assume you know
more and dig deeper.
You're assuming that Mike will pretend to be a Master Of C++. But what's
wrong with having a quick look at some overview in order to get at least an
idea about C++/algorithms? As you said, they will probably find out that
his knowledge is quite shallow, so as long as Mike does not try to cheat on
them, there is no problem. Contrarily, I think that otherwise the
interviewers will wonder why he would not have spent at least 10 minutes of
his time on cramming.

Markus

(Final cross-post, follow-up set to alt.comp.lang.learn.c-c++)

Nov 4 '06 #5

P: n/a

Mike wrote:
Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...

Btw, could somebody also point me to some good C++ and programming/data
structure/algorithms interview problems?

Thanks a lot!
I've sent more than one interviewee away crying after exposing that
they made up their experience and knowledge. I've been known to ask the
interviewee about how he stands on the acetylsolosin QID controversy in
C++ or whether they have had any experience with Feci Tauri methods.

When they start to enumerate their vast experience with (or passing
exposure to) each of them, I know that I'm going to have fun in the
(usualy very short) interview. If at all possible, I will arrange to
get called away and leave the interviewee alone to stew for a while
while I go joke with the buddy of theirs who recommended them.

When I come back, I usually try to discover their experience with NAFC
objects and thank them for coming in. We will put their resume in the
SNK file and call them back when the weather changes (like when hell
freezes over).

I do sympathize. I learned more in my first 4 hours on a real gig than
I did in 4 years of undergrad. You will likely do the same. If someone
is truely in the market for an SNK, they are more concerned about how
you approach problems and how fast you can learn stuff than in your
ability to cram for an interview. I look for integrity, ability, and
cooperation in the people whom I hire.

Nov 4 '06 #6

P: n/a
I believe too much emphasis is made in interviews on what one knows
there and then. Some interviewers will judge you on a small amount of
knowledge they might expect you to have since they had come across it
in the past and they will completely disregard anything else you might
know or can do. Although I tend not to do any cramming myself I feel it
is a useful exercise especially when it improves one knowledge. This
can only be a good thing.

Certainly, you should never go to an interview with the intention to
mislead. Again, some interviewers may suspect you of trying to mislead
them; maybe this is because they know they might do (have done) this
themselves.

In terms of good online references I would recommend the following
links: -

http://www.informit.com/guides/guide...cplusplus&rl=1
http://www.parashift.com/c++-faq-lite/
http://www.cppreference.com/
http://www.sgi.com/tech/stl/
http://www.dinkumware.com/manuals/

I hope you find that helpful :)

Mike wrote:
Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...

Btw, could somebody also point me to some good C++ and programming/data
structure/algorithms interview problems?

Thanks a lot!
Nov 7 '06 #7

P: n/a

Michael Angelo Ravera wrote:
Mike wrote:
Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...

Btw, could somebody also point me to some good C++ and programming/data
structure/algorithms interview problems?

Thanks a lot!

I've sent more than one interviewee away crying after exposing that
they made up their experience and knowledge. I've been known to ask the
interviewee about how he stands on the acetylsolosin QID controversy in
C++ or whether they have had any experience with Feci Tauri methods.
Thanks for the tip. I got a huge fright! ;-)

Werner

Nov 7 '06 #8

P: n/a


On Nov 4, 9:24 am, "Mike" <housing2...@gmail.comwrote:
"Ian Collins" <ian-n...@hotmail.comwrote in messagenews:4r*************@individual.net...
Mike wrote:
Hi all,
Ian Collins.This is a bad answer. I am not applying for a pure programming job, although
programming might be 25% of my job. C++ is one portion of this and I need to
pick it up after several years of experiences in other stuff. What's wrong
with cramming and what's wrong with asking for help on cramming more
efficiently? As a colleage student, how much real-world C++ programming
experiences do I have aside from several classes at various stage of my
schooling? Don't waste other people's bandwidth and time if you don't
intend to help.-
When I was a student I found that there were some subjects I really
knew and I didn't really need to apply any special techniques at all to
answer the examinations, I could just answer them from my knowledge
whatever they were likely to ask and pass easily with an A grade. It
was only in those when I didn't really know the subject properly that I
had to apply some "technique" - planned answers for what they were
likely to ask - and then I most often got only a B grade.

A good interviewer (as well as a good examination paper in my opinion)
will test the full range so there will be some easy questions, some
medium questions and some real testers so they can find your true
level. They might not expect you to know everything.

In my opinion it should generally be based on understanding techniques,
not necessarily knowing the technical names for them, but unfortunately
that's not always the way it is, so my advice is to at least ensure you
do know the technical names for the techniques you understand.

Know what these terms mean:
- Inheritance
- Overriding
- Overloading
- Polymorphism
- Encapsulation.

You might even add a comment, eg if asked what encapsulation means, you
might say that it technically means wrapping in a shell, and
technically is used to protect the user of a class from its
implementation detail. You might say that this is often done with
private members but ideally it is done in a manner whereby the users of
the class cannot see any implementation detail at all. You might
mention the pImpl idiom.

You might get asked about design patterns too. These are questions that
have annoyed me a lot because I have used them without knowing the
technical names for them. I don't know of a good site that gives a
quick, clear explanation of them, and possibly a very simple example in
C++. Perhaps I should write my own.

You might get asked some questions about the language.

- What is the difference between a struct and a class? Commonly asked
question. Remember to state that technically the only difference is
that by default, access in a struct is public and in a class is
private, and that by default a struct inherits publically and a class
privately. You may however want to point out that although this is the
only technical difference, because one tends to associate a struct with
C, the struct keyword is most often used only for basic aggregates of
data.

- What is the difference between a pointer and a reference? References
use a different syntax, must be initialised to refer to a single object
and must then refer to the same object throughout their lifetime. A
pointer need not be initialised, may point to NULL and may later point
to a different object - and they use a different syntax.

- What is the difference between a macro and a 1. template 2. inline
function. I'll leave you to answer those.

Nov 7 '06 #9

P: n/a
[cross-posting deleted]

Mike wrote:
I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...

Btw, could somebody also point me to some good C++ and programming/data
structure/algorithms interview problems?
See the FAQs, starting with this one:

http://www.parashift.com/c++-faq-lit....html#faq-6.14

Cheers! --M

Nov 7 '06 #10

P: n/a

Mike wrote:
Hi all,

I am cramming for an technical interview about C++ and programming... I
believe there will be problems on data-structures and algorithms... could
anybody recommend some online resources/references/websites so that I can
find summary sheet about the confusing points of C++ and typical
storage/time complexity of common data structures and common algorithms? I
do have those big textbooks but I found they don't provide a fast
overview...

Btw, could somebody also point me to some good C++ and programming/data
structure/algorithms interview problems?
You know, you might consider that your prospective employer is here
reading this. We have some guys comming in to interview for positions
in testing and for a second I thought you might be one of them.
Probably not, but the point is that there are many here that are leads
in their departments and/or involved directly in the interview process.

Something to keep in mind.

Nov 7 '06 #11

P: n/a

Michael Angelo Ravera wrote:
>
I've sent more than one interviewee away crying after exposing that
they made up their experience and knowledge. I've been known to ask the
interviewee about how he stands on the acetylsolosin QID controversy in
C++ or whether they have had any experience with Feci Tauri methods.
I would be one to answer these questions in detail. You better be an
expert too or I'll convince you they are real.
When they start to enumerate their vast experience with (or passing
exposure to) each of them, I know that I'm going to have fun in the
(usualy very short) interview. If at all possible, I will arrange to
get called away and leave the interviewee alone to stew for a while
while I go joke with the buddy of theirs who recommended them.
But, the joke would be on you because I would know what you where up to
and have decided I probably don't want to work for, or with, such
people.
When I come back, I usually try to discover their experience with NAFC
objects and thank them for coming in.
NAFC as in having to ask trick questions to discover someone's true
experience?

I actually have extensive experience with NAFC objects. NAFC managers
too.

Hopefully you don't really interview people this way. If you do maybe
your employer needs to see what else is in the management market
because that is NOT how to do an interview. I mean, it really is a
rather abrasive and confrontational way to talk to someone and you're
competing for my skills as much (or more possibly) as I am trying to
sell them.

Nov 7 '06 #12

P: n/a
On 7 Nov 2006 10:41:11 -0800, "Noah Roberts" <ro**********@gmail.com>
wrote:
>Hopefully you don't really interview people this way. If you do maybe
your employer needs to see what else is in the management market
because that is NOT how to do an interview. I mean, it really is a
rather abrasive and confrontational way to talk to someone and you're
competing for my skills as much (or more possibly) as I am trying to
sell them.
Hell screw that, I'd work for the guy in a second. It's exactly what
I'd do in his position. That was a nice case of someone passing the
WWGATD* test.
I really dislike people who bullshit and can't admit that they don't
know what I'm talking about. It's extraordinarily dishonest and
insulting.
-==Kensu==-
* - What Would Grand Admiral Thrawn Do?
Nov 7 '06 #13

P: n/a

Noah Roberts wrote:
>
You know, you might consider that your prospective employer is here
reading this. We have some guys comming in to interview for positions
in testing and for a second I thought you might be one of them.
Probably not, but the point is that there are many here that are leads
in their departments and/or involved directly in the interview process.
They may well be but it wouldn't be immediately intuitive that I post
as Earl Purple. There is one person in a company where I used to work
just over a couple of years ago who has been known to post in some of
the c++ groups (comp.lang.c++, comp.lang.c++.moderated and
comp.std.c++). I know who he is but I'm not sure he's worked out who I
really am.

Companies always want the best C++ programmers and are then happy to
shove them into maintenance of legacy code. Why?

Nov 7 '06 #14

P: n/a
Earl Purple said:

<snip>
>
Companies always want the best C++ programmers and are then happy to
shove them into maintenance of legacy code. Why?
Because maintenance is more difficult than development. Any fool can create
bugs, but it takes a special kind of fool to track them down.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 7 '06 #15

P: n/a

Chris Schumacher wrote:
On 7 Nov 2006 10:41:11 -0800, "Noah Roberts" <ro**********@gmail.com>
wrote:
Hopefully you don't really interview people this way. If you do maybe
your employer needs to see what else is in the management market
because that is NOT how to do an interview. I mean, it really is a
rather abrasive and confrontational way to talk to someone and you're
competing for my skills as much (or more possibly) as I am trying to
sell them.

Hell screw that, I'd work for the guy in a second. It's exactly what
I'd do in his position. That was a nice case of someone passing the
WWGATD* test.
Yes, because everyone would love working for or with Thrawn.

Nov 7 '06 #16

P: n/a

Richard Heathfield wrote:
Earl Purple said:

<snip>

Companies always want the best C++ programmers and are then happy to
shove them into maintenance of legacy code. Why?

Because maintenance is more difficult than development. Any fool can create
bugs, but it takes a special kind of fool to track them down.
Bring in the good programmers from the start and you don't have the
mess there to clean up in the first place.

Nov 8 '06 #17

P: n/a
Earl Purple said:
>
Richard Heathfield wrote:
>Earl Purple said:

<snip>
>
Companies always want the best C++ programmers and are then happy to
shove them into maintenance of legacy code. Why?

Because maintenance is more difficult than development. Any fool can
create bugs, but it takes a special kind of fool to track them down.

Bring in the good programmers from the start and you don't have the
mess there to clean up in the first place.
Yeah, I know, but that's what they tried to do at the start, only they
didn't manage it - and now it's too late, because it isn't the start any
more. Companies have to run with what they have, not what they'd like to
have had at the beginning.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 8 '06 #18

P: n/a
* Earl Purple:
Richard Heathfield wrote:
>Earl Purple said:

<snip>
>>Companies always want the best C++ programmers and are then happy to
shove them into maintenance of legacy code. Why?
Because maintenance is more difficult than development. Any fool can create
bugs, but it takes a special kind of fool to track them down.

Bring in the good programmers from the start and you don't have the
mess there to clean up in the first place.
Although off-topic in both groups posted to, I think that comment
deserves a follow-up.

Yes, it would be ideal if that was how projects are managed.

However, a typical project leader in a typical firm would not be a
project leader if he or she couldn't point to past "success stories".
With success being narrowly defined as accomplishing stated goals within
some time & budget frame, ignoring the likely consequences for what
happens later, because it hasn't happened yet. Thus, Darwinian natural
selection operates, ensuring that the project leader's focus will be on
short term advantage, not on negative consequences for those who must
maintain the mess later on (some project leaders may of course focus
also on that, but then, unless there is a long-term follow up policy in
place, it's /better/ that the next lead should fail, because that's then
one less person to compete with for a limited number of positions).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nov 8 '06 #19

P: n/a

Alf P. Steinbach wrote:
* Earl Purple:
Richard Heathfield wrote:
Earl Purple said:

<snip>
Companies always want the best C++ programmers and are then happy to
shove them into maintenance of legacy code. Why?
Because maintenance is more difficult than development. Any fool can create
bugs, but it takes a special kind of fool to track them down.
Bring in the good programmers from the start and you don't have the
mess there to clean up in the first place.

Although off-topic in both groups posted to, I think that comment
deserves a follow-up.

Yes, it would be ideal if that was how projects are managed.

However, a typical project leader in a typical firm would not be a
project leader if he or she couldn't point to past "success stories".
With success being narrowly defined as accomplishing stated goals within
some time & budget frame, ignoring the likely consequences for what
happens later, because it hasn't happened yet. Thus, Darwinian natural
selection operates, ensuring that the project leader's focus will be on
short term advantage, not on negative consequences for those who must
maintain the mess later on (some project leaders may of course focus
also on that, but then, unless there is a long-term follow up policy in
place, it's /better/ that the next lead should fail, because that's then
one less person to compete with for a limited number of positions).
Sometimes it's a matter of knowledge as well, especially with startups.
Take my position...company was started out of a garage by
non-programmers who learned how. Original was written in basic in the
80's. Then it was translated to C, again by the same people, for
win16. Then it was translated again to win32 and yet again they
switched to C++ and started using OO.

Code that has been around for that long and been translated that many
times has a tendency to get a little unclean. It all works, but yes,
there is plenty of rot and places nobody wants to go because it is
almost impossible to maintain. Super long functions, monolithic
objects, the works...

I think the agile crowd has shown that TDD and such work, and work
well, so there isn't much need for such stuff to continue...but you
have to be able to deal with legacy code or you're just not worth your
salt. Even TDD with refactoring can get messy when a deadline is
comming up, or even when not and the design is just flawed. The cool
thing is though that refactoring works great to understand a piece of
software and you can slowly get the product under test as you add
features and change things.

Point is, it doesn't matter how it happens and it can happen in many
ways...but legacy code and code rot occur and you can't just start over
when it does. Not in a commercial product worth a fortune. You have
to continue working on it, adding features, while trying to keep it a
viable product. This necessitates a clean as you go kind of philosophy.

Nov 8 '06 #20

P: n/a
Noah Roberts wrote:
Michael Angelo Ravera wrote:

I've sent more than one interviewee away crying after exposing that
they made up their experience and knowledge. I've been known to ask the
interviewee about how he stands on the acetylsolosin QID controversy in
C++ or whether they have had any experience with Feci Tauri methods.

I would be one to answer these questions in detail. You better be an
expert too or I'll convince you they are real.
When they start to enumerate their vast experience with (or passing
exposure to) each of them, I know that I'm going to have fun in the
(usualy very short) interview. If at all possible, I will arrange to
get called away and leave the interviewee alone to stew for a while
while I go joke with the buddy of theirs who recommended them.

But, the joke would be on you because I would know what you where up to
and have decided I probably don't want to work for, or with, such
people.
When I come back, I usually try to discover their experience with NAFC
objects and thank them for coming in.

NAFC as in having to ask trick questions to discover someone's true
experience?

I actually have extensive experience with NAFC objects. NAFC managers
too.

Hopefully you don't really interview people this way. If you do maybe
your employer needs to see what else is in the management market
because that is NOT how to do an interview. I mean, it really is a
rather abrasive and confrontational way to talk to someone and you're
competing for my skills as much (or more possibly) as I am trying to
sell them.
I only interview people this way when they start off as liars and self
indulgent ones at that. People who come in saying "I heard that you are
looking for a snot nosed kid who can program in c++. Well, here I am!"
have the job unless I get overruled by someone else.

Nov 8 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.