Proficient at C

[jaysome]

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

I can think of one good question:

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

What other good simple, basic questions are there (e.g., don't cast
malloc)?

Thanks
--
jay

BTW, the correct answer to the above question is A, C, E and F.

[Walter Roberson]

Re: Proficient at C

In article <55qu44hqk2ls6b 5mr41uo0dqkgvth heuns@4ax.com>,
jaysome <jaysome@hotmai l.comwrote:

>I can think of one good question:

>Which of the following definitions of main are acceptable by a
>portable Standard C implementation?

>A. int main(void) { /*...*/ }
>B. void main(void) { /*...*/ }
>C. int main(int argc, char *argv[]) { /*...*/ }
>D. void main(int argc, char *argv[]) { /*...*/ }
>E. int main(int argc, char **argv) { /*...*/ }
>F. int main(int count, char **args) { /*...*/ }
>G. None of the above.
>H. All of the above.

>BTW, the correct answer to the above question is A, C, E and F.

It depends which version of the Standard the implementation adheres
to. None of your definitions return a value from main, so the
behaviour is implementation defined (or is it undefined, I'd have
to check the exact wording) in C89/C90. In C99 such cases automatically
return 0 from main, rendering the behaviour well-defined.

--
"We may gather out of history a policy, by the comparison and
application of other men's forepassed miseries with our own like
errors and ill deservings." -- Sir Walter Raleigh

[Dan]

Re: Proficient at C


"jaysome" <jaysome@hotmai l.comwrote in message
news:55qu44hqk2 ls6b5mr41uo0dqk gvthheuns@4ax.c om...

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.
>
For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?
>
I can think of one good question:
>
Which of the following definitions of main are acceptable by a
portable Standard C implementation?
>
A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.
>
What other good simple, basic questions are there (e.g., don't cast
malloc)?

I think it WAY more important to get people who can acutally program rather
than those who remember some of the finer points of a language. I had people
who didn't know what a function pointer were who were way better coders and
knew how to look up something and learn it when they didn't know. All the
people who did know knew everything about C, but had no clue how to use it
to actually solve a problem. I would focus questions more around how they
would implement an algorithm or solve a problem. How they would use dynamic
allocation and linked lists etc. What they would do to look up a stdlib
function to see how it works. Where to look to make sure something is
portable etc. Maybe im just saying that because I coded C for years without
knowing only C was valid and E wasn't.

[Richard Heathfield]

Re: Proficient at C

jaysome said:

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.
>
For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?
>
I can think of one good question:
>
Which of the following definitions of main are acceptable by a
portable Standard C implementation?
>
A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

A, C, E, F, although for maximum acceptabilititu de you will want to put a
return statement in between those braces...

I would extend the list to include a const modifier for argv, and if anyone
specifically marked it either as /right/ or as /wrong/ (as opposed to just
choosing G or H), I'd ask them why. They might well get the acceptability
aspect wrong, but for an excellent reason. Remember, you're not after
perfection, but after proficiency.

Otherwise, the above question doesn't really deal with proficiency, although
it does help you to weed out the incompetent.

What other good simple, basic questions are there (e.g., don't cast
malloc)?

Well, you could word it better than that. For example: "the practice of
casting the return value of functions returning void *, such as malloc, is
ancient and widespread. Is this necessary? If so, why? If not, why not? Was
it ever necessary in the past? If so, why? Is it good practice? If so, why?
If not, why not?"

Here's another, which is in several parts.

Consider a frame buffer that is described by the following data structure:

struct gfx_fb_
{
unsigned long **buffer;
size_t rows;
size_t columns;
};

typedef struct gfx_fb_ gfx_fb;

Pixel (x, y) is represented by buffer[y][x].

You have five minutes. Write a function with this interface:

int floodfill(gfx_f b *fb, size_t x, size_t y, unsigned long colour);

to replace a contiguous patch of colour with the new colour passed in as the
fourth parameter.

(Obviously we can't expect a perfect job in five minutes, but we'd expect the
basics. Almost certainly the candidate will go for the naive recursive
implementation, on the grounds that anything else is likely to take him more
than five minutes!)

Follow-up (and this is the important one): look at the code you've just
written - what would you say is wrong with it?

A proficient C programmer will:

