C++ areas you look for during interview

Question

If you are taking an interview of an candidate without any prior work experience and want to find out how good he/she is in C++ what are the areas you generally look for ?

Answer 1

Definitely a question about copy constructors... if they get that, you can be pretty confident they know something about C++

Answer 2

Also, it goes without saying that, regardless of the language, they should write some actual code for you.

Answer 3

I'd probably look into these areas:-

• Constructors and Destructors (incl. copy constructors!)
• RAII
• Exceptions
• Assignment operator
• New/Delete/New[]/Delete[] vs malloc/free
• STL containers
• Smart Pointers : why, how and when

Answer 4

I always ask the diff of new/delete and free/malloc. Also how the templates work.

Answer 5

Personally, I believe that the most important questions involve dynamic binding and typing. Questions such as "what will be invoked in situation X" can really help identify potential employees who will potentially use inheritance well, and those that passed their CS courses with enhanced C skills without truly understanding OOP. I think that the focus on operator overloading and minor differences from C doesn't identify good developers.

Also, While I haven't interviewed anyone, a common pattern that I have seen in good organizations is a trick question where you are given code that passes parameters by value where they should obviously be passed by reference, to see if you catch it.

Answer 6

I wouldn't ask any language specific questions. A language is just a tool a qualified candidate can learn to use pretty fast.

Problem solving skills and how a candidate adapts to new situations/tools/requirements is much more important.

Answer 7

I'm copy-pasting what I've said in the past:

I'm not very fond of too precise and syntax oriented questions.

I'd rather have someone that understands major principles like semantics, LSP, RAII, the most widely used patterns, ... than someone that knows the syntax of custom pre- and post-increment operators, how new/delete operators are overidden, or whatever stuff we never do more than once every 2 years.

I guess I would ask to complete a poorly designed set of classes (of course I'll never say the class are poorly designed) to implement whatever algorithm.

If he immediatelly points out the design flaws and explains what should have been done, I'll be quite happy. Otherwise, any newcomer in C++ world should be able to implement what has been asked without feeling down or disturbed by very complex and jargon-oriented questions he is not able to answer. (C++ has a very precise jargon, and many details are more easily explained when we are fluent in its jargon).

Regarding the design flaws, I'll try to hide things like : - more than two raw ressources in a class, - provide copy-semantics on an entity-semantics oriented class (typically within a hierarchy of polymorphic classes), - use public inheritance for anything but LSP, - ...

=> have something that looks simple, and that permits to test newcomers as well as experimented C++ developpers.

Regarding development, there are many other things to check. As it has been said: a talented developper may have not been initiated to C++ intricacies.

If the person is reconverting from a language to C++, he should at least be able to point out the syntaxic and idiomatic differences between the two languages, and to write down algorithms in a semi-C++/semi-natural dialect.

Answer 8

Ask something about exceptions in constructors, nobody knows this well.

Answer 9

If the candidate has no prior work experience, you can be sure that there will be a lot of learning in the first year.

Focus less on C++ trivia and more on how hungry he is and how quickly he can apply new concepts.

Find a topic he's not familiar with...vtables or some boost object or design pattern and give him an explanation. Then see if he can make use of that concept in front of you. This will tell you far more about how an effective an employee he will be.

Answer 10

I'd ask them to solve some simple programming problems using C++, that shows whether or not they can actually program, and if they are actually familiar with C++.

Get them do do something, talk is cheap.

Answer 11

I would ask a simple question involving pointers. Amazingly enough that very quickly separates people who do know C++ from those who only say they do.

Answer 12

I would start with rudimentary questions about pointers and memory. Try to figure out if they know the difference between pointers and a references. Then go on with constructors, destructors, inheritance, exceptions, const, well the basics.

After that I'd ask something on common design patterns, such as RAII, visitor pattern, factory pattern, adapter pattern, and so on.

Probably I'd go for a small programming exercise.

Answer 13

LET THEM WRITE CODE

Besides discussing the things Roddy has listed, make sure you see hwo they tackle an actual function to write. The point is not a pass/fail for the one correct solution, but watching the candidate as he develops the code. Thinking ahead, asking for clarification, style, handling error coditions etc.

If you are an inexperienced interviewer, this helps a lot to convince you that "maybe's" are actually "no hire's" - at least when the "surprises" I've seen are standard fare. (see also Joels guide V.3 on maybe ==> no)

---

Technically: Have two or three simple problems ready, that you understand well, and can be solved in about ten to twenty "normal" lines of code, but has a few conditions to check against. (For C++, some String processing is a good idea). One task is usually enough, have a second one ready in case the candidate totally fails or excels at the first,: in both cases, you didn't have a chance to watch the process.

Put it towards the second half of the interview, encourage the candidate and try to put him at easy (if that's even possible during an interview).

Answer 14

I'd say that, when you generally hire a programmer you should never look for "how much does this person know at the moment". You should rather look for "how much can this person grow".

There are many programmers that are skilled at i.e. c++ but they do lack a lot of ther aspects, such as taking in newer perspectives and it's one of the, imo, most important thing when hireing someone.

If the person likes programming, have easy to learn and able to communicate programming on a professional basis, then it doesnt matter if they know everything.

However, when looking for a Programmer i always assume they know OOP and how to adapt it.

Answer 15

If they are new grads, you might want to see if they learned what they were supposed to in school - as this is probably a good indicator of what kind of employee they will be - i.e. hungry/passionate, etc.

You might break out some fundamental computer science questions and see how they handle those before moving into language specific questions (which I think are very necessary with C++).

Answer 16

1) Ask them, that when they don't know the answer to a problem, where they would look for the answer.

2) How to design programs that can easily be tested (e.g. unit tests, test-driven development)

Answer 17

Give his a simple agile story to implement in C++. This is what I do at my company. The guy gets a simple (fake)interface to the db he/she has to implement, few unit tests that document the (initial)requirements and that's it. Tell the applicant that for this interview we are all one team, this will encourage him to ask question. Asking questions is important so you need to check this out. After he/she completes the task, change some requirement to see if the code scales or it's a legacy code already...

During this kind of story you can check:

• basic and advanced C++
• use of STL
• use of Boost
• use of design patterns
• familiarity with interfaces
• familiarity with design principles
• unit testing and writing testable code

I give a guy a laptop with prepared project in VS 2008 Express and I have an extra monitor set to close to actually see what the guy is doing and give tips, ask question etc. I did this style of interview over 10x and it's great.

Remember: THEY HAVE TO WRITE CODE DURING INTERVIEW. PERIOD.

Answer 18

It really depends on what you are looking for. The skill set for application programmers are much less demanding than that for library and framework writer.

For application programmers: RAII (vs new/new[]/delete/delete[] vs malloc/free), standard library (STL/boost) usage, exception handling etc., besides generic algorithm/problem solving.

For library/framework creator/maintainers: in addition to above areas, virtual inheritance in multiple inheritance (most other popular languages do not have MI) and construction order; copy constructor and assignment (gotchas), destructor (why it should be virtual for any polymorphic classes), the concept of iterator and how it enables generic algorithms, template (concept of partial specialization, metaprogramming, let's face it, template is what gives performance and expressiveness to modern C++ libraries.)

It's much harder to find a competent library/framework programmer than a application programmer.

Answer 19

http://discuss.joelonsoftware.com/default.asp?joel.3.414500.47

Answer 20

To understand their knowledge of memory allocation and layout, ask them how to dynamically allocate memory for 2 dimensional array.

int **data = null ;
// write code to dynamically allocate and initialize memory for 2 dimension array of size 10X15
....
....
// Now use the 2 dimension array
int a = datat[3][2] ;