The Old Joel on Software Forum: Part 3 (of 5)

Interview Question

Back during the dot com madness, I used to give technical interviews all of the time. The first thing I would say to Unix/C programmers was:

You know, I'm a Turbo Pascal/Delphi guy, and I really don't know C much at all. I have a question about 'printf' I was wondering about: "Will this compile?"

printf("There are %d days in February",12);

Everyone would say "yes", that this would compile. Then I would rewrite the statement and ask: "Will this compile?"

printf("There are %d days in February");

Out of maybe 100 people I've asked that of, perhaps 97 said "No, that won't compile." In those cases, I would then spend the next 15 minutes wondering how quickly I could wrap up the interview with the interviewee "saving face".

(By the way, many of those 97 candidates [I instantly internally rejected] would go on to tell me the wonderousness of Unix/C vs. Windows/Delphi!)

This was always for a project that has been around for nearly 13 years that is made up of a Galacticomm BBS (written in DOS/Borland C++), a (now) XP machine running Turbo Pascal and Delphi programs, and a single Netware file server. (This system will probably run for at least another 5 years.)

We tried three seperate times to replace this with Solaris/Oracle/Perl/C++/you name it. Failure each time. The latest try was with VB (not even close!)

Now that I'm involved with additional projects that deal with AIX, I've decided to add an additional question that I really don't have the answer to (we ran into this on 1 of the Solaris "trys"):

Where does standard out go in a daemon?

Steve Forest
Sunday, November 30, 2003

In those cases, I would then spend the next 15 minutes wondering how quickly I could wrap up the interview with the interviewee "saving face"

Sad, it is. You are not yet a jedi. For a jedi would have asked what they used as a compiler. Some (Watcom being one), would declare it a compiler error. While it is language legal, that was not your question.

This, in the end, is the problem with all these type questions. Much like your last one. Would "it depends" be an acceptable answer? Would you know if they were right if they did not use your exact phrasing? Would you bet your job, the answer would be the same regardless of the OS?

Based on the attitude, I would say the 97 were the lucky ones.

TooBadSoSad
Sunday, November 30, 2003

Let me suggest a question, just as usefull:
Everyday, people's ability to mischaracterize reality, never ceases to amaze me. Or maybe it does. Please explain the contradiction. You have two minutes.

Nothing in all the world is more dangerous than sincere ignorance and conscientious stupidity.
Martin Luther King Jr. (1929 - 1968), Strength to Love, 1963

JimmyB
Sunday, November 30, 2003

Erm... the incorrect printf should always compile. The people who say "no" are incorrect. If your compiler gives you a warning, that's good -- for you. However, the code will still compile.

Insert half smiley here.
Sunday, November 30, 2003

D'oh -- I should add, Watcom is incorrect in this situation. It doesn't know what printf you are using. Maybe you have your own, for which %d means something different. It's none of its business -- it should indeed warn, but not fail.

Insert half smiley here.
Sunday, November 30, 2003

What did you learn about the candidates by asking this question?

Beth
Sunday, November 30, 2003

Asking someone a technical question isn't to see if they know the answer to your particular question or to trick them in order to boost your own ego, it's meant to see how they code and how they think. A better question or exercise would be to ask the candidate to write strlen in a given amount of time and then question them as to why they did it the way they did. You can obviously tell by the code they write and the answers they give if they know what they are doing and if they are the kind of coder you would want working for you. Questioning them like this helps you to understand them and the way they think about problems while not suggesting that you are superior to them.

icancyuwudbeshy
Sunday, November 30, 2003

But then, how smart is it to still develop in C today, unless you have a very good reason to (eg. tight, portable code)? :-)

Frederic Faure
Sunday, November 30, 2003

gcc will warn about it with suitable warning settings (such as -Wall). If you have warnings as errors, it wont compile.

So even with the same compiler, it could depend on what your compiler settings are.

Sum Dum Gai
Sunday, November 30, 2003

"But then, how smart is it to still develop in C today"

Pretty smart since C applications represent 80% of commercial application revenue.

She sells C shells
Sunday, November 30, 2003

Wow, such angryness!

"It depends" would be a wonderful answer--if only I heard it more often.

I had one candidate who supposedly had written a text book on C programming. I asked her to write the classic "hello world" program. She replied, "Right now???" with incredularity. She couldn't do it.

My point of this "printf" question is that many people don't get what is REALLY going on under the hood.

How can a compiler know that a format string and its "passed arguments" (for lack of a better term) don't match up in either type or quantity? What if the format string was a variable that you didn't know the value of until runtime???

