There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

Do they have any experience with C++ at all? How much do you expect them to know vs. how much they'll have to pick up?
–
Dean HardingDec 29 '10 at 8:59

Yes, over the year they have had some C++ here and there.
–
egilDec 29 '10 at 9:47

4 Answers
4

First, make sure that they can think algorithmically, regardless of programming language. Then, make them solve some simple problem in C++ code on the whiteboard. Then, ask about the distinguishing features of C++ that you actually use in your project. Possible topics are memory management, RAII, templates, references, operator overloading. Maybe boost and metaprogramming, if you use it. OO-style programming is similar in C++ and Java/.NET (class-based, single-dispatch), except that it also supports multiple inheritance and virtual inheritance. Understanding what constitutes implementation-defined, unspecified and undefined behavior is also a plus.

I think boost will be a bad idea, considering the Java background.
–
GeekDec 29 '10 at 7:47

+1 for thinking algorithmically. Languages can be picked up in short order.
–
DavidDec 29 '10 at 17:23

@David: Language syntax can be picked up in short order. Concepts take longer. C++-style resource management is likely to take longer to understand than how to write a C++ class.
–
David ThornleyDec 29 '10 at 18:49

@Thornley: IMO (and I'm interested in hearing your opinion, should it differ), if someone understands how the JVM does memory management, then learning about destructors isn't going to be a huge leap (conceptually speaking). I understand that there is a difference in terms of what the programmer has to write, but if one knows how the JVM reclaims memory, then learning the C++ way is not a world apart.
–
DavidDec 29 '10 at 19:25

The main issue that I have seen with programmers from .Net and Java that use C++ is memory management. They have a big tendency to always allocate objects on the heap instead of using stack, so watch for this.

Any developer starting a new job needs to learn the idioms used in that project and team. Learning the idioms of the particular implementation language is just an aspect of that, really - an extra learning curve issue, but for C++ relative to C# or Java, probably not that big a deal. The exception may be where there are strong religious views that the person may not be willing to drop as a point of principle.

The non-garbage-collected nature of C++ is an obvious area for religious issues. I might worry about someone who strongly asserts that all non-GC software is buggy without acknowledging that that using GC can lead to different resource-management complications and bugs rather than complete upside-only elimination of a whole class of problems. A true extremist in that position may reject C++ resource management idioms pretty much out of hand, insisting that the resulting issues are inevitable anyway and that any working C++ code produced by others is a result of bizarre superhuman intelligence or fluke. A view that GC is generally a better approach wouldn't necessarily worry me, so long as there is flexibility and a willingness to adopt idioms appropriate to C++.

A question to reveal that viewpoint? Without giving a misleading impression of people who currently have mostly GC-specific experience, but would quickly adapt? I doubt I can come up with one, and I think the real issue would be with people who's bias is apparent throughout, and irrespective of the particular question, anyway. That's assuming you can reliably detect the issue in an interview situation at all, assuming the applicant knows the role involves C++.

Asking questions about heap vs. stack, and smart pointers, should help here. Also, ask something about RAII. I agree that you're looking for willingness to think in C++ terms here.
–
David ThornleyDec 29 '10 at 16:21

A reference can be modified. It's usually unlikely to occur by mistake, but it can be done. It can even be done accidentally, usually as a result of passing as a parameter in a different form (e.g. use & and pass the pointer as reference-to-pointer) without considering the consequences or what will be done with that parameter.
–
Steve314Dec 31 '10 at 9:41

Understanding references as supporting different idioms to pointers is important, though. Most will recognise the convenient pass-by-reference kind-of-like-a-Pascal-var-parameter usage, but fewer will immediately recognise the use for local alias variables. Even so, I think this is mostly covered in learning the idioms of a new but not-that-hugely-different language, and not a deal for someone who lacks the specific experience but is willing to learn.
–
Steve314Dec 31 '10 at 9:47