* point out any obvious syntax bugs, basically doing a quick clc on it;
* show how the recursion is broken (if indeed it is);
* explain how, given more time, he would make the function more robust (for
example, does the code "fall off" the edge of the image? Not to worry if it
does, but does he *spot* that it does?);
* illustrate how the efficiency might be improved.

What you're looking for here is the ability to criticise one's own code, which
is all too rare but absolutely essential. You are also looking for the
ability to produce code quickly. The floodfill example is a good one because
the candidate won't need much in the way of library calls. (In fact, he
shouldn't need to look up anything at all.)

Then you might want to ask him a similar question that /maximises/ the need to
look stuff up. Write something meaningful but scary-looking using functions
such as strpbrk, strtok(!), fmod and modf (definitely both of these), and
perhaps div, and ask him to modify the code to add such-and-such a feature.
Have a K&R right there on the desk, but don't mention it to him. See if he
asks whether he can use it. (The right candidate will do so, unless he has a
phenomenal memory.) How often does he need to consult the book? How quickly
does he find stuff? How well does he interpret what he reads?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Antoninus Twink]

Re: Proficient at C

On 11 Jun 2008 at 7:19, Dan wrote:

All the people who did know knew everything about C, but had no clue
how to use it to actually solve a problem.

Welcome to clc.

[Eric Sosman]

Re: Proficient at C

jaysome wrote:

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.
>
For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

1: "Describe some work you've done in C, paying special
attention to the part that was most difficult. Why was
it difficult, how did you deal with the difficulty, and
if it were possible to do the project all over again from
scratch what would you do differently?"

2: "List all the Standard-defined macros whose names
incorporate an odd number of lower-case letters."

3: "If you were assessing someone's proficiency in C,
would questions of type 1 or of type 2 be more revealing?
Discuss."

--
Eric Sosman
esosman@ieee-dot-org.invalid

[noagbodjivictor@gmail.com]

Re: Proficient at C

On Jun 11, 8:41 am, Eric Sosman <esos...@ieee-dot-org.invalidwrot e:

jaysome wrote:

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

>

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

>
     1: "Describe some work you've done in C, paying special
attention to the part that was most difficult.  Why was
it difficult, how did you deal with the difficulty, and
if it were possible to do the project all over again from
scratch what would you do differently?"
>
     2: "List all the Standard-defined macros whose names
incorporate an odd number of lower-case letters."
>
     3: "If you were assessing someone's proficiency in C,
would questions of type 1 or of type 2 be more revealing?
Discuss."
>
--
Eric Sosman
esos...@ieee-dot-org.invalid

Why make the interview difficult? :)

[Paul Hsieh]

Re: Proficient at C

On Jun 11, 12:24 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

jaysome said:

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

>

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

Ask them to write a function which *outputs* a string. How they
handle pointers and storage is key to demonstrating their
understanding of how to program in C.

I can think of one good question:

>

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

>

A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

This is not a good question. Whatever your compiler accepts is good
enough, and if another doesn't this couldn't be more than a 10 second
fix. There are cases where being pedantic about the standard is so
truly and utterly useless. This is one of of those cases.

If you care to address the standard, throw in a third parameter that
represents the environment variables and ask the candidate to address
that.

A, C, E, F, although for maximum acceptabilititu de you will want to put a
return statement in between those braces...
>
I would extend the list to include a const modifier for argv, and if anyone
specifically marked it either as /right/ or as /wrong/ (as opposed to just
choosing G or H), I'd ask them why. They might well get the acceptability
aspect wrong, but for an excellent reason. Remember, you're not after
perfection, but after proficiency.
>
Otherwise, the above question doesn't really deal with proficiency, although
it does help you to weed out the incompetent.
>

What other good simple, basic questions are there (e.g., don't cast
malloc)?

This question is unlikely to be very good at discerning the ability of
someone to program. However, if you have a candidate that insists
that putting this cast is a bad idea, you should probably consider
walking the candidate out immediately. That kind of ideologue
especially going the wrong way, is likely to be a problem candidate.

Well, you could word it better than that. For example: "the practice of
casting the return value of functions returning void *, such as malloc, is
ancient and widespread. Is this necessary? If so, why? If not, why not? Was
it ever necessary in the past? If so, why? Is it good practice? If so, why?
If not, why not?"

In other words, has the candidate heard of the C++ programming
language. But the OP has not listed that as amongst his criteria.

