24

I have to interview some C++ candidates over the next few weeks and as the most senior programmer in the company I'm expected to try and figure out whether these people know what they are doing.

So has anybody got any suggestions?

Personally I hate being left in a room to fill out some C++ questions so I'd rather do a more complex test that I can chat with the interviewee about their approaches and so forth as we go along. ie it doesn't matter whether they get the right answers or not its how they approach the problem that interests me. I don't care whether they understand obscure features of the language but I do care that they have a good solid understanding of pointers as well as understanding the under lying differences between pointers and references. I would also love to see how they approach optimisation of a given problem because solid fast code is a must, in my opinion.

So any suggestions along these lines would be greatly appreciated!

eeerahul
  • 1,629
  • 4
  • 27
  • 38
Goz
  • 61,365
  • 24
  • 124
  • 204
  • 5
    Take a look at this question also: http://stackoverflow.com/questions/347793/c-areas-you-look-for-during-interview – Naveen Sep 09 '09 at 09:09
  • Give them a task that would be common for a junior at your company to have to sole. Give them a week to submit a solution then do a code review with them and a few of your peers. – Jesper Juhl Apr 17 '23 at 14:07

16 Answers16

23

I wouldn't make them write code. Instead, I'd give them a couple of code snippets to review.

For example, the first would be about design by contract: See if they know what preconditions, postconditions and invariants are. Do a couple of small mistakes, such as never initializing an integer field but asserting that it is >= 0 in the invariant, and see if they spot them.

The second would be to give them bool contains(char * inString, char c). Implement it with a trivial loop. Then ask whether there are any mistakes. Of course, your code here does not check for null in the input parameter inString (even if the very previous question talked about preconditions!). Also, the loop finishes at character 0. Of course, the candidate should spot the possible problems and insist on using std::string instead of this char * crap. It's important because if they do complain, you'll know that they won't add their own char *'s to new code.

An alternative which addresses containers: give them a std::vector<int> and code which searches for prime numbers or counts the odd numbers or something. Make some small mistake. See if they find any issues and they understand the code. Ask in which situation a std::set would be better (when you are going to search elements quite systematically and original order of entrance doesn't matter.).

Discuss everything live, letting them think a couple minutes. Capture the essence of what they say. Don't focus on "coverage" (how many things they spot) because some people may be stressed. Listen to what they actually say, and see if it makes any sense.

I disagree with writing code in interviews. I'd never ask anyone to write code. I know my handwritten code would probably suck in a situation like that. Actually, I have seldom been asked to do so, but when I have, I haven't been hired.

Daniel Daranas
  • 22,454
  • 9
  • 63
  • 116
  • I DO fully agree on the not writing code. I was more thinking about providing them with a question and asking how they would approach the problem. Good idea to do a "find the f**k ups" in a block of code though! Knowing my luck, though, they'd spot a mistake i hadn't noticed ... I've done that before ;) – Goz Sep 09 '09 at 09:31
  • @Goz I think a question about approaching a problem would be good, too. – Daniel Daranas Sep 09 '09 at 09:38
  • 7
    I don't know that making sure they prefer std::string over "char *" is really helpful in assessing the general abilities of a programmer, regardless of their experience with C++. I like the suggestions about having them look for coding mistakes, though. – reuben Sep 10 '09 at 01:57
  • 1
    The sample is pretty good, I guess a programmer saying char * should be replaced by string or we should check for NULL pointer. It will be too harsh to ask buried mistakes and write a code at the first interview. Most applicants will be exited and they will jump to code right away, without thinking on the subject, resulting a very crappy code. – Cem Kalyoncu Sep 16 '09 at 11:12
  • I can't relate to not wanting to write code in an interview. I would much rather write code (give me a computer with a reasonably easy setup or tell me to bring my own laptop which is setup to compile/run c++ however I like to develop) than anything else. Plus I think it's far more telling to see someone actually write code. For a programmer, actually programming something is the best test of their ability – David Dec 16 '15 at 20:18
  • @David I can hear what you're saying. My answer is from six years ago. Now, I think slightly differently. I think I'd try to create the conditions for the candidate to actually write some code. I might edit my answer later, or just keep it as it is for historical reasons :-) – Daniel Daranas Dec 16 '15 at 21:02
