Entry level C test? 
Author Message
 Entry level C test?

Over the past decade or so I've been asked to judge the qualifications
of about a dozen or so people applying for entry level C programming
positions. At one point I started writing up a formal test, with a
series of questions in order of increasing difficulty. However, I got
discouraged when I discovered that I couldn't find anyone who could
answer what I thought was the simplest part of my test:

Given:
        void myfunc(char *p, char *q)
        {
                while(*p++ = *q++);
        }

1. What does myfunc() do?

2. Explain how myfunc() does it.

3. Can you suggest possible improvements to myfunc()?

I added number 3 only recently, when for the first time I was given
permission to hire a senior C programmer. I had high hopes that I would
find several applicants who could answer the first two questions, and I
was hoping that I would be able to distinguish between them by how well
they answered number 3. No such luck. Two interviews so far, and neither
could even correctly answer #1. To be fair, while they were both senior
programmers, they both had more, and more recent, experience with
fortran than with C.

Are these questions really so difficult? I could have answered the first
two questions right off the bat, after my first read of K&R, before I
even wrote my first program in C (yes, I did read the whole book before
writing a single line of code - that's the way I do things, for better
or for worse). It's almost straight out of chapter 5 of my copy (1st
edition).
--



Sun, 20 Apr 2003 08:32:29 GMT  
 Entry level C test?

Quote:

> Over the past decade or so I've been asked to judge the
> qualifications of about a dozen or so people applying for
> entry level C programming positions. At one point I started
> writing up a formal test, with a series of questions in
> order of increasing difficulty. However, I got discouraged
> when I discovered that I couldn't find anyone who could
> answer what I thought was the simplest part of my test:

> Given:
>         void myfunc(char *p, char *q)
>         {
>                 while(*p++ = *q++);
>         }

> 1. What does myfunc() do?

Takes two arguments that are of type "pointer to char",
implicitly assumes that (a) they both point to valid
memory, (b) that the second argument, named q, points
to a valid NULL-terminated string, and (c) the storage
space pointed to by p is large enough to contain all
the data pointed to by q. Copies the data pointed to
by q into the memory area pointed to by p, including
the terminating NULL.

Quote:
> 2. Explain how myfunc() does it.

The assignment is performed within the test of a while
loop with no body. What this means is that so long as
the assignment operation lvalue (the value pointed to
by p after being assigned from the value pointed to by
q) is nonzero, the assignment will be repeatedly...
repeated. Each execution of the assignment will, because
of the "++" postfix on both variables, cause p and q to
be incremented after each assignment. Thus, after each
iteration, p will point to the next character in memory
to which to write, and q will point to the next character
from which to read. When the NULL is reached, and copied,
the test will fail, terminating the while loop, and the
function.

Quote:
> 3. Can you suggest possible improvements to myfunc()?

Have it test p and q to see if they are NULL, before trying
to dereference them. Have the function return a value, possibly
to indicate how many characters were copied, or a -1 to indicate
that a NULL was passed and the function didn't attempt a copy.
Use strcpy() instead if this function, or possibly memcpy()
or memmove().

- Show quoted text -

Quote:
> I added number 3 only recently, when for the first time
> I was given permission to hire a senior C programmer. I
> had high hopes that I would find several applicants who
> could answer the first two questions, and I was hoping
> that I would be able to distinguish between them by how
> well they answered number 3. No such luck. Two interviews
> so far, and neither could even correctly answer #1. To be
> fair, while they were both senior programmers, they both
> had more, and more recent, experience with Fortran than
> with C.

> Are these questions really so difficult? I could have
> answered the first two questions right off the bat, after
> my first read of K&R, before I even wrote my first program
> in C (yes, I did read the whole book before writing a
> single line of code - that's the way I do things, for better
> or for worse). It's almost straight out of chapter 5 of my
> copy (1st edition).

Personally, I found question three easier to answer than question two.
And I never really finished reading the K&R book...

-Ed
--



Tue, 22 Apr 2003 04:04:06 GMT  
 Entry level C test?


