C interview questions: what to ask?



Question for all C developers on this forum: what questions would you ask as an interviewer to measure the level of proficiency of a candidate in C ? The opening is for a developer with 3 years of experience. Our team develops application software that run on both Linux and Windows for relatively large firms.



While I don't expect the candidate to be able to recite "The Annotated C Reference Manual" by heart, I want to pose questions that are meaningfully challenging and C specific. I'm slightly lost here though because this is the first time I'll be playing an interviewer.

Vick

Tuesday, October 10, 2006





What if you find a good developer who doesn't know C yet (but could learn in a very short time)?

Steve Hirsch

Tuesday, October 10, 2006





While I'm not advocating the idea of technical interviews at all (preferring code evaluation from the candidates former projects) - the following topic might be useful:



"What do you think about private virtual functions?"



Micha

Micha

Tuesday, October 10, 2006





A good grasp of C text book knowledge != a good programmer.



A good programmer doesn't necessarily know C

FJ Cruiser

Tuesday, October 10, 2006





I always thought that some of those Lint puzzles (they used to be in the lint ads in Dr Dobbs) were great.

Sunil Tanna

Tuesday, October 10, 2006





I am not any type of "star".

Type my name and collect some question I was struggling with.

DAN LEE

Tuesday, October 10, 2006





You might find some questions here:



http://www.possibility.com/epowiki/W...rviewQuestions

t

Tuesday, October 10, 2006





I always try to get a candidate to explain stack unwinding to me, and what is in danger of being leaked, and what they can do about it. I wouldn't necessarily consider that a super advanced question, but it seems to flunk out enough people it makes a good first question.

Keith Wright

Tuesday, October 10, 2006





Here's what I do for teching out somebody. Ask the question, then leave the room, making sure that the interviewee has a phone to call friends, a web connection, textbooks. Come back in a few to review the answer. Have the person explain how they got the answer.



It's not school. "Cheating" is a good thing, having memorized syntax is worthless when reference materials are easily available. To me, the technical test is the explanation of the answer.

Steve Hirsch

Tuesday, October 10, 2006







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.

Luc Hermitte

Tuesday, October 10, 2006





1 for Keith



His type of question is the right kind to ask.



When interviewing, there's no sense in trying to put the person under pressure. Just give them something then let them run with it. Most people will hang themselves. You've got your answer.



The key is that most people like to talk. They suck at listening. That can really work in your favor if you work it right. I've done enough interviews like that and seen it work time after time.

Ryan Smyth

Tuesday, October 10, 2006





What is LSP?

Old Coder

Tuesday, October 10, 2006





Liskov substitution principle, i.e. that you can substitute an object A with another object B which is a subtype of A without breaking any contracts. Rather fundamental to OOP.

-L

Tuesday, October 10, 2006





What books have you read and what did you get out of them?

Christopher Wells

Tuesday, October 10, 2006





Why won't this compile?