14

This one is a great complex task, even though it is looking quite harmless.

The task is

Write a Named Point class with three members: two floating point values for the coordinates on an X-Y plane, and a name represented as a 'char *'. Assume that this class will be used for some sort of wargame or simulation program that treats the world as flat and that these named points will be used to represent things like cities, battlefields, etc.

then evaluate the person's ability to debug based on feedback, due to the language having non-obvious pitfalls.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
h0b0
  • 1,802
  • 1
  • 25
  • 44
  • Fantastic read and definitely makes a valid point on C++ and large projects. – jim Sep 09 '09 at 13:13
  • 9
    I can't be the only one who, on being posed that question, would ask the interviewer "can I use a std::string internally, and only expose the name as a const char* via an accessor?" Resulting source is about the size of the initial wrong answer, and unlikely to be very much less efficient than the answer he finally settles for. – Steve Jessop Sep 09 '09 at 16:00
  • 2
    It is actually rather surprising that people claiming 3 years of C++ experience would have problems with that. Anyone ever got to copy-and-swap idiom for assignment (got to the place where you might want to start considering stronger exception guarantees)? :) – UncleBens Sep 09 '09 at 17:50
  • 1
    The correct response for a C++ programmer is to point out that representing the name as "char *" is dumb. If you insist on it, the correct response is to ask if you micromanage everything. The problem is that you will lose out on good C++ programmers who aren't assertive in interviews. – David Thornley Sep 09 '09 at 17:55
  • 1
    I'm not sure what the relevance of this is. The question was not "is C++ a good language for large projects", but about interviewing candidates for a C++ position. – jalf Sep 09 '09 at 18:45
  • @UncleBens: That particular article is from 2001. I don't remember when people got the hang of exception safety in C++ (I think it was very roughly then), but not a whole lot of people knew how to handle exceptions back then. Nowadays I'd like C++ people to have a clue about exception guarantees, but at that time it would have been unusual. – David Thornley Sep 09 '09 at 18:54
  • @jalf: most of that linked article actually is not directly to do with its title, and is a (perhaps stereotyped) account of a "typical" interview programming task. The point of the article is that almost everyone fails to produce competent code (and, hence, in the author's opinion, C++ is "too hard"). Since the question is about how to test who can competently write C++, it seems relevant to me :-) – Steve Jessop Sep 09 '09 at 20:06
7

I believe that a C++ programmer needs more than just generic programming skills, because...

In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.

Writing bug-free, maintainable C++ code places a much higher demand on a few areas than most languages.

One thing I'll call "pedanticness". You know how some people can spot spelling errors in something at a glance? A C++ programmer needs to be able to spot simple bugs while they read or write code (whether the code is their own or not). A programmer who relies on the "compile and test" technique just to get rid of simple bugs is incompatible with the C++ language, because those bugs don't always lead to immediate failure in C++.

C++ programmers also need a good knowledge of low-level stuff. Pointers, memory allocators, blocking, deadlocks. And "nitty gritty" C++ issues, like multiple inheritance and method hiding and such, particularly if they need to maintain other people's code.

Finally, C++ programmers need to be able to write code that's easy for other people to use. Can they design stuff well?

A good test for the first two areas is "Here's some C++ code I got off the internet. Find the bugs, and identify the unneccessary bits." (There's lots of really bad C++ code available on the internet, and often the programmer does unnecessary things due to a faulty understanding of how to be "safe" in C++.)

The last area you can test with more generic interview questions.

Artelius
  • 48,337
  • 13
  • 89
  • 105
  • The first paragraph is not a bad point. You probably don't want someone who assumes "if it compiles, it's correct" (or even "if it runs, it's correct") – jalf Sep 09 '09 at 10:29
  • Indeed, good debugging skills are incredibly useful but nothing like as useful as not writing the bugs in the first place. – Goz Sep 09 '09 at 10:39
  • 2
    What I had in mind was more about people who *know* that code which appears to run may have logic bugs, but nonetheless rely on testing to remove all the "implementation" bugs. That is, the bugs that arise because the code you write doesn't reflect your mental model of the program. Like accidentally using the wrong variable name. (Unlike the bugs that arise because your mental model is itself broken.) – Artelius Sep 09 '09 at 11:12
7

A few questions can allow you to know a lot about a candidate:

  • Differences between a pointer and a reference, when would you use each?
  • Why would you make a destructor virtual?
  • Where is the construction order of a class attributes defined?
  • Copy constructor and operator=. When would you implement them? When would you make them private?
  • When would you use smart pointers? what things would you take into account to decide which?
  • Where else have you seen RAII idiom?
  • When would you make a parameter const? when a method?
  • When would you make an attribute mutable?
  • What is virtual inheritance?
  • What is template specialization?
  • What are traits?
  • What are policies?
  • What is SFINAE?
  • What do you know about C++Ox standard?
  • What boost libraries have you used?
  • What C++ books have you read? (Sutter? Alexandrescu?)

Some short exercises (no more than 10 minutes) about STL containers, memory management, slicing, etc. would also be useful. I would allow him to do it in a computer with a ready environment. It's important to observe the agility.

Fernando N.
  • 6,369
  • 4
  • 27
  • 30
  • 9
    Sry I might be a little harsh, but are you trying to interview a scholar or a programmer. Info that should be covered in a book does not worth asking. Programming is about skill, experience and their approach on problems not just knowledge. A person accepted through your questions might still write bad code. – Cem Kalyoncu Sep 16 '09 at 11:21
  • 2
    Most of the C++ developers out there have over 3 years of experience and won't be able to answer those questions properly, even some of the basic ones. This is a good way to know how if the candidate is a proactive person reading good books and with clear ideas or just a person doing a work he don't like. Of course their skills are important, read the last paragraph of my answer. – Fernando N. Sep 17 '09 at 19:36
  • 1
    I'd be careful about questions like these. In my work, we have some language "groupies" - They have read the standard cover to cover several times, follow the proceedings of C++0x committee, etc., etc. They're not that great programmers - to them, programming isn't so much about solving customer problems but instead an effort to create perfect C++ programs. They view working, stable, legacy code that doesn't use exceptions as an abomination that must be fixed, even though expending that effort on code that is in maintance-mode would have zero customer benefit. – Michael Sep 22 '09 at 20:19
  • My above comment refers to some of the more specialized questions you asked (i.e., what is SFINAE) that do not come up in day-to-day C++ development. – Michael Sep 22 '09 at 20:23
  • This questions are not a panacea. Are just a bunch of short questions with a incremental difficulty level to make yourself an idea about the candidate c++ knowledge. Client orientation and many other important features for a candidate are not covered because are not the question subject. – Fernando N. Sep 23 '09 at 21:29
  • Slicing. No matter how many times I read that chapter about slicing in Sutters/Alexandrescu's book I forgot it within 15 minutes. Perhaps I'll read up on it again. – C.J. May 16 '13 at 17:48
6

Checkout Joel's Guerrilla guide to interviewing. Seems a lot like what you are looking for.

kripto_ash
  • 919
  • 7
  • 14
5

"Write a program that receives 3 integers in the range of 0..2^32-1, and validates if they represent valid edges of a triangle".

It seems to be a simple question. The input is considered valid if the sum of any two edges is greater than the third edge. However, there are some pitfalls, that a good programmer will handle:

  • The correct type to use should be unsigned long. Many "programmers" will fail here.
  • Zero values should be considered as non-valid.
  • Overflow should be avoided: "if (a+b <= c) return false" is problematic since a+b may cause an overflow.
  • if (a <= c-b) is also bad solution since c-b may be negative. Not a good thing for unsigned types.
  • if (c > b) { if (a <= c-b) return false; } else { if (a <= b-c) return false; } This looks much better, but it will not work correctly if (a >= b+c).

A good programmer must be detail oriented. This simple exercise will help checking if he is.

Sergii Fedkiv
  • 3
  • 3
Lior Kogan
  • 19,919
  • 6
  • 53
  • 85
  • @SergiiFedkiv: I don't like your edit. Note that I'm showing only one of three symmetric tests that should be carried out. One should also check if (a>b) ... and if (a>c) ...which will cover all cases. – Lior Kogan Nov 12 '16 at 05:44
4

Depending on what your organisation's pre-screening is like, assume that the person knows nothing at all about C++ and has just put in on their CV because it makes them look supertechnical. Seriously. Start with something simple, like reversing a string. I have had candidates who couldn't even write a function prototype for this !!

tragomaskhalos
  • 2,733
  • 2
  • 17
  • 10
  • 1
    And you can instantly see if they're good if they can do it in-place ;) – Goz Sep 09 '09 at 10:40
  • 1
    Nowadays it is quite hard problem as the string is always encoded in UTF-8 :) – vava Sep 09 '09 at 11:36
  • Reversing a UTF-8 string isn't hard, just requires a bit of arcane knowledge. – Artelius Sep 09 '09 at 12:00
  • Certainly harder than reversing the bytes, though! If people have trouble with THAT...... – Artelius Sep 09 '09 at 12:04
  • @Artelius, try to write code reversing UTF-8 on an interview :) It is much harder than you think. – vava Sep 09 '09 at 12:43
  • @vava: not that bad. Run along the string, identifying each character and reversing the bytes just in that character. Once that's done, reverse all the bytes in the whole thing. That said, I'd need a reference open in front of me to write the "find the length of the next character" function, and there's a design decision what to do on encountering invalid byte sequences (in particular, do you abort and leave the string in a mangled state). – Steve Jessop Sep 09 '09 at 16:07
  • Yes good point about UTF-8, I should have specified that the string is ASCII or UTF-16; the idea is to see if the person knows basic pointer manipulation and/or can do it using the STL, not to worry about variable length encodings. Obviously bonus points to the candidate who points this out themselves! – tragomaskhalos Sep 10 '09 at 13:56