Quote:
>Over the past decade or so I've been asked to judge the qualifications
>of about a dozen or so people applying for entry level C programming
>positions. At one point I started writing up a formal test, with a
>series of questions in order of increasing difficulty. However, I got
>discouraged when I discovered that I couldn't find anyone who could
>answer what I thought was the simplest part of my test:

I thought you said entry level programmers. Why then choose an idiom
that is easy to those who have had to use it and quite hard if you have
never seen it before.

I would be quite happy for an entry level programmer to know how to use
strcpy correctly without being able to implement it.

I think your problem is that you started with what you are familiar with
and assumed that would be definitive of a good programmer.

Quote:

>Given:
>                                       void myfunc(char *p, char *q)
>                                       {
>                                               while(*p++ = *q++);
>                                       }

>1. What does myfunc() do?

Re-invents the wheel, badly because the function name, and parameter
names are poorly chosen.

Quote:

>2. Explain how myfunc() does it.

Why not ask what assumptions it makes?

Quote:

>3. Can you suggest possible improvements to myfunc()?

Of course, but I would not bother as there are perfectly good
implementations in the Standard C Library.

Quote:

>I added number 3 only recently, when for the first time I was given
>permission to hire a senior C programmer. I had high hopes that I would
>find several applicants who could answer the first two questions, and I
>was hoping that I would be able to distinguish between them by how well
>they answered number 3. No such luck. Two interviews so far, and neither
>could even correctly answer #1. To be fair, while they were both senior
>programmers, they both had more, and more recent, experience with
>Fortran than with C.

Which seems a very poor qualification if you need low level C
programmers.

Quote:

>Are these questions really so difficult? I could have answered the first
>two questions right off the bat, after my first read of K&R, before I
>even wrote my first program in C (yes, I did read the whole book before
>writing a single line of code - that's the way I do things, for better
>or for worse). It's almost straight out of chapter 5 of my copy (1st
>edition).

Exactly, but if you have not read K&R you might well never have come
across it. So you first interview question might be 'Have you ever read
'The C programming Language'? If 'yes', ask which edition.

Francis Glassborow                      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA                                  +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
--



Tue, 22 Apr 2003 04:17:00 GMT  
 Entry level C test?

Quote:

>    void myfunc(char *p, char *q)
>    {
>            while(*p++ = *q++);
>    }

> 1. What does myfunc() do?

strcpy()

Quote:
> 2. Explain how myfunc() does it.

Increases the pointers in parallel, copying as it goes, until it copies
a null character.

Quote:
> 3. Can you suggest possible improvements to myfunc()?

- test for null pointers and bail if found;
- copout: use strcpy() itself;
- depending on the system, using strlen() and memmove() might be faster.

Quote:
> Are these questions really so difficult?

No. This should be a prima vista stuff.

Richard
--



Tue, 22 Apr 2003 04:17:57 GMT  
 Entry level C test?
I have taken a first course in C (about 5 years ago) after many years
writing Fortran, then bought K&R 2nd ed and used C in some significant but
not complicated programs. In fact I tend to keep the source simple even
if using clever constructs would make the program shorter or faster -
it only needs to be fast enough. So I would describe myself as an
advanced beginner in C with a history of Fortran and with an
awareness of the kinds of problems that C can cause.

My first reaction was: it copies a string, ending when it meets a null in
the source string, which is pointed to by q. Then I thought that's so
obvious, maybe there's a trick such as an unexpected effect of the
precedence of * and ++. So, as I write this line, I'm looking it up in
K&R 2nd ed page 52, then chapter 5. On p 95 I find I was correct, and
in *p++=*q++ each pointer is incremented after copying across the "=".
So my answers:
1. It copies a string (sequence of char) pointed to by q into memory
starting where p points.
2. args *p and *q are pointers to char. The exprn inside the while()
both copies across the "=" sign, increments the pointers and returns the
value of the char copied as the value tested by "while" After a null has
been copied, the "while" sees it as False and terminates.
3. Improvements: check that p and q aren't null pointers. Perhaps limit
the number of chars copied. Make myfunc return an int so it can
return a status, e.g. to say whether anything was copied.

