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.

What questions would ask a candidate with mainly Java/.NET experience (10 years+) in an interview for a C++ position?

share|improve this 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 Harding Dec 29 '10 at 8:59
    
Yes, over the year they have had some C++ here and there. –  egil Dec 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.

share|improve this answer
1  
I think boost will be a bad idea, considering the Java background. –  Geek Dec 29 '10 at 7:47
    
+1 for thinking algorithmically. Languages can be picked up in short order. –  David Dec 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 Thornley Dec 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. –  David Dec 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.

share|improve this answer

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

share|improve this answer
    
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 Thornley Dec 29 '10 at 16:21

Proper use of pointers and references:

  • Pointers are variables that hold an address to a block of memory that is equal in size to the type of the pointer.

    int * test = new int(5);    // on 32-bit OSs, test would be 4 bytes
    *test      = 6;             // access the value (dereferencing)
    delete test;                // free the memory
    
  • References are pointers that cannot be modified - instead, any operations performed on them affect the memory pointed to.

    int target = 1;             // target now holds a value of 1
    int& ref   = target;        // ref points to target
    ref        = 2;             // modifications to ref modify target
                                // notice that we do not dereference ref
    
share|improve this answer
    
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. –  Steve314 Dec 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. –  Steve314 Dec 31 '10 at 9:47

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.