Here's another, which is in several parts.
>
Consider a frame buffer that is described by the following data structure:
>
struct gfx_fb_
{
unsigned long **buffer;
size_t rows;
size_t columns;
>
};
>
typedef struct gfx_fb_ gfx_fb;
>
Pixel (x, y) is represented by buffer[y][x].
>
You have five minutes. Write a function with this interface:
>
int floodfill(gfx_f b *fb, size_t x, size_t y, unsigned long colour);
>
to replace a contiguous patch of colour with the new colour passed in as the
fourth parameter.
>
(Obviously we can't expect a perfect job in five minutes,

int floodfill (gfx_fb *fb, size_t x, size_t y, unsigned long colour) {
int counter;
unsigned long currentColor;

if (NULL == fb || x < 0 || y < 0 || x >= fb->columns || y >= fb-

>rows)

return 0;

currentColor = fb->buffer[y][x];

if (currentColor == colour) return 0;
fb->buffer[y][x] = colour;
counter = 1;
if (y 0 && currentColor == fb->buffer[y-1][x])
counter += floodfill (fb, x, y-1, colour);
if (y < fb->rows - 1 && currentColor == fb->buffer[y+1][x])
counter += floodfill (fb, x, y+1, colour);
if (x 0 && currentColor == fb->buffer[y][x-1])
counter += floodfill (fb, x-1, y, colour);
if (x < fb->columns - 1 && currentColor == fb->buffer[y][x+1])
counter += floodfill (fb, x+1, y, colour);

return counter;
}

About 2-3 minutes?

[...] but we'd expect the
basics. Almost certainly the candidate will go for the naive recursive
implementation, on the grounds that anything else is likely to take him more
than five minutes!)

Sure.

Follow-up (and this is the important one): look at the code you've just
written - what would you say is wrong with it?

Its fully recursive. By changing the interface, its possible to
remove the redundant pixel reads and redundant coordinate bounds
checking. You didn't say what you wanted returned; i just assumed
"number of pixels updated" was good enough.

A proficient C programmer will:
>
* point out any obvious syntax bugs, basically doing a quick clc on it;

Its hard for me to judge myself on this. But that's what compilers
are for.

* show how the recursion is broken (if indeed it is);

I highly doubt that it is.

* explain how, given more time, he would make the function more robust (for
example, does the code "fall off" the edge of the image? Not to worry if it
does, but does he *spot* that it does?);

Unless I have made a mistake, the code is robust. (Aren't tautologies
awesome?)

* illustrate how the efficiency might be improved.

A hand generated stack would work just fine (this is a case where a
block based memory pool/arena allocator is much better than straight
malloc). You would also want to be clever in doing horizontal spans
in terms of direct fills as well as what you put into your hand
generated stack.

The result would be somewhat complicated. Designing a unit test for
it does not seem that complicated -- but its not clear how good
coverage you can get in a reasonable amount of CPU cycles.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/

[Ben Bacarisse]

Re: Proficient at C

Paul Hsieh <websnarf@gmail .comwrites:

On Jun 11, 12:24 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

<snip>

>Well, you could word it better than that. For example: "the practice of
>casting the return value of functions returning void *, such as malloc, is
>ancient and widespread. Is this necessary? If so, why? If not, why not? Was
>it ever necessary in the past? If so, why? Is it good practice? If so, why?
>If not, why not?"

>
In other words, has the candidate heard of the C++ programming
language. But the OP has not listed that as amongst his criteria.

That is not the only reason why it is/was widespread. It took me ages to
unlearn it since it was common in K&R C (malloc returned a char *).
Of course knowing this history favours a particular kind of applicant
which the OP might or might not want!

--
Ben.

[Richard Heathfield]

Re: Proficient at C

Paul Hsieh said:

On Jun 11, 12:24 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

>jaysome said:

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

>>

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

>
Ask them to write a function which *outputs* a string. How they
handle pointers and storage is key to demonstrating their
understanding of how to program in C.

This is like void main - only a truly incompetent programmer could foul it up.

I can think of one good question:

>>

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

>>

<snip>

>
This is not a good question.

Agreed...

Whatever your compiler accepts is good enough,

Much laughing. So a Fortran program is good enough, provided you're using a
compiler that accepts Fortran? I Don't Think So.

and if another doesn't this couldn't be more than a 10 second
fix. There are cases where being pedantic about the standard is so
truly and utterly useless. This is one of of those cases.