What marks do I get? Is this really difficult for the average or not-quite-
beginner C programmer?

BTW: What sort of wrong answers do you get to question 1? (or is
mine one of them?) Now I turn to K&R p 96 & I see that I was correct
on question 1.

--
Oliver Walter (speaking for myself, not my employer)
Alenia Marconi Systems
Borehamwood, UK
email (anti-spam coded, obvious interpretation):
oliver DOT walter AT gecm DOT com


Quote:
> Over the past decade or so I've been asked to judge the qualifications
> of about a dozen or so people applying for entry level C programming
> positions. At one point I started writing up a formal test, with a
> series of questions in order of increasing difficulty. However, I got
> discouraged when I discovered that I couldn't find anyone who could
> answer what I thought was the simplest part of my test:

> Given:
> void myfunc(char *p, char *q)
> {
> while(*p++ = *q++);
> }

> 1. What does myfunc() do?

> 2. Explain how myfunc() does it.

> 3. Can you suggest possible improvements to myfunc()?

> I added number 3 only recently, when for the first time I was given
> permission to hire a senior C programmer. I had high hopes that I would
> find several applicants who could answer the first two questions, and I
> was hoping that I would be able to distinguish between them by how well
> they answered number 3. No such luck. Two interviews so far, and neither
> could even correctly answer #1. To be fair, while they were both senior
> programmers, they both had more, and more recent, experience with
> Fortran than with C.

> Are these questions really so difficult? I could have answered the first
> two questions right off the bat, after my first read of K&R, before I
> even wrote my first program in C (yes, I did read the whole book before
> writing a single line of code - that's the way I do things, for better
> or for worse). It's almost straight out of chapter 5 of my copy (1st
> edition).

--



Tue, 22 Apr 2003 04:19:13 GMT  
 Entry level C test?
-----BEGIN PGP SIGNED MESSAGE-----



Quote:
>Over the past decade or so I've been asked to judge the qualifications
>of about a dozen or so people applying for entry level C programming
>positions. At one point I started writing up a formal test, with a
>series of questions in order of increasing difficulty. However, I got
>discouraged when I discovered that I couldn't find anyone who could
>answer what I thought was the simplest part of my test:

>Given:
>    void myfunc(char *p, char *q)
>    {
>            while(*p++ = *q++);
>    }

>1. What does myfunc() do?

>2. Explain how myfunc() does it.

>3. Can you suggest possible improvements to myfunc()?
[...]
>Are these questions really so difficult? I could have answered the first
>two questions right off the bat, after my first read of K&R, before I
>even wrote my first program in C (yes, I did read the whole book before
>writing a single line of code - that's the way I do things, for better
>or for worse). It's almost straight out of chapter 5 of my copy (1st
>edition).

Well, I'm kind of rusty at this (I'm stuck orking with perl and
java these days), and I normally favor explicit parentheses so
I had to think about the the precedence for a few minutes,
BUT... no, it's not difficult.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1

iQCVAwUBOgC8PopCfoshjxMpAQF84wQAhTx8e5/BLu2y3gXwx4tl4jBbTfVtwuqH
MAd/SOTKvq3jjz6ADTJyANsLig0Dn3A7D9bSRo+ohGUKTMejJNugAA/hkdUS6OGq
qqus+tkGJ4iOt+vdOgYzqSv+OkQyAFWgA9rzJTQLkoVIMhEjnpgTNRSNXEmAxRBI
ozF3w4DMdlQ=
=8Lqy
-----END PGP SIGNATURE-----
--

PGP key fingerprint = 48 94 7A 54 59 B6 C0 77  1F F6 94 55 0C 55 51 C4
"...and so the m{*filter*}of the story is: Always make backups."
"But that was the m{*filter*}last night, and the night before that too!"
--



Tue, 22 Apr 2003 04:19:33 GMT  
 Entry level C test?