[COLOR=#000][FONT=monospace]int e;

for (int i = 0; i [COLOR=#000000]> There's a ton of niggling little details about C that don't translate over to all these other languages. Someone who has memorized more syntax, library

> details, etc. will be orders of magnitude more

> productive than someone who has to look it up

> every time.



Rubbish. Productivity has nothing to do with how fast you write code and everything to do with how well you write code.



I'll take well structured, well designed, well written code over churned out spaghetti code any day.

Jussi Jumppanen

Tuesday, October 10, 2006





> It just so happens that exceptions go hand-in-hand with the STL.



Sounds like another good reason to stay away from STL

Jussi Jumppanen

Tuesday, October 10, 2006





Jussi, you can use the STL just fine without exceptions. I use it a lot, and I don't use exceptions.

sloop

Tuesday, October 10, 2006





In the real world, with otherwise identical people the one who knows the language well will be more productive than the one who doesn't know the language as well. Even if the language is python or lisp, that still holds true.



Given one guy who's a bit smarter but knows 50 languages other than the one your team uses, hiring that guy means taking time to wait for him to learn the language, and unless he's remarkably more intelligent than the other guy, that'll probably be somewhat irritating.



So, assuming you're only interviewing smart people to start with, checking basic things like "do they actually know the language they claimed to know to the level that a real expert would" covers both honesty in the resume, and helps in that experts tend not to be retarded. A C expert (and that isn't limited to memorizing language features, but includes knowing when to use or avoid the feature) helps with determining if the guy is smart.



(Which is a point: the natural followup to any language feature question is "when would you do that?" and sometimes the correct answer is "when I'm on drugs".)



Tuesday, October 10, 2006





>> Rubbish. Productivity has nothing to do with how fast you write code and everything to do with how well you write code.



What does speed of coding, fast or slow, have to do with code quality? A developer who takes seconds to type the correct line of code is going to be more productive than a developer who takes minutes or longer. Someone who has fopen's common usage memorized will naturally be much more productive than someone who has to take 30 minutes every time to look up the second parameter and then debug it until they realize they needed the "b". It's really hard to disagree with this. Someone who takes two seconds to type the correct line of code is going to be more productive than someone who takes 30 minutes.

SomeBody

Tuesday, October 10, 2006





I bought the Wrox C# book and learned enough C# in 3 days to pass a pretty tough technical test in a C# .NET shop. I did that because I knew that I could do the job well, I needed to get past the stupid key word filter. I have no regrets.



If you consider that coding is oh, 5 to 10% of the effort of creating sw systems that people actually use, testing potential employees on how much syntax they can spit out as if they were in school will pretty much guarantee you the wrong type of employee. You wind up with people more interested in the tool than your business, and that's never happy.

Steve Hirsch

Tuesday, October 10, 2006





>> It's really hard to disagree with this. Someone who takes two seconds to type the correct line of code is going to be more productive than someone who takes 30 minutes. > It's not 30 minutes, it's 5 minutes. And it's only 5 minutes on the first pass - then it's 2 seconds.



No, it's only two seconds the next time if the person actually remembers. The argument here seems to be that no one should ever be expected to remember anything since it can just be looked up.

SomeBody

Wednesday, October 11, 2006





I remember C as not too difficult, but it was a while ago. If C is that much harder to learn well, then drop it, it's not the right tool for the job.



Hiring a programmer based on the syntax s/he knows is like hiring a mechanic based on whether s/he uses a wrench or a ratchet. If all your developers do is program, then you need to reorganize your department.

Steve Hirsch

Wednesday, October 11, 2006





here is one that most C programmers have never used, including myself. I know what they are but never used them..never had to.



what does the keyword mutuable and exclusive mean in C and give me an example of how i could use either one.

OpenGL_Programmer

Wednesday, October 11, 2006





"what does the keyword mutuable and exclusive mean in C and give me an example of how i could use either one"



mutable means you can modify a variable from a const method. I don't use it very often, but I do use it on critical sections so I can access variables in a critical section from a const method.



exclusive isn't a keyword in standard C .

sloop

Wednesday, October 11, 2006





oops what i mean was mutable and explicit. for some reason got caught up in thinking of the phrase "mutually exclusive" for some reason. thats when you know its really late and time for bed haha.



has anyone ever used mutable or explicit and what for?

OpenGL_Programmer

Thursday, October 12, 2006





I already mentioned an example of where you might use mutable. explicit is used with constructors to prevent implicit conversions. Take a look at the auto_ptr(T *) constructor for an example.

sloop

Thursday, October 12, 2006





Mutable is used in multithreading programs where the act of aquiring a lock changes the lock structure, declaring the lock mutable lets you keep 'logically const' methods const, e.g. a method that has to lock object state, but does now change it.



Explicit stops all sorts of crazy hidden conversions happening, we used it by default on all single argument constructors.



I think these are good questions to ask, a 'C expert' should be able to answer questions like these no probs.

Manny

Thursday, October 12, 2006





I use explicit every time I define a single-argument constructor on types (*) I do not wish to have an implicit convertion from the argument type.

(*) Typically when they have an entity semantics. Sometimes I permit the implict conversion on value semantics based types.



Regarding mutable, sometimes I use it to implement proxies, and quite often on the mutex attributes of my objects.

Luc Hermitte

Thursday, October 12, 2006





OpenGL_Programmer what bothers me, is that not only you don't know why the 'explicit' keyword can be useful, but your C colegues don't know it either. It just means that neither you, nor your colegues have read even one decent book on C . You guys may be wizards of 'C with classes' but this ain't enough to call yourselves C programmers. Don't get upset, just read a book. Until you know such "details" call yourselves C students. Here is a very short example:








[COLOR=#000][FONT=monospace]struct Fred {
Fred(int n): v(n) {}
std::vector v;
};

int main() {
using namespace std;
Fred f(1);
f.v[0] = 5;
cout [COLOR=#000000]