Portability has its benefits, whether you realise it or not.

<snip>

What other good simple, basic questions are there (e.g., don't cast
malloc)?

>
This question is unlikely to be very good at discerning the ability of
someone to program.

Agreed.

However, if you have a candidate that insists
that putting this cast is a bad idea, you should probably consider
walking the candidate out immediately.

If you insist on disagreeing with the candidate, then yes, of course, thank
him for his time and let him go - there's no point hiring a bright guy if
you're not going to listen to him.

That kind of ideologue
especially going the wrong way, is likely to be a problem candidate.

So you think of "getting it right for good reason" as being an ideology, and
presumably an ideology with which you disagree? Well, so be it.

<snip>

>(Obviously we can't expect a perfect job in five minutes,

>
int floodfill (gfx_fb *fb, size_t x, size_t y, unsigned long colour) {
int counter;
unsigned long currentColor;
>
if (NULL == fb || x < 0 || y < 0

Two wasted tests. x and y are unsigned types. But you will be pleased to hear
that the code does actually do its job, albeit rather slowly.

About 2-3 minutes?

A candidate who wasted his spare time staring into space instead of finding
those redundant tests would not be doing himself any favours.

>

>[...] but we'd expect the
>basics. Almost certainly the candidate will go for the naive recursive
>implementation , on the grounds that anything else is likely to take him
>more than five minutes!)

>
Sure.
>

>Follow-up (and this is the important one): look at the code you've just
>written - what would you say is wrong with it?

>
Its fully recursive.

Right.

By changing the interface, its possible to
remove the redundant pixel reads and redundant coordinate bounds
checking.

You don't need to change the interface to at least make a start on that. (I
won't explain further, because you explained it yourself - "direct fills" -
further on in your article.)

>A proficient C programmer will:
>>
>* point out any obvious syntax bugs, basically doing a quick clc on it;

>
Its hard for me to judge myself on this. But that's what compilers
are for.
>

>* show how the recursion is broken (if indeed it is);

>
I highly doubt that it is.

It isn't. You actually did a rather fine job, given the limited time. But then
I don't think anybody ever accused you of being incompetent.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Malcolm McLean]

Re: Proficient at C


"jaysome" <jaysome@hotmai l.comwrote in message news:

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.
>
For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?
>
I can think of one good question:
>
Which of the following definitions of main are acceptable by a
portable Standard C implementation?
>
A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.
>
What other good simple, basic questions are there (e.g., don't cast
malloc)?
>

There's no point asking trivia about the C standard. Someone might be a very
good C programmer but simply never have used the language in an environment
where strict adherence was important. As for casting malloc(), people will
disagree - I myself have been converted to the non-casting party.

If you want a binary proficient / non-proficient test, prpeare a couple of
files with employee first name, employee surname, and salary. Give the
candidate the first file and a computer and ask him to produce a program to
read in the data, sort by salary, and produce an output file.
This tests structures, basic IO, malloc() and realloc(), and function
pointers. To avoid wasting his time on reading variable-length strings,
specify a maximum name length.
Use the second file to verify that the program works as specified.

Note that this test tells you whether someone is proficient in C or not. It
doesn't tell you how good the person is. It's an artificial environment;
possibly unfamiliar editor, lots of stress, and a time limit (even if you
don't set one it's kind of implied that the program has to be knocked up
quickly), but it's a bread and butter type task any C programmer ought to be
able to do.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Paul Hsieh]

Re: Proficient at C

On Jun 11, 9:25 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

Paul Hsieh said:

On Jun 11, 12:24 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

jaysome said:
When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or
something to that extent.

>

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

>

Ask them to write a function which *outputs* a string. How they
handle pointers and storage is key to demonstrating their
understanding of how to program in C.

>
This is like void main - only a truly incompetent programmer could foul it
up.

Right, but I need to know whether the candidate deals with string at
the average level of people who post here in c.l.c. or whether they
are a candidate worthy of real consideration. Some people don't get
the fact that you cannot return a string that you declared as an array
in the inside of your function, or that use of statics inhibit multi-
threading. Enough people that its worth testing that.

I can think of one good question:

>

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

>
<snip>
>

This is not a good question.

>
Agreed...
>

Whatever your compiler accepts is good enough,