Quote:
>Over the past decade or so I've been asked to judge the qualifications
>of about a dozen or so people applying for entry level C programming
>positions. At one point I started writing up a formal test, with a
>series of questions in order of increasing difficulty. However, I got
>discouraged when I discovered that I couldn't find anyone who could
>answer what I thought was the simplest part of my test:

>Given:
>    void myfunc(char *p, char *q)
>    {
>            while(*p++ = *q++);
>    }

>1. What does myfunc() do?

>2. Explain how myfunc() does it.

>3. Can you suggest possible improvements to myfunc()?

>I added number 3 only recently, when for the first time I was given
>permission to hire a senior C programmer. I had high hopes that I would
>find several applicants who could answer the first two questions, and I
>was hoping that I would be able to distinguish between them by how well
>they answered number 3. No such luck. Two interviews so far, and neither
>could even correctly answer #1. To be fair, while they were both senior
>programmers, they both had more, and more recent, experience with
>Fortran than with C.

>Are these questions really so difficult? I could have answered the first
>two questions right off the bat, after my first read of K&R, before I
>even wrote my first program in C (yes, I did read the whole book before
>writing a single line of code - that's the way I do things, for better
>or for worse). It's almost straight out of chapter 5 of my copy (1st
>edition).

Most "C" programmers I've encountered do not write idiomatic C.
They write a Fortran/Pascal version of the language (depending on
their vintage) with many more if, else and break statements than
a fluent C programmer would use. I'd say your test rates entry
level C programmers quite well. Also, if they can't answer 3,
they're probably not very good programmers in general.

Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada
--

                                use address above to reply
--



Tue, 22 Apr 2003 04:19:49 GMT  
 Entry level C test?

says...

Quote:
> Over the past decade or so I've been asked to judge the qualifications
> of about a dozen or so people applying for entry level C programming
> positions. At one point I started writing up a formal test, with a
> series of questions in order of increasing difficulty. However, I got
> discouraged when I discovered that I couldn't find anyone who could
> answer what I thought was the simplest part of my test:

> Given:
>    void myfunc(char *p, char *q)
>    {
>            while(*p++ = *q++);
>    }

> 1. What does myfunc() do?

Copies a string -- in fact, IIRC, other than the names, it's nearly a
verbatim copy from K&R.

Quote:
> 2. Explain how myfunc() does it.

I don't suppose you'd accept "fairly well" as an answer? <G>

Quote:
> 3. Can you suggest possible improvements to myfunc()?

Sure.  Eliminate it and use the strcpy in the library instead -- it
may not be smaller, faster, etc., but at least in some cases it will
be.  If you decide to retain the code, the first and most obvious
improvement would be to use meaningful names for the function and
variables (e.g. "copy_string", "dest" and "source").  If you wanted
to go further, it would be good to add a parameter for the maximum
size of the destination string.  This would also require adding some
more specification though -- specifically, whether the copy will be
zero terminated when/if it stops copying in the middle of a string.

Quote:
> Are these questions really so difficult? I could have answered the first
> two questions right off the bat, after my first read of K&R, before I
> even wrote my first program in C (yes, I did read the whole book before
> writing a single line of code - that's the way I do things, for better
> or for worse). It's almost straight out of chapter 5 of my copy (1st
> edition).

They sure don't look terribly difficult to me.  In fact, if this had
been posted by somebody whose name I didn't recognize, I'd probably
have guessed that it was a troll and wouldn't have bothered replying
at all.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
--



Tue, 22 Apr 2003 04:19:56 GMT  
 Entry level C test?
Quote:

> Given:
>         void myfunc(char *p, char *q)
>         {
>                 while(*p++ = *q++);
>         }
> 1. What does myfunc() do?