The few people who "knew" about this went on to discuss with me about what would happen in what environments if you passed the character string "fred" instead of a numeric value. They were hired and we invested a lot of money in them.

Sorry, but for that project, I wasn't looking to train a newbie. I needed more senior people and was willing to pay for their expertise.

Nope, I am not all knowing.

But one of the reasons I stuck with Turbo Pascal v7 so long (still use it today!) is that the compiler is very simple and with years of experience with it, I can usually predict what it is going to do (not always true with Delphi!) The base Turbo Pascal command line compiler .exe size is less than 64K. Even at this size, there is WHOLE LOT to learn (Anders Hejlsberg, author of Turbo Pascal, Delphi, & C# is a genius in my opinion.)

I still don't know where standard out goes in a daemon. We had one daemon written in C on Solaris where standard out would "end up in the middle" of the data files we were processing. No apparent rhyme or reason. Just "in the middle".

Steve Forest
Sunday, November 30, 2003

Steve, you asked how can a compiler know. Well, in the case you gave, a compiler can be written to know that there is a mismatch and some compilers will flag this as a warning. Yes, if it the format string is a variable and not a constant string, then it will be a lot harder to tell.

If I was interviewing, I would make use of the time and educate the person and see how they reacted. Do they say "Oh yeah - doh!" and hit their forhead? That's a good reaction. Do they say "I fail to see why that is important." or insist you are wrong and call you names? That's not as good. If they then point out some of the repercussions of forgetting an argument (stack corruption), and talk about the times they goh burned by it and they are so glad to now have a really smart compiler that frags it as an error, that's even better.

Regarding your daemon question, the answer is 'it depends', on the operating system you are using for one thing, and the compiler for another, and what you are linking against for a third. But the key is that you absolutely should not be sending to stdout from a daemon process unless you have written your own low level console output routines and linked them against the standard library.

She sells C shells
Monday, December 1, 2003

Anders Hejlsberg makes me complete.

TJ Haeser
Monday, December 1, 2003

You wasted 97 peoples time with your ignorance.

Realist
Monday, December 1, 2003

Just imagine this guy interviewing a doctor. What material is the scalpel coated with, and to what depth?

Monday, December 1, 2003

She sells C shells >> Pretty smart since C applications represent 80% of commercial application revenue.

... and considering the average quality of software, a smart move would be to think hard about _why_ they still code in C.

I'll have to check if Opera 7.21 _finally_ fixed the memory leak bug that was already there in 5.12 ;-)

Frederic Faure
Monday, December 1, 2003

I see no reason why being able to program in the language they are being hired for should not be tested in the interview. In fact, I'd say it always should be. The question then is what can you ask to reasonably test their language knowledge?

Now, this particular question is a little odd. But I wouldn't say it is the horror it is made out to be. I'd rather see it posed in a less out-of-context way, instead, perhaps asking if the candidate can find the bugs in a piece of code containing this error. But I think a C-programmer should know this.

Mr Jack
Monday, December 1, 2003

Wow Freddie, I didn't realize that the correctness of the program was due to the language used and not the talent of the people creating the program. Thanks for clearing that up.

She sells C shells
Monday, December 1, 2003

I meant that, considering how pathetically productive and error-prone people are developing in C (me love GPFs), seems to me that, yes, it's a smart thing to do to start questioning the tools used :-)

Frederic Faure
Monday, December 1, 2003

Steve,

As for your daemon's stdout, the answer is so simple that it's probably going to be a little hard for you.

The recommended practice for a daemon is to close stdin, stdout and stderr completely. The programmer must actively choose what happens with these streams though. One possible use of the stdout or stderr stream is to write a log file, separate from the syslog created files. There is no "standard" destination for the endpoint of any of those streams though. If the programmer doesn't redirect them, they stay pointed to where they were when the program was started. Depending on how the daemon is started, the results can be pretty interesting.

Clay Dowling
Monday, December 1, 2003

Steve, imagine going to interview for your dream job - some kind of cutting-edge, challenging, "on your toes" C coding job in a great work environment. Good pay, benefits, location, and every developer gets an office.

You know C inside and out, obviously, and you're confident as you walk into the interview.

The interviewer comes in, sits down, and asks "Where does stdout go in a daemon?"

You stumble, mutter, finally admit you don't know.

"I see," says the interviewer, as he graciously ends the interview and shows you the door.

See, *he* lives in daemon world, and simply cannot be bothered with anyone who claims to know C but doesn't know something that fundamental...

Sound fair to you?

Philo

Philo
Monday, December 1, 2003

quote: I asked her to write the classic "hello world" program. ... She couldn't do it.

Dude. With that single question she recognized what an ass you were. That's why she didn't do it.

paul
Monday, December 1, 2003

“My point of this "printf" question is that many people don't get what is REALLY going on under the hood. “

The whole point of being under the hood is to hide complexity. Most of the people don’t need to know what is happening under the hood so they can focus on solving things that are billable like implementing business logic and shipping the product.

coresi
Monday, December 1, 2003

My roommate has a pet interview question that I've been trying to dissuade him from: it goes, "how can you tell if a problem is solvable by a computer?" Actually, it's a pretty good question when you can go into topics like NP-completeness and O(n) notation, but the way my roommate asks it, he's looking for a special, "magic word" answer - anything else is wrong.

The magical word in this case is "algorithm". "If you can come up with an algorithm, it's solvable by a computer", says he.

Hang on just a minute. 'Algorithm' just means 'a step-by-step method of solving something. So in short, he just said that if you can come up with a method of solving the probelm, then it's solvable. How tautological is that?

I don't think he's the only interviewer asking "magical word" questions.

Alyosha`
Monday, December 1, 2003

Steve,

I think your printf() verbal test is absolutely "fair and balanced", and kudos to you for thinking of it.

Let me defend Steve to the group, then. I always like to hear about simple, elegant pass/fail criteria. I love this stuff.

Printf() is almost without exception the very *first* run time library function learned by most C programmers. No C programmer hasn't encountered printf().

Mismatching the % argument slot and the value parameter list is the kind of entry level challenge that *any* C programmer would encounter in developing their own code. The question, "what would this do when you tried to compile it, or would it even compile" is exceptionally fair.

KNOWING WHAT HAPPENS TO PRINTF WHEN ARGUMENTS ARE MISMATCHED IS FIRST-ORDER KNOWLEDGE.

Also, C implementations (as opposed to C++) don't always check the parameters passed against the function's argument list. Every C developer with any type of decent experience knows that it's possible to pass parameters when none are need or to pass fewer function parameters than needed. It's possible to compile the crap, and then to get really interesting results when you run that code.

This is as much as *listening* exercise as it is a technical exercise. The Jerry Weinberg "orange juice" test comes to mind. It's important sometimes to know when someone is *carefully* listening to you, not just fluffing off with generalities.

The context of the experience is also very important. Let's talk about billings and business success vs. knowledge of low level detail.

I've known quite a few independent contractors who billed high (earned much more than me) and who knew lots of people, but who were as shallow as a puddle in terms of technology knowledge. Placed in a context where such a "personality and marketing driven" contractor had to work with a techie who would test their mettle, the "glamor guy" would fail miserably, because he would only know *just enough* to be billable but would be out of his element when dealing with actual details. In the past I've had people like this laugh at my relative lack of business success, then pump me for my knowledge...

Lastly, comparing this question to knowledge of a daemon's response to writing to stdout is dumb. Daemons are NOT the first order knowledge of developers, since they require not only coding experience but knowledge of real time programming, interrupts, multiple system calls, scheduling, etc. printf() *is* first order knowledge.

So, I think the scorn for Steve's test is unfounded. Again - simple, almost effortless, and testing the candidate against several important criteria at once.

Bored Bystander
Monday, December 1, 2003

However if you begin the question by stating "You know, I'm a Turbo Pascal/Delphi guy, and I really don't know C much at all." then you might expect generalities in the reply to this and every other C-related question you ask.

Despite Steve's best recruiting efforts neither he nor his new recruits could resolve the daemon stdout issue, the cause of which could be guessed by anyone who "gets what is REALLY going on under the hood". How ironic.

G
Monday, December 1, 2003

Bored - tell me again what street the Empire State Building is on?

I can tell you, from both first-person and second-person experience that what YOU think is "just so" is not always "just so" for everyone else.

Let's start with first principles:
EVERYONE'S BRAIN IS WIRED DIFFERENTLY.

You could have three candidates that all know the answer to that particular question, but will each miss it, depending on whether you presented it: a) written down, b) spoken, or c) spoken, asking them to write it.

Have you seen the poster that has a list of colors, each color's text written in the "wrong" color? It asks you to read the colors off - whether you read the word or say the color of the word indicates whether you're left-brained or right-brained. Neither one is "correct"

Here's a fuller discussion of "types of minds":
http://brain.web-us.com/brain/LRBrain.html

Now with the printf question (or *any* go/no-go single point of knowledge question), what you are looking for is "someone just like me" - someone with your experience that learned the things you know the way you did.

[hint: with my daemon interviewer, what if he learned C to write daemons? He taught himself what he needed to know, when he needed to know it. He never used the printf statement, and for whatever reason never used tokens]

Anyone stop to think that if you've always learned by opening editors and stealing code snippets you might not know what the hell "Hello World" means?

And I will posit that hiring a company full of people "just like oneself" is making things harder for the company - true viability comes from creating a heterogenous mix of personalities and talents.

My $.02

Philo

Philo
Monday, December 1, 2003

Philo,

34th street, I THINK. ;-)

Now let me ask you a comparable question: how would you choose to spend your own money on a programmer? How would you choose one that is actually able to do the work?

Assuming an interviewer is obliged to ask questions that measure the candidate's knowledge and honesty in presenting themselves as a plausible candidate to work with technology X: what kinds of questions would you favor?

I'll grant you one thing. I think answering this question incorrectly would not necessarily indicate that the candidate can't do the work, because they may not key off of the question as expected. (Although I still think the question is very clear, concise and unambiguous and I really still wonder about the 97 washouts calling themselves C programmers or the person who wrote a C book who can't write "Hello, world".)

So, I think that a few other questions in a radically different style would be appropriate. Best 2 out of 3 gets called back, for instance.

I'm pretty open minded and I tend to favor the candidate's point of view. I tend to think most corporations and their gang-bang interviews are the province of egotistical pricks who don't want to admit that anyone outside their pwecious widdle company clique knows anything.

BUT let's be reasonable. An interviewer is obliged to measure *something*.

Your thoughts?

Bored Bystander
Monday, December 1, 2003

>> [hint: with my daemon interviewer, what if he learned C to write daemons? He taught himself what he needed to know, when he needed to know it. He never used the printf statement, and for whatever reason never used tokens]

Anyone learning a new language uses *some* IO device to test their first coding attempt. The console is generally the easiest solution to see if you've got something that runs, unless you're writing something like PIC or 8051 assembly code.

I've never known a C developer who *didn't* ever use printf(), at least initially. I'm sure they are out there. If they are, I sure as heck haven't worked with any.

>> Anyone stop to think that if you've always learned by opening editors and stealing code snippets you might not know what the hell "Hello World" means?

I probably wouldn't want to hire someone who never cracked a book open on any programming subject and who was therefore unaware of "Hello World" as a basic exercise...

Bored Bystander
Monday, December 1, 2003

Honest to goodness. I bet all the people answering here actually do hire people. No wonder we have a shortage of talent. When I hire a programmer I read their programs. End of story.

Me
Monday, December 1, 2003

Not being a C programmer (C++/C#, yes) can someone answer:
Why would anyone write a printf statement like that? And what harm would it do?

From what I gather it would produce a runtime error?

MR
Monday, December 1, 2003

MR,

What it will do depends on the compiler. The first statement will compile and run flawlessly.

The second one may not compile, depending on your compiler. If it does compile, it may fall down and go boom with a segfault/core dump. It may print a number that is not predictable from the information available. In some subsequent statement, there may be unusual errors that don't make a lot of sense, because the stack is corrupted. I have seen all of these reactions, depending the tools used the build the application and the system it is running on.

In short, you can't predict what will happen based on the available information. Without doubt the code is incorrect. It's also an easy thing to overlook, especially if you're using an older compiler that doesn't check for this sort of error.

Clay Dowling
Monday, December 1, 2003

Someone would use printf like that out of carelessness. There are a load of bad C/C++ programmers who depend on the compiler and testers to find their mistakes.

Under Windows/Visual C++, the bad printf example will print whatever four bytes are next on the stack. This will likely be the value of a local variable or the return address (compiler optimizations can make this somewhat unpredictable). It almost certainly will not crash. It's not hard to imagine a different implementation that would respond differently. Under Windows/Visual C++, mistakes with things like %d are mostly just annoying because they tend to occur in less tested code like error messages or logging where getting the correct value can be important for pinning down a problem.

If you change the %d to %s (string instead of int), you'll get either junk or a crash because some unintended value is being dereferenced as a pointer.

As I think someone mentioned earlier, any compiler that doesn't compile printf("%d") is flawed even though this usage is obviously incorrect (it is nice when they provide a warning).

I'm curious how many interviewees pointed out that February has more than 12 days?

SomeBody
Monday, December 1, 2003

Bored - while I've never slung C, every language I've learned in has had the same basic token replacement syntax. For whatever bizarre reason, I've never picked up on using token replacement in strings. Eight and a half years of programming and the only token replacements I've done are in inline sql until I started using stored procedures.

My point being that it's entirely possible, in the vast sea of programming knowledge, to miss an island once in a while. Even if it's right next to the customs stand at your point of debarkation.

On another line of thinking, why would you quiz someone you want to be good with a line of bad code? Wouldn't it please you if they've never actually seen that line of code, because they've never made that mistake?

"If you drive a car with a wheel missing, which way does it pull?"
"I don't know - I've never left a wheel off the car. Does that happen to you a lot?"
[grin]

Philo

Wisdom trumps knowledge
Monday, December 1, 2003

>> why would you quiz someone you want to be good with a line of bad code? Wouldn't it please you if they've never actually seen that line of code, because they've never made that mistake?

That's about the most unlikely situation I can imagine. If someone isn't making mistakes, they're not trying nor making any progress either.

If someone is proficient with a tool, they almost without doubt know the common ways in which that tool can be misused.

Bored Bystander
Monday, December 1, 2003

You know what? I can think of distinct moments when either I or a peer had a head-smacking moment over a bug that didn't make sense until you found the stupid mistake. Two months ago I had to point out the missing statement in a SP call to a friend who's been working .Net since early beta. He'd never seen it before, (sheepishly) I have.

I still think not knowing that that statement will compile is a false positive for "doesn't know C". Sure it's an indicator, but a damn poor go/no-go, as just about any single question worth asking is.

Philo

Wisdom trumps knowledge
Monday, December 1, 2003

"If someone is proficient with a tool, they almost without doubt know the common ways in which that tool can be misused."

That's precisely the point of why this printf test is a lousy way to judge programming skill. The question that's being asked of the candidate is, "Will this compile?" A good programmer is careful about getting the number of arguments for their printf statements correct in the first place. They'd fix the problem before they ever tried to compile the code. It's a trivia question about pitfalls in the C language that good programmers learned to avoid long ago.

Matt Latourette
Monday, December 1, 2003

>> That's precisely the point of why this printf test is a lousy way to judge programming skill.

I disagree.

The point isn't to determine what the skill level of the candidate is with one question and answer. The point is to disqualify people who are blowing smoke about having programmed in the target language at all.

If I gave this question to someone and they said "it won't compile" I'd ask them to walk through exactly why they said this. I wouldn't simply include them or knock them out of the running with a yes or no answer.

In fact if they said "yes it will compile", even though it's the correct answer, I would again ask them upon what they based this assertion.

What could possibly be the problem with a question like this? The definition of "compile"? If someone uses a compiled language like C, they had BETTER know what "compilation" means. The mastery of nit picky details? We're talking about a problem space consisting of a 30 or so character C code statement using the most commonly used run time library function. Not exactly a huge territory to get lost in.

Hells' bells, this kind of question beats the absolute socks off of the "uber geek" type of nit picking prima donna weenie question I've been asked in this industry. I think all of you guys who are criticizing this low a bar of knowledge are missing the fact that while it's not perfect, it's still pretty damned simple, elegant, and impervious to misunderstanding by most English speakers.

The typical C question I've been asked by people who were inordinately proud of their command of inane details were things like confusing multiply-dereferenced pointer questions. This seems to be a favorite "let me bust the chops of the unwashed outsider I have to interview today" question.

IE, in the C language if 'p' is a pointer at int, then *p is the int variable pointed-to itself. And you can have pointers-at-pointers, **p to dereference for instance, but the utility starts to decline substantially. I've had "idiots" (bright people way too proud of their command of the inane) ask me to decipher usage of "****p" in a piece of code and explain the strategy of memory allocation it implied.

I don't expect anyone to see any of this at all. Asking for specific knowledge seems to offend some people greatly. Why, I don't know. I'm honestly trying to see what the hell is the problem with such a simple criteria. I don't repent. I think the basic question is GREAT.

Are some of you arguing just for the sake of arguing?

Bored Bystander
Tuesday, December 2, 2003

I agree that it's a great question.

The point isn't that the interviewees didn't know the correct answer, it's that they gave the wrong answer. Even if you have a valid excuse for not having much experience with the printf family of functions, reasonable knowledge of the language should be enough to give a decent guess.

To get this question wrong, you'd have to:
* Have little knowledge of printf.
* Know nothing about varargs.
* Not know the difference between a keyword and a standard library function.
* Not know the difference between compiling and linking.
* Not understand the relationship between string literals and char pointers ("%d" could be replaced with the same string loaded from a file at runtime).
* Think that the contents of strings affect the compilation of the code around them.

Remove just *one* of the above and you should be able to get this right.

I'd hate to get any recommendations for doctors from someone who thinks that wisdom trumps knowledge! The truth is that both are important.

SomeBody
Tuesday, December 2, 2003

Well put.

If someone lacks specific first-order knowledge, I tend to assume that they probably don't have all that much wisdom, either... Wisdom is gained by day-to-day accomplishments, among other things. The people in this industry who possess "wisdom" also have a ton of specific knowledge simply because they've done a lot.

When someone professes wisdom but can't back it up with details, that's exactly when you need to do a reality check.

I suppose it's possible that someone possesses great mastery of rote facts but lacks the wisdom to use those facts properly... I personally have not observed too many instances of this.

Bored Bystander
Tuesday, December 2, 2003

...or you could ask a few more questions and be sure. Or is that too much work?

I simply think that if you're screening resumes well, any question that you use as a go/no-go that fails 97% of your interviewees bears reexamination.

Philo

Wisdom trumps knowledge
Tuesday, December 2, 2003

My point is that the question as it is phrased is a trick question. In an interview situation, the candidate is inevitably going to be nervous and you're probably going to get their knee-jerk response to this question. You'll often get the wrong answer from candidates who do have the first-order knowledge you're looking for because "Will this compile?" is easily translated into "Is there something wrong with this code snippet?" mentally. The candidate immediately recognizes that the code is bad and answers "no." A more reasonable test would be to give the candidate a snippet of code to look at and have them point out coding errors to you. Whether or not bad code compiles is irrelevant. What matters is that the candidate can recognize coding errors and fix them.

Matt Latourette
Tuesday, December 2, 2003

Interesting point, Matt- I agree with your logic. By extension, doesn't that mean the original poster and Bored are advocating "dubugging via compiling"?

Now I'm trying to think of when that question would be relevant. Bad code is bad code, whether it compiles or not, and why would you care whether or not bad/useless code compiles?

Here's one that I had to test:
Will this compile in C#?

const int zero=0;
int test=1/zero;

Answer: who cares. If you get a compiler error, great - the compiler's saved you some work. If you don't, then you have to find your stupid mistake on your own. You don't look at code like that and think "well THAT can't be the problem - it compiled!"

Ayuh - in that light, I've got to relegate the printf question to the "stupid trivia" pile - no practical application.

Philo

Wisdom trumps knowledge
Tuesday, December 2, 2003

Once again, you're missing the point.

Referring to it as "stupid trivia" implies that the original poster sat candidates behind a terminal that flashed the question on the screen and gave 30 seconds for them to press a big YES or NO button. He specifically mentioned in a followup post that he would've loved to hear an answer like "it depends", implying that he was open to discussion.

Again, the point isn't that the interviewees didn't know the answer but that they assertively gave the incorrect answer. As I stated in my last post, a person with reasonable knowledge of C/C++ should be able to formulate a reasonable theory about what will happen. This is a great question precisely because it's something that no one would ever memorize the answer to and probably would never try since it's obviously incorrect and would likely only be able to answer correctly if they have the language experience that they claim and understand the distinctions between compile time, link time, and runtime -- understanding these distinctions is vital to using C/C++.

SomeBody
Wednesday, December 3, 2003

"This is a great question precisely because it's something that no one would ever memorize the answer to and probably would never try since it's obviously incorrect"

Here's the thing - you are asking a question that has no purpose.

"and would likely only be able to answer correctly if they have the language experience that they claim and understand the distinctions between compile time, link time, and runtime -- understanding these distinctions is vital to using C/C++."

I think you're wrong here. It seems to me (no C experience) that all it tests is if the candidate knows if C compilers, in general, check the parameter list when a token replacement is indicated, and if they do, whether they issue a warning or an error.

Does it even issue a runtime error? Seems to me it would be trivial to implement a printf statement that, if no token replacements are offered, simply issues the literal token in the string. Whether or not C does that means knowing the mechanics of the printf statement in C when used contrary to common usage.

Can the original question be replaced with this?

"A C function is defined as follows:
int wakka(const char *format, /* args*/ ...);

will this statement compile?

wakka("There are %d days in February");
"

Can you intuit the answer?

Philo

Philo
Wednesday, December 3, 2003