Does anybody know any good C programming tests?

[CDP]

I'm looking to hire a junior software engineer or possibly a software tester depending on who is available.

Previously I've hired contractors who I already knew to be good so interviews and tests weren't necessary.

I was wondering if anybody knew of any decent test for C or C++? I'm not after any of the silly propeller-head stuff just something to give me an idea on what they know.

Thanks

[dcb]

CDP said:

I'm looking to hire a junior software engineer or possibly a software tester depending on who is available.

Previously I've hired contractors who I already knew to be good so interviews and tests weren't necessary.

I was wondering if anybody knew of any decent test for C or C++? I'm not after any of the silly propeller-head stuff just something to give me an idea on what they know.

Thanks

Get them to write some code.

My usual is

void trim( char *str);

which removes whitespace from the front'n'back of a string. Should be
doable in about 20 lines of code.

Extra points if they use memmove instead of explicit copy.

Failing that, get them to explain the difference between

int (*comp)(void *, void *);

and

int *comp( void *, void *);

or, for simpletons, what is the value of this expression 1 + 2 * 3 ?

Most amusingly, one of our employees got the last one wrong ;->

[gamefreaks]

Make some prinouts with classes/functions/snippets of code. Eg: A printout of some multithreaded code and ask them where there are race-conditions and how they would solve them. Or maybe a snippet that leaks memory or double deletes an object.

Open each one with a question.

Use each one as a discussion point. Try to get them expand on previous experience to get a feel for how well they know their stuff.

Stuff I would try to cover:

• Basic types: So maybe something really basic like dividing/overflowing an int type or directly comparing floats.
• Memory managment: Maybe mismatched new with free() or be sneaky and use 'new char* string[MAX_PATH];' with 'delete string'.
• Classes, Inheritance and polymorphism: Just a basic class structure to ensure they know about private vs protected members, virtual functions (including virtual destructors) and dynamic casts between base and derived classes.
• Strings: I would be expecting knowledge of unicode, C runtime string handling, and STL strings. Include a bug that 'forgets' space for the NULL terminator.
• STL Containers: deques/vectors/hashmaps and iterators.
• Multithreading: Look for awareness of race conditions and knowledge of mutexes/semaphores/interlocked (atomic) operations.
• Template Classes.

Throw in tools/API's that they are also expected to know.

[CDP]

Thanks, all good stuff. Looking for new(ish) graduates spotting the differences can be hard.

The trim idea in particular is quite good. Either asking them to write it or give them a faulty example and ask what's wrong.

[jeremyc]

Tell them they have a function void plot (int x, int y) to draw a pixel on a display.

Ask them to write code to draw a circle on the display using this function.

Good way to see if they can optimise for speed, understand tradeoffs in using trig function libraries etc.

[aspender]