Emulates strcpy (but doesn't return a value).
Quote:
> 2. Explain how myfunc() does it.

Copies bytes via parallel pointers, which are incremented to access
successive bytes, until a 0-valued byte has been transferred.
Quote:
> 3. Can you suggest possible improvements to myfunc()?

Eliminate it and use standard strcpy() instead.
Rename it to something like my_strcpy().
Return a pointer (better pointing to final 0 byte than to beginning).
Change second parameter to const char *q.
Rename parameters to dst and src.
Change types to unsigned char to ensure correct operation on all values.
Move the semicolon to a line by itself (one more level of indentation).
Adopt local formatting conventions.
Make the test explicit:
        while ( (*dst = *src) != '\0' ) // '\0' terminates (included)
                ++dst, ++src;
Document the public interface (via intro comment block).
Quote:
> Are these questions really so difficult?

No, not if you're testing for competence in C programming.
As you said, you should expect correct answers to 1 and 2,
and can judge relative experience etc. by answers to 3.
I don't recommend relying entirely on a single test question;
when we were hiring at Geotronics we had a standard test with
several questions, not all of them linguistic.  For example
(adapted from an entrance exam at Decision Graphics):
        A windowing system needs to clip arbitrary line segments
        to rectangular windows so as not to draw outside the window.
        Solve this problem; state your assumptions.
The premise is that programmers who can't make any progress on such
problems cause more work than they alleviate.
--



Tue, 22 Apr 2003 04:20:11 GMT  
 Entry level C test?
...

Quote:
> What marks do I get? Is this really difficult for the average or not-quite-
> beginner C programmer?

Your answers are quite acceptable. You did many times better than any of
my applicants ever did. Of course, you were sitting at home, they were
at a job interview, which increases the stress levels.

Quote:
> BTW: What sort of wrong answers do you get to question 1? (or is

Most often, they say they have no idea what it does. The ones that can
articulate the cause of their confusion point to the use of an
assignment operator in a context that calls for a condition (not that
they understand standardese well enough to explain it in those terms). A
couple have claimed that it was a string compare, rather than a string
copy, which at leasts suggests familiarity with the idiom. However, even
they could not explain how it works, which means they had no chance of
catching their error.
--



Tue, 22 Apr 2003 12:14:43 GMT  
 Entry level C test?
...

Quote:
> They sure don't look terribly difficult to me.  In fact, if this had
> been posted by somebody whose name I didn't recognize, I'd probably
> have guessed that it was a troll and wouldn't have bothered replying
> at all.

I know what you mean. I have a lot of trouble understanding why our
applicants find this so difficult.
--



Tue, 22 Apr 2003 12:14:47 GMT  
 Entry level C test?

Quote:



...
> I thought you said entry level programmers. Why then choose an idiom
> that is easy to those who have had to use it and quite hard if you have
> never seen it before.

Because I considered it so elementary that I expected they would have
seen it already, long before they would consider themselves ready to be
paid for their programming skills. It's in K&R (or at least in my copy
of the 1st edition), and I understood every aspect of C described in
that book before I started my first paid programming job. I didn't
understand Unix, or libraries, or de{*filter*}s, or compiler/linker options,
or makefiles, but I understood the C language itself.

Quote:
> I would be quite happy for an entry level programmer to know how to use
> strcpy correctly without being able to implement it.

> I think your problem is that you started with what you are familiar with
> and assumed that would be definitive of a good programmer.

That could be - that's the essence of my question: is my test
appropriate for entry level programmers? So far, you seem to be in the
minority that says "no". My actual experience with using this test
unfortunately inclines me to agree with you, against the majority.

...

Quote:
> >1. What does myfunc() do?
> Re-invents the wheel, badly because the function name, and parameter
> names are poorly chosen.

The names were deliberately obscure. The test was intended to determine
if they could understood the C language; not whether they could make
reasonable guesses based upon function and parameter names. I agree with
your comments, and they're precisely the kind of thing I'm looking for
as an answer to question 3.

...

Quote:
> Which seems a very poor qualification if you need low level C
> programmers.

They were the best applicants I've found so far in our price range :-(.
Worse yet, for this position I need a more experienced programmer, NOT
an entry level one.
One of them had 35 years of scientific programming experience, but all
of it was in Russia, and little of it was in C. It's too bad she failed
my test so miserably; she was only asking for $30K, well under even our
price limit.

Quote:
> >Are these questions really so difficult? I could have answered the first
> >two questions right off the bat, after my first read of K&R, before I
> >even wrote my first program in C (yes, I did read the whole book before
> >writing a single line of code - that's the way I do things, for better
> >or for worse). It's almost straight out of chapter 5 of my copy (1st
> >edition).