4

Do not forget to also test for code bigotry. I know I don't want anyone working for or with me that isn't a flexible and consequently practical programmer both in their attitude to the programming language, but also in their approach to problem solving.

  • Denying any type of preconceptions
  • Understanding the value of the exceptions in any Best Practices
  • Being capable of refusing long term habits in favor of something else if the need arises

These are characteristics dear to me. The manner of testing for these is not ideal if the interviews aren't lengthy or don't involve presenting code. But showing code snippets with purposely debatable techniques while offering a use case scenario and asking the candidate how they feel about the solution is one way.

Alexandre Bell
  • 3,141
  • 3
  • 30
  • 43
  • 1
    Damned good point. Have come across far too many programmers that can't recognise that straight design patterns are not necessarily the best solution to every problem. – Goz Sep 09 '09 at 13:43
  • 3
    So the questions: "when have you used goto?"; "should you check a pointer parameter for NULL before using it?"; and "singleton?" should give answers respectively: "almost never, but I sometimes think about it"; "depends whether my caller is a muppet or not"; and "no, I'm engaged actually, and don't call me Tone"? ;-) – Steve Jessop Sep 09 '09 at 16:14
3

Don't test only the C++ and overall technical skills! Those are of course important, but they are nothing if people don't listen, don't answer properly or don't follow the commitments they made.

