companies' tests for c++ developers

[Giff]

Hi,

soon I will finish the university and start looking for jobs, I know
that the companies often send you some questions by email before the
personal interview, to check if the candidate actually knows the
language (c++)

can anyone of you suggest what to revise in order to be better prepared
for these questions?

of course the main thing is programming experience, but maybe there is
some kind of pattern for these tests and some things are considered more
important than others...

thanks a lot for any suggestion

[Victor Bazarov]

Giff wrote:

soon I will finish the university and start looking for jobs, I know
that the companies often send you some questions by email before the
personal interview, to check if the candidate actually knows the
language (c++)

can anyone of you suggest what to revise in order to be better
prepared for these questions?

Your textbook[s] and your course notes.

of course the main thing is programming experience, but maybe there is
some kind of pattern for these tests and some things are considered
more important than others...

The things that are more important: you need to know the basics [well]
and you need to be able to solve problems. Answering those alleged
questionaires will probably get your foot in the door, but if you only
succeed in that, what is exactly the point? If you're a good candidate
for the position, you will be able to answer the questions. If you're
not, answering those questions is a waste of time (yours and those who
are hiring).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[giff]

Victor Bazarov ha scritto:

Your textbook[s] and your course notes.

of course ;)

The things that are more important: you need to know the basics [well]
and you need to be able to solve problems.

yes, but what are the "basics"? is there any pattern in the kind of
problems they are more likely to ask?

If you're a good candidate

for the position, you will be able to answer the questions. If you're
not, answering those questions is a waste of time (yours and those who
are hiring).

this makes sense, but I suppose they can ask things that I didn't need
so far in my programming (only academical)

thanks for answering
--
there are no numbers in my email address

[Earl Purple]

Giff wrote:

Hi,

soon I will finish the university and start looking for jobs, I know
that the companies often send you some questions by email before the
personal interview, to check if the candidate actually knows the
language (c++)

I have found it is more common to get a telephone interview first but
then I am not fresh from university.

The questions are typically like: what functions are automatically
provided. Difference between a pointer and a reference. Sometimes some
questions on STL. Of course I never have any problems answering these
but obviously they eliminate many.

Being able to answer all of these doesn't make you a good programmer. A
lot depends on requirements. The requirements for writing a boost
library are a lot stricter on the standards of C++ where near
perfection is important, whereas in a work situation, you don't always
have time to write the perfect code and have tight schedules to meet.

can anyone of you suggest what to revise in order to be better prepared
for these questions?

You should know the language. Maybe revise on the standard library
algorithms. Not sure you'll be tested on them but it's useful to know
what's available.

of course the main thing is programming experience, but maybe there is
some kind of pattern for these tests and some things are considered more
important than others...

If I wre giving the interviews I'd present GOTW-style tests but it is
rare to see that. Perhaps I apply for the wrong companies.

[Victor Bazarov]

giff wrote:

Victor Bazarov ha scritto:

>The things that are more important: you need to know the basics
[well] and you need to be able to solve problems.

yes, but what are the "basics"?

What is the difference between a class and a struct? What's a class?
What's overloading? I am not sure, I've not interviewed fresh-out-of-
college folk recently.

is there any pattern in the kind of
problems they are more likely to ask?

Take "Effective C++" and "More Effective C++" by Meyers. Those are
one level beyond basics, but they presume the knowledge of basics.
If you can understand them, you know basics.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[giff]

Victor Bazarov ha scritto:

Take "Effective C++" and "More Effective C++" by Meyers. Those are
one level beyond basics, but they presume the knowledge of basics.
If you can understand them, you know basics.

The books I have are "Thinking in C++" by Eckel and "The C++ Programming
Language" by Stroustrup.

I do understand them but of course don't remember all that is written in
them ;)

thanks
--
there are no numbers in my email address

[giff]

Earl Purple

>
I have found it is more common to get a telephone interview first but
then I am not fresh from university.

thanks for your reply
--
there are no numbers in my email address