>
Much laughing. So a Fortran program is good enough, provided you're using
a compiler that accepts Fortran? I Don't Think So.

Which of the options listed (that you have deleted from the thread, of
course) do you think a Fortran compiler will accept?

and if another doesn't this couldn't be more than a 10 second
fix. There are cases where being pedantic about the standard is so
truly and utterly useless. This is one of of those cases.

>
Portability has its benefits, whether you realise it or not.

*Cough* straw man *cough*.

What other good simple, basic questions are there (e.g., don't cast
malloc)?

>

This question is unlikely to be very good at discerning the ability of
someone to program.

>
Agreed.
>

However, if you have a candidate that insists
that putting this cast is a bad idea, you should probably consider
walking the candidate out immediately.

>
If you insist on disagreeing with the candidate, then yes, of course,
thank him for his time and let him go - there's no point hiring a bright
guy if you're not going to listen to him.

"Bright guys" besides being a subjective turn, can do all sort of
intolerably wrong things (there is even a movie about this based on
the book: "The Smartest Guys in the Room" that is worth watching).
Productivity, and understanding the real world of coding (not this
strange fantasy world that CLC seems to operate in) kind of matters.
Code may and likely will migrate to C++, that's just a general
principle that people should be aware of, that's far more important
that someone's bad argument for avoiding a useful cast.

That kind of ideologue
especially going the wrong way, is likely to be a problem candidate.

>
So you think of "getting it right for good reason" as being an ideology,
and presumably an ideology with which you disagree? Well, so be it.

Whatever, I only have evidence and measurable data on my side. (I
have never written a line of C code in my professional code that
didn't eventually get handed to a compiler that could do, or *did* do C
++.)

<snip>
>