Check at most for the ability to clearly communicate. If people cant tell you what roughly they did in their former jobs within a few minutes, they will also be unable to report about their work at your place etc.

In a recent company we invited people for interviews in groups of about 3 people together. They were surprised, but nobody was angry about that. It was very interesting, because people had to communicate not only with us, but also with others in the same position. In case we were interested further, we arranged a second interview.

RED SOFT ADAIR
  • 12,032
  • 10
  • 54
  • 92
2

You can choose potentially problematic task and see how they approach it. Ask them to write a smart pointer for example, you'll see if they understand pointers, references and templates in one step :) Usually they are stressed so they will do mistakes, those mistakes might help you find out how good they problem solving skills are, what paths would they use to fix a mistake and so on. The only problem with this approach is that sometimes interviewee just don't know anything about the task and you would have to quickly figure out something easier. If they do perfect code you can discuss their choices but when there's nothing to look at it is depressing for both of you.

vava
  • 24,851
  • 11
  • 64
  • 79
  • 1
    Good point on asking relevant questions. No point in asking someone a question on x86 assembler latency/throughput when they are a higher level programmer ;) – Goz Sep 09 '09 at 09:32
2

Here is my answer to a similar question geared towards C#, but notice that my answer is language agnostic. My interview question is, in fact, in C. I rarely interview a person with the goal of finding out if they can program. I want to find out if they can think, problem solve, collaborate, communicate, understand something new, and so on. In the meantime, I circle around trying to see if they "get it" in terms of the big picture of software engineering. I use programming questions because that's a common basis and an easy ruse.

