Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
show 1 more comment

migrated from stackoverflow.com Sep 1 '11 at 10:26

This question came from our site for professional and enthusiast programmers.

20 Answers

up vote 33 down vote accepted

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
share|improve this answer
9  
The ability to write a function template to implement a generic algorithm. Otherwise you're hiring a C-with-classes programmer ;-p –  Steve Jessop Dec 7 '08 at 19:54
1  
And on the same basis some would say TMP, but not me yet, because I'm deeply suspicious of accidental technology. Maybe when the Boost TMP stuff has been in the standard for a few years... –  Steve Jessop Dec 7 '08 at 20:10
4  
Please don't get me started on templates ;-) Every C++ programmer should know how to USE them and what happens when you do (hence STL above), but nobody should be forced to write the damn things. Writing a MIN template that's actually better than #define is still a job for Alexandrescu... –  Roddy Dec 7 '08 at 20:11
1  
Well, the definition of min in GCC's bits/stl_algobase.h is, aside from naming everything with underscores and a type requirement, "template<typename T> inline const T&min(const T &a, const T &b) {if (b < a) return b; return a;}". Not beyond mortal ability, I think ;-) –  Steve Jessop Dec 7 '08 at 23:08
4  
I think that DDJ article is having a laugh: "The gist of providing a good min/max implementation is to obtain something that behaves much like the macros". No, because we don't like the way the macro behaves. To coerce return type or resolve ambiguity, do min<int>(a,b), and move on... –  Steve Jessop Dec 8 '08 at 1:08
show 3 more comments

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.

share|improve this answer
6  
I liked your point "Focus less on C++ trivia and more on how hungry he is and how quickly he can apply new concepts." When I started with c++, what I had more was hunger than concepts. –  AKN Apr 22 '10 at 10:46
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
7  
I disagree. It depends on the situation. Sometimes you need a person fluent in a particular language to start working immediately. You cannot always afford the time it would take somebody to learn a new language. –  Dima Dec 7 '08 at 18:49
4  
For most languages, I'd agree. Unfortunately, C++ is not something you "just learn". I'd be extremely worried about letting someone near a C++ codebase if they have not demonstrated that they know the tricky aspects of writing robust C++ code. –  jalf Dec 7 '08 at 18:49
2  
Programming in C++ is fundamentally different than programming in garbage collected languages, though. If all the work the candidate will be doing is in C++, then I think it's totally appropriate to ask C++ questions in the interview. –  Bill the Lizard Dec 7 '08 at 18:49
2  
@jalf,BillTheLizard: I agree 100% - with C, you're on a highwire with no safety net - and you know it. But C++ contrives to give you a false warm fuzzy feeling despite the fact you're juggling five AK47s with no safety catches and hair triggers which are somehow ALWAYS pointing at your feet... –  Roddy Dec 7 '08 at 18:55
show 4 more comments

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

share|improve this answer
add comment

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.

share|improve this answer
2  
"i.e." = "id est" = "that is". You most likely mean "e.g." = "exempli gratia" = "for example". –  Svante Dec 7 '08 at 20:55
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
BTW, if your going to make them actually program, how about letting them use a computer & compiler rather than the white board. When white boarding, I frequently do things like leave off semicolons after class declarations, etc., that I don't do while typing thanks to muscle memory. –  ceretullis Dec 7 '08 at 19:53
1  
And if you let them use a computer, you get to see whether they compile with -Wall :-) –  Steve Jessop Dec 10 '08 at 1:56
add comment

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

share|improve this answer
add comment

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).

share|improve this answer
add comment

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 = data[3][2] ;
share|improve this answer
add comment

I've found myself dividing C++ interview questions into certain categories. Of these, many interviewers only touch on fundamentals and details. Junior candidates like those this question asks about can only be expected to know some of this, but you definitely want to see that they've attacked it with some enthusiasm.

It's hard to find people who've made a systematic, broad investigation of the how-tos of C++ programming at the low-level library level (where the most ingenuity is generally required), and equally hard to find people who know what to do in terms of large-scale design and architecture trade-offs. Very roughly - just to illustrate these factors - I've compiled some examples:

  • FUNDAMENTALS: basic knowledge you must have to use the language
    • the what, how, why of class, object, pointers, functions, headers, templates, virtual functions, const & mutable, stack/heap, static...
  • DETAILS: the stuff that's normally just below the surface but occasionally gives rise to questions (the kind of stuff needing an answer from the C++ FAQ lite)
    • what're the performance/memory implications of inlining, of virtual dispatch...
    • throwing from destructors
    • Liskov Substitution Principal
    • RAII
  • HOW TO: generic practical programming tasks that even good programmers might not be able to do fully off the top of their heads, but should be able to be helped through with minimal pain - sorts the reusers of canned solutions from those who understand the implementation issues, e.g.
    • variants
    • functors
    • SFINAE tests for member functions
    • hash table or binary tree
    • thread pools
    • simple design patterns: visitor, observer, pub/sub, factories etc.
    • how do you debug certain types of issues: race conditions, deadlocks
    • multiple processes want shared in-place access to objects in shared memory: how can you provide runtime polymorphism (virtual dispatch) for the objects
    • design a non-templated function f(X&) and template <class A, class B> struct T such that f can accept any object of type T and handle them via virtual dispatch
  • WHAT TO: stuff that requires practical insight/experience: for example...
    • contrast the utility of templates and virtual dispatch
    • discuss approaches to serialisation/deserialisation in C++
    • compare Design By Contract with Defensive Programming
    • discuss physical dependencies (changes triggering/needing recompilation)
    • contrast factors in / approaches to testability: e.g. templatised code, abstract interfaces, derivation versus composition, #ifdefs
share|improve this answer
add comment

I always ask the difference between new/delete and free/malloc. I also ask how the templates work.

share|improve this answer
add comment

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.

share|improve this answer
1  
Unfortunately it doesn't separate people who know C from those who know C++. And hiring for a C++ seat, that's critical. –  Roddy Dec 7 '08 at 18:58
show 1 more comment

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.

share|improve this answer
show 3 more comments

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)

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
1  
@Uri - I would provide a class with several well-known nontrivial members (string/vector/map) and one constructor. Ask the candidate to enumerate all possible code paths when constructing, including which sub-constructions/destructions –  Tom Dec 7 '08 at 21:19
show 2 more comments

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++).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.