> Exactly, but if you have not read K&R you might well never have come
> across it. So you first interview question might be 'Have you ever read
> 'The C programming Language'? If 'yes', ask which edition.

Is it missing from later editions?
--



Tue, 22 Apr 2003 12:15:00 GMT  
 Entry level C test?


Quote:
>    void myfunc(char *p, char *q)
>    {
>            while(*p++ = *q++);
>    }

I have a suggestion.

Try a few variants:

Then ask the same three questions.

e.g.:
        void myfunc2(char *p, char *q)
        {
                while (*p = +*q++)
                        *p++;
        }

        void myfunc(unsigned char *p, unsigned char *q)
        {
                while (*(p++) = (*q)++);
        }

I wouldn't hire someone based solely on figuring those two out, but I'd sure
be impressed.

This, itself, depresses me.

-s
--

C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Consulting & Computers: http://www.*-*-*.com/
http://www.*-*-*.com/ ~seebs/ops/pres.html - Presidential endor{*filter*}t!
--



Tue, 22 Apr 2003 12:48:14 GMT  
 Entry level C test?

Quote:
> [ strcpy() test snipped ]
> Are these questions really so difficult?

Yes and no. The function uses an idiom which I wouldn't expect an entry-
level C programmer to know.

However, I would expect them to be able to figure it out with one or two
gentle hints (your post didn't say if you gave them the opportunity or
not); I might even learn more about their understanding of C this way
than if they had answered the questions successfully.

Quote:
> It's almost straight out of chapter 5 of my copy (1st edition).

When I learned C, K&R wasn't available to me; and when I finally could
lay my hands on it, I no longer needed it. Maybe one day I'll buy it
just for curiosity value...
--

              http://www.bearnip.com/
--



Tue, 22 Apr 2003 03:00:00 GMT  
 Entry level C test?

Quote:
>Because I considered it so elementary that I expected they would have
>seen it already, long before they would consider themselves ready to be
>paid for their programming skills. It's in K&R (or at least in my copy
>of the 1st edition), and I understood every aspect of C described in
>that book before I started my first paid programming job. I didn't
>understand Unix, or libraries, or de{*filter*}s, or compiler/linker options,
>or makefiles, but I understood the C language itself.

So you are an academic? And one who still uses out of date books?
Many,  including myself, do not base our C on K&R 1st ed. Things
have moved on in the last 30 years.

Anyone who claims to have "understood every aspect of C described in
that book" [K&R] is an idiot. Especially if that person  then goes on to
say that they did not understand libraries (and essential part of C)
compilers, linkers or de{*filter*}s.

It is like saying I am a master chef because I read and memorised a
cook book without ever setting foot in a kitchen or  I am a poet
because I read the dictionary.... there is far more to SW Engineering
than knowing the syntax.

I would also refer you to the paper on C by Denise Ritche where he
comments that lint was developed because people were using legal but
dubious constructs. Just because it is legal C does not make it good C.

Having looked at the code you showed my first reaction is that I would
not like to work in a place where that was considered acceptable.

Mind you I have yet to write a windows program  :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--



Tue, 22 Apr 2003 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. HELP: Entry Level job C test

2. Entry Level C Programming Job

3. Evaluating Entry Level Programmer Hires

4. Entry level C/C++

5. Entry Level Programmer Wanted

6. self taught C++ entry level jobs???

7. OH - CINCI/DAYTON - Entry Level Delphi Freelancer Sought

8. Entry Level Software Engineer Position Wanted

9. Entry level job?

10. 'C' Programmers needed / including entry level

11. Device Drivers - entry level help required

12. Looking for entry level job with MFC

 

 
Powered by phpBB® Forum Software