Community
  • 1
  • 1
plinth
  • 48,267
  • 11
  • 78
  • 120
2

Get Codility.com to screen out non-programming programmers, this will get you a limited number of mostly reasoable candidates. Sit for an hour with each of them and try to build something together (a micro web server, a script for processing some of your data, a simple GUI). Pay attention to communication skills, i.e. how much effort does it take to understand the candidate. Ask the candidate for recommendation of books related to the subject (C++ software development in your case). Follow Guerilla Guide to Interviewing, i.e. answer yourself honestly, if the person is smart and gets things done. Good luck.

Grzegorz Jakacki
  • 201
  • 3
  • 5
1

Check 10 C++ Interview Questions by Tests4Geeks.

It's an addition to their pre-interview C++ test and it has really usefull questions. Many people have been working on these interview questions so it's quite balanced and has no tricky or syntax questions.

Idea is quite simple - first you weed out incompetent candidates using the test, then you use article questions in real-life interview.

Billy Gym
  • 11
  • 1
0

Whatever you do, pairing would be a good idea. Come up with a good program and pair with the guy and work towards solving the problem. IMHO, that a very good idea

Manish Chakravarty
  • 571
  • 1
  • 6
  • 9
0

So has anybody got any suggestions?

I'd recommend getting a copy of this:

http://www.amazon.co.uk/Programming-Interviews-Exposed-Secrets-Programmer/dp/047012167X/ref=sr_1_1?ie=UTF8&s=books&qid=1252499175&sr=8-1

ie it doesn't matter whether they get the right answers or not its how they approach the problem that interests me

You could ask the candidate to come up with a UML design to a common problem. If they show you a design pattern, then you can talk through the pros/cons of the pattern. You could then ask them to produce some code for one of the classes.

This would help you determine their technical knowledge level and their communication abilities.

I do care that they have a good solid understanding of pointers as well as understanding the under lying differences between pointers and references

Linked list problems are good for determining whether a candidate has a solid grasp of pointers.

As for references, you could show them some code that does not use references correctly, and ask them to describe the problem.

e.g show them a class definition that contains a reference member variable, and the implementation of the constructor with the reference initialization missing.

I would also love to see how they approach optimisation of a given problem because solid fast code is a must, in my opinion.

I'd start off simple...

Show them a code example that passes strings to a function by value. (the strings should not be modified in the function). You should check they correct the code to pass the strings by const reference.

After this, you could show a constructor that uses assignment instead of initialization (for objects). Ask them to improve it.

Lastly, ask them simple questions about data structure selection.

e.g. When they should use a list rather than a vector.

If you feel they have a grasp of the fundamentals you could either ask how they approach optimization problems (discuss profilers etc), or ask them to optimize something less obvious.

Steven Keith
  • 1,789
  • 15
  • 23
0

Take a look into this C++ test. They have a questions about differences between pointers and references as you require.

Here is full list of topics:

  • Fundamentals: References & Pointers, Const Correctness, Explicit
  • Standard Library
  • Class Design, Overloading
  • Virtual Functions, Polymorphism, Inheritance
  • Memory Management, Exception Safety
  • Miscellaneous: Perfect Forwarding, Auto, Flow Control, Macros

These guys are really serious about their questions, they also made the great list of C++ interview question which you might ask your candidates: https://tests4geeks.com/cpp-interview-questions/

Alex
  • 79
  • 1
  • 1