You could use Codility ( http://codility.com/ ) and set it up to require answers in C.

The questions tend to be quite algorithmic with short implementation but edge cases and space/time complexity constraints so you should assess whether you will learn what you want from it. I recently applied (successfully) to a company that use it and it was fine to use from the candidate's point of view. Personally I'd always prefer to see somebody solve a slightly more real-world problem and learn more about how they structure code, naming, readability etc rather than just simple correctness.

[CDP]

aspender said:

Personally I'd always prefer to see somebody solve a slightly more real-world problem and learn more about how they structure code, naming, readability etc rather than just simple correctness.

I agree with that point completely, absolute language knowledge isn't required I just need to work out who's trying to blag the interview.

[spikeyhead]

I'd want to test their ability to learn, and to ensure that they have a sense of humour and common sense far more than whether they understand the esoterics of something that plenty in the team can easily guide them in.

Nothing worse than trying to teach someone with high intelligence what common sense or basic social skills are.

[Flibble]

jeremyc said:

Tell them they have a function void plot (int x, int y) to draw a pixel on a display.

Ask them to write code to draw a circle on the display using this function.

Good way to see if they can optimise for speed, understand tradeoffs in using trig function libraries etc.

Trig? To plot a circle? Just use http://en.wikipedia.org/wiki/Midpoint_circle_algor...

[jeremyc]

Flibble said:

jeremyc said:

Tell them they have a function void plot (int x, int y) to draw a pixel on a display.

Ask them to write code to draw a circle on the display using this function.

Good way to see if they can optimise for speed, understand tradeoffs in using trig function libraries etc.

Trig? To plot a circle? Just use http://en.wikipedia.org/wiki/Midpoint_circle_algor...

Exactly: that article illustrates why it's such a great question - good candidates will be able to discuss what optimisations might be possible, the better ones might be able to explain their thinking and come up with the optimal implementation immediately.

Those that say "I'd look it up on Wikipedia/in a book/the internet" get shown the door straight away.

Mind you it's all changed since my day - I probably last used this question in interview more than 20 years ago. Programming were all fields then ....

[CDP]

jeremyc said:

Those that say "I'd look it up on Wikipedia/in a book/the internet" get shown the door straight away.

If they say that after giving a reasonable answer I wouldn't write them off. Not re-inventing the wheel is an important part of engineering.

[jeremyc]

CDP said:

jeremyc said:

Those that say "I'd look it up on Wikipedia/in a book/the internet" get shown the door straight away.

If they say that after giving a reasonable answer I wouldn't write them off. Not re-inventing the wheel is an important part of engineering.

Absolutely, but I'd argue this isn't an engineering project - it's the candidate trying to sell themselves, their experience and their skills to the interviewer. Looking it up isn't an option in this scenario - I'd much rather see someone talk through the problems and potential solutions (maybe even not getting the best answer).

[Flibble]

If given a simple scenario such as "write a function to draw a circle", my first port of call would be to look up a circle drawing algorithm, either via google or in a book. Saying someone is rubbish because they can't pop a fairly uncommonly used algorithm off the top of their head is crazy. You wouldn't force someone to do without reference material in their actual job, so why enforce that in an interview?

A better solution would be to have some reference material prepared and if they say "I'd like to look up an algorithm" (bonus if they name it as either the midpoint circle algorithm or Bresenham's circle algorithm) then present them with the material and let them get on with it.

[jeremyc]

Flibble said:

If given a simple scenario such as "write a function to draw a circle", my first port of call would be to look up a circle drawing algorithm, either via google or in a book. Saying someone is rubbish because they can't pop a fairly uncommonly used algorithm off the top of their head is crazy. You wouldn't force someone to do without reference material in their actual job, so why enforce that in an interview?

A better solution would be to have some reference material prepared and if they say "I'd like to look up an algorithm" (bonus if they name it as either the midpoint circle algorithm or Bresenham's circle algorithm) then present them with the material and let them get on with it.

You miss the point - I'm not looking for skills in remembering algorithms, but rather an ability to solve problems. If they were to say they couldn't remember the equation for a circle then I'd give them the information.

At the time I needed engineers who could write code to solve problems that didn't have the answers on Wikipedia, searchable via Google nor in books.

Finding candidates with the ability to solve problems that haven't been answered before is a good way to add real value to a business. Otherwise all everyone has to do is copy the internet* ....

At the time the internet didn't exist.

[gamefreaks]

jeremyc said:

Flibble said:

jeremyc said:

Tell them they have a function void plot (int x, int y) to draw a pixel on a display.

Ask them to write code to draw a circle on the display using this function.

Good way to see if they can optimise for speed, understand tradeoffs in using trig function libraries etc.

Trig? To plot a circle? Just use http://en.wikipedia.org/wiki/Midpoint_circle_algor...

Exactly: that article illustrates why it's such a great question - good candidates will be able to discuss what optimisations might be possible, the better ones might be able to explain their thinking and come up with the optimal implementation immediately.

Those that say "I'd look it up on Wikipedia/in a book/the internet" get shown the door straight away.

Mind you it's all changed since my day - I probably last used this question in interview more than 20 years ago. Programming were all fields then ....

In my opinion, this is exactly the sort of question to avoid unless your looking for a low-level graphics coder. It's trivia. A lot of perfectly able junior (read: young!) programmers will give you a guppy impression. The good ones will simply say call DrawElipse(). At best, you'll be getting them to dredge up GCSE trig.

I think this is a better example:

Ask them to write a RingBuffer class. Take a laptop into the meeting room so they can write it with an IDE and a debugger (like they'll use when they actually work for you) and leave them to it for 15 minutes. Don't make them write it on paper or a whiteboard!

When they've done it, you have a number of discussion points Eg:

• Does it actually work?
• Did they use a template class or does it just work with pointers + length?
• Is it thread safe?
• Did they optimise for things like copying a large buffer into a small ringbuffer?
• Coding style.
• Does it alloc and free its buffer correctly?
• Appropiate use of public/private members.