(Obviously we can't expect a perfect job in five minutes,

>

int floodfill (gfx_fb *fb, size_t x, size_t y, unsigned long colour) {
int counter;
unsigned long currentColor;

>

if (NULL == fb || x < 0 || y < 0

>
Two wasted tests. x and y are unsigned types.

You have to be kidding me. There is a *GARGANTUAN* amount of waste in
my routine, even ignoring the recursion, and you managed to isolate
the most irrelevant? (And if you look again, it does appear to be
*three* wasted tests, as fb cannot spontaneously become NULL as it
gets passed recursively.) In graphics, you tend to ignore these
things when bandwidth to pixel data is a factor.

Look, like many of the other problems with my solution, the originally
proposed *INTERFACE* limits my ability to do this right. In this
case, you went and made the coordinates unsigned for some bizarre
reason. Anyone who knows basic graphics or has been in the graphics
industry for even a short time knows that you never do this -- it will
muck up all of your standard clip algorithms. My natural tendency is
to do things as they are really meant to be done and ignore errors in
design; in this case the prototype.

If that was supposed to be "a trick question" kind of thing, it seems
like a fairly shallow and also valueless trick (its not like array
reversal, where the trick of making sure your index only goes half way
through is fundamental to getting it right.)

[...] But you will be pleased to hear
that the code does actually do its job, albeit rather slowly.
>

About 2-3 minutes?

>
A candidate who wasted his spare time staring into space instead of
finding those redundant tests would not be doing himself any favours.

As opposed to the time I spent agonizing over this interface and how
it forces me to read back each pixel at least twice? You have a
bizarre sense of priority.

[...] but we'd expect the
basics. Almost certainly the candidate will go for the naive recursive
implementation, on the grounds that anything else is likely to take him
more than five minutes!)

>

Sure.

>

Follow-up (and this is the important one): look at the code you've just
written - what would you say is wrong with it?

>

Its fully recursive.

>
Right.
>

By changing the interface, its possible to
remove the redundant pixel reads and redundant coordinate bounds
checking.

>
You don't need to change the interface to at least make a start on that.
(I won't explain further, because you explained it yourself - "direct
fills" - further on in your article.)

No what I meant was that the interface should include the color from,
use *signed* integer coordinates, and guarantee that the incoming
coordinates are in bounds. Look closely. My solution reads each
pixel twice (once to decide whether it should recursively flood fill
there, and once to figure out which color its trying to match) and it
checks for being in-bounds twice (once upon input, and once for each
of the four recursions.)

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/

[Richard Heathfield]

Re: Proficient at C

Malcolm McLean said:

<snip>

If you want a binary proficient / non-proficient test, prpeare a couple of
files with employee first name, employee surname, and salary. Give the
candidate the first file and a computer and ask him to produce a program to
read in the data, sort by salary, and produce an output file.
This tests structures, basic IO, malloc() and realloc(), and function
pointers.

<snip>

Note that this test tells you whether someone is proficient in C or not.

Or rather, his knowledge of sort(1)'s -g and -k switches. :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Re: Proficient at C

Paul Hsieh said:

On Jun 11, 9:25 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

>Paul Hsieh said:

<snip>

<main>

Whatever your compiler accepts is good enough,

>>
>Much laughing. So a Fortran program is good enough, provided you're using
>a compiler that accepts Fortran? I Don't Think So.

>
Which of the options listed (that you have deleted from the thread, of
course)

The deletion is not malicious. We both know what we're talking about.

do you think a Fortran compiler will accept?

Well, gcc will accept several of them, and that's a Fortran compiler, right?
Once you step outside the rules of C, you're not really testing C knowledge
any more.

and if another doesn't this couldn't be more than a 10 second
fix. There are cases where being pedantic about the standard is so
truly and utterly useless. This is one of of those cases.

>>
>Portability has its benefits, whether you realise it or not.

>
*Cough* straw man *cough*.

Not at all. You claim that this whole main() thing is one of the cases where
being pedantic about the Standard is truly and utterly useless, whereas in
fact it's one of those cases where knowing the language spec allows you to
write a maximally portable entry point for your program - so as far as I can
see, your claim is simply wrong. Not a strawman in sight.

<casting malloc>

However, if you have a candidate that insists
that putting this cast is a bad idea, you should probably consider
walking the candidate out immediately.

>>
>If you insist on disagreeing with the candidate, then yes, of course,
>thank him for his time and let him go - there's no point hiring a bright
>guy if you're not going to listen to him.

>
"Bright guys" besides being a subjective turn,

And "ideologue" isn't?

><snip>
>>

>(Obviously we can't expect a perfect job in five minutes,

>>

int floodfill (gfx_fb *fb, size_t x, size_t y, unsigned long colour) {
int counter;
unsigned long currentColor;

>>

if (NULL == fb || x < 0 || y < 0

>>
>Two wasted tests. x and y are unsigned types.

>
You have to be kidding me. There is a *GARGANTUAN* amount of waste in
my routine, even ignoring the recursion, and you managed to isolate
the most irrelevant?

You mentioned all the others yourself, right? So what's the point in telling
you about those?

(And if you look again, it does appear to be
*three* wasted tests, as fb cannot spontaneously become NULL as it
gets passed recursively.)

Well, it's not wasted on the *first* call. (The fix is obvious.)

<snip>

You have a bizarre sense of priority.

I think it's very, very fortunate that we don't work at the same place. We'd
drive each other nuts within a week.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Re: Proficient at C

noagbodjivictor @gmail.com wrote:

On Jun 11, 8:41 am, Eric Sosman <esos...@ieee-dot-org.invalidwrot e:

>jaysome wrote:

>>When we are looking to hire C programmers, we inevitably receive
>>resumes from people who claim they are "proficient at C", or something
>>to that extent.
>>For those who claim they are "proficient at C", what are some good
>>questions to ask them to determine if they are really "proficient at
>>C", as they claim?

> 1: "Describe some work you've done in C, paying special
>attention to the part that was most difficult. Why was
>it difficult, how did you deal with the difficulty, and
>if it were possible to do the project all over again from
>scratch what would you do differently?"
>>
> 2: "List all the Standard-defined macros whose names
>incorporate an odd number of lower-case letters."
>>
> 3: "If you were assessing someone's proficiency in C,
>would questions of type 1 or of type 2 be more revealing?
>Discuss."
>>

>
Why make the interview difficult? :)

Mwahh-hahh-hah-ha-heeeeeeheeehee!

Seriously, closed-end questions are self-limiting in that
they can elicit only closed-end answers. With questions of the
kind the O.P. illustrated, you might as well give each applicant
a multiple-guess quiz and add up the scores; write a computer
program to administer and score the quiz and you never even need
to take time to meet the applicant at all. Since your company
no longer needs your services as an interviewer of applicants,
you may find yourself pounding the pavement and trying to score
well on multiple-guess quizzes ...

--
Eric Sosman
esosman@ieee-dot-org.invalid