[Victor Bazarov]

giff wrote:

Victor Bazarov ha scritto:

>Take "Effective C++" and "More Effective C++" by Meyers. Those are
one level beyond basics, but they presume the knowledge of basics.
If you can understand them, you know basics.

The books I have are "Thinking in C++" by Eckel and "The C++
Programming Language" by Stroustrup.

I do understand them but of course don't remember all that is written
in them ;)

That's different. I am talking about using some indirect way to test
how much basic stuff you understand. Take "Advanced C++" for example.
Right in the name you have a hint that it's not basic. That means if
you understand it, you have a decent grasp of the basic stuff.

Take my word for it, if you want to have a career in programming and
would like to begin it with C++, the two books I mentioned first are
not going to hurt you. Get them. First you'll see if you got a good
grasp of the basics, and then you will learn more C++ from them.

"Advanced C++: Programming Styles and Idioms" by J.Coplien is a bit
old, but I still think it's a very good reading. If you can find one
used, don't pass it up.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Noah Roberts]

Giff wrote:

Hi,

soon I will finish the university and start looking for jobs, I know
that the companies often send you some questions by email before the
personal interview, to check if the candidate actually knows the
language (c++)

can anyone of you suggest what to revise in order to be better prepared
for these questions?

of course the main thing is programming experience, but maybe there is
some kind of pattern for these tests and some things are considered more
important than others...

thanks a lot for any suggestion

I recently created an interview "project" - we sent the same problem
out to the different prospects to solve to see what we would get back.
Those that we liked got a phone interview. The task boiled down to
wanting to know if the interviewee could adapt legacy code and alter
features while also cleaning up a class obviously written by someone
primitive obsessed or originally written in C. In the end we wanted to
see that they could adapt a class to be safer and cleaner by use of STL
or custom datatypes with minimal impact on clients. We wanted to see
knowledge of the language of course but more importantly creativity and
ability to deal with and understand existing code.

Every place will be different. I don't much dig on interviews where
they run through a list of language features and ask what they do.
First off, knowledge of any particular language is not important. What
is more important is whether the person can program and has the type of
problem solving skills necissary to write good code; I'm of the belief
that you are either a programmer or you are not - there is a certain
type of thinking that seems to be necissary to the task and not
everyone thinks that way. I personally also want to know that they
enjoy the art of programming and that they study and hone their skills
at home.

[Phlip]

Noah Roberts wrote:

I recently created an interview "project" - we sent the same problem
out to the different prospects to solve to see what we would get back.
Those that we liked got a phone interview. The task boiled down to
wanting to know if the interviewee could adapt legacy code and alter
features while also cleaning up a class obviously written by someone
primitive obsessed or originally written in C. In the end we wanted to
see that they could adapt a class to be safer and cleaner by use of STL
or custom datatypes with minimal impact on clients. We wanted to see
knowledge of the language of course but more importantly creativity and
ability to deal with and understand existing code.

So what was the hard part?

;-)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Phlip wrote:

Noah Roberts wrote:

I recently created an interview "project" - we sent the same problem
out to the different prospects to solve to see what we would get back.
Those that we liked got a phone interview. The task boiled down to
wanting to know if the interviewee could adapt legacy code and alter
features while also cleaning up a class obviously written by someone
primitive obsessed or originally written in C. In the end we wanted to
see that they could adapt a class to be safer and cleaner by use of STL
or custom datatypes with minimal impact on clients. We wanted to see
knowledge of the language of course but more importantly creativity and
ability to deal with and understand existing code.

So what was the hard part?

I don't know that there was one. I suppose the "legacy" part. We
threw in some uglyness to see what they would do with it.

[Frederick Gotham]

Fat Ass Fred posted:

int a=0[5];
in C... Things that make the average programmer say "What????"

Actually, my own thought process were:

Well... that's equivalent to:

*(0 + 5)

which is equivalent to:

*5

which led to, "You can't dereference an int.".

--

Frederick Gotham