«

osmium posted:

> Julie writes:
>
>> > int main()
>> > {
>> > int * x;
>> >
>> > *x = 10;
>> > return 0;
>> > }
>> >
>> > // What's wrong here?
>>
>> Absolutely nothing is wrong. All of the above is
perfectly legal C++.
>
> Only a fool would give that answer if he wanted the job.
If you don't
> want to work there, why bother with the interview?
>
> They are hiring programmers, not language lawyers.


What the hell is going on here?

Julie, yes, the code will compile; is that your definition
of "perfectly legal C++"? The code contains undefined
behaviour.

osmium, the question is very clear and straightforward. In
answering it correctly, one shows an understanding of
what's going on. Anyone with more than an hour's C++
knowledge knows what's going on there, let alone a language
lawyer.

int main()
{
int * x; //1

//1: Defines a local variable named "x" of type "int*".
The variable is un-initialized and as such contains white
noise - it may contain any value

*x = 10; //2

//2: The aforementiond variable is dereferenced: the
address which this variable contains is written to with the
value 10. As the variable contains any value, any piece of
memory is written to.

return 0;

}


-JKop

On Sat, 17 Jul 2004 03:11:02 -0400 in comp.lang.c++, "rohi"
<> wrote,
>dear friends,
>
> I have applied for a job in a software company.
>a friend of mine told me that the written test will basically contain
>questions from C & C++.I would be happy if someone could please send some
>basic interview questions asked in C and C++ along with their answers.

Many questions asked here are answered in bits and pieces in Marshall
Cline's C++ FAQ, but the answer to this one is the whole thing. It is
always good to check the FAQ before posting. You can get the FAQ at:
http://www.parashift.com/c++-faq-lite/

Also Steve Summit's C FAQ. http://www.eskimo.com/~scs/C-faq/top.html

osmium wrote:
>
> Julie writes:
>
> > > int main()
> > > {
> > > int * x;
> > >
> > > *x = 10;
> > > return 0;
> > > }
> > >
> > > // What's wrong here?
> >
> > Absolutely nothing is wrong. All of the above is perfectly legal C++.
>
> Only a fool would give that answer if he wanted the job. If you don't want
> to work there, why bother with the interview?
>
> They are hiring programmers, not language lawyers.

I'm not a fool, nor a language lawyer. However, I do answer the question
_asked_. What do you do? Answer what isn't asked?!

In answer to the question, nothing is wrong. How can you determine what is
wrong when what is expected isn't defined? Suppose the requirement was to
"create a program that exhibits undefined behavior" --

The interviewer should ask "what is the result?" if that is what they are
after. The answer to _that_ question is "undefined behavior due to an
uninitialized pointer dereference."

Osimum, perhaps you don't realize it (yet!), but when interviewing for a job,
there are actually two interviews that _should_ be taking place: one is the
interviewing of perspective candidate by the company representative(s), the
second is by the candidate of the company and its representative(s). Only a
foolish candidate wouldn't consider the second.

JKop wrote:
>
> osmium posted:
>
> > Julie writes:
> >
> >> > int main()
> >> > {
> >> > int * x;
> >> >
> >> > *x = 10;
> >> > return 0;
> >> > }
> >> >
> >> > // What's wrong here?
> >>
> >> Absolutely nothing is wrong. All of the above is
> perfectly legal C++.
> >
> > Only a fool would give that answer if he wanted the job.
> If you don't
> > want to work there, why bother with the interview?
> >
> > They are hiring programmers, not language lawyers.
>
> What the hell is going on here?
>
> Julie, yes, the code will compile; is that your definition
> of "perfectly legal C++"? The code contains undefined
> behaviour.
>
> osmium, the question is very clear and straightforward. In
> answering it correctly, one shows an understanding of
> what's going on. Anyone with more than an hour's C++
> knowledge knows what's going on there, let alone a language
> lawyer.
>
> int main()
> {
> int * x; //1
>
> //1: Defines a local variable named "x" of type "int*".
> The variable is un-initialized and as such contains white
> noise - it may contain any value
>
> *x = 10; //2
>
> //2: The aforementiond variable is dereferenced: the
> address which this variable contains is written to with the
> value 10. As the variable contains any value, any piece of
> memory is written to.
>
> return 0;
>
> }
>
> -JKop

You didn't answer the question though. "What's wrong here?"

You can't answer the question, because you don't know the requirement.

Julie posted:

> JKop wrote:
>>
>> osmium posted:
>>
>> > Julie writes:
>> >
>> >> > int main()
>> >> > {
>> >> > int * x;
>> >> >
>> >> > *x = 10;
>> >> > return 0;
>> >> > }
>> >> >
>> >> > // What's wrong here?
>> >>
>> >> Absolutely nothing is wrong. All of the above is
perfectly legal
>> >> C++.
>> >
>> > Only a fool would give that answer if he wanted the
job. If you
>> > don't want to work there, why bother with the
interview?
>> >
>> > They are hiring programmers, not language lawyers.
>>
>> What the hell is going on here?
>>
>> Julie, yes, the code will compile; is that your
definition
>> of "perfectly legal C++"? The code contains undefined
behaviour.
>>
>> osmium, the question is very clear and straightforward.
In
>> answering it correctly, one shows an understanding of
>> what's going on. Anyone with more than an hour's C++
>> knowledge knows what's going on there, let alone a
language lawyer.
>>
>> int main()
>> {
>> int * x; //1
>>
>> //1: Defines a local variable named "x" of type
"int*".
>> The variable is un-initialized and as such contains
white
>> noise - it may contain any value
>>
>> *x = 10; //2
>>
>> //2: The aforementiond variable is dereferenced: the
>> address which this variable contains is written to with
the
>> value 10. As the variable contains any value, any piece
of
>> memory is written to.
>>
>> return 0;
>>
>> }
>>
>> -JKop
>
> You didn't answer the question though. "What's wrong
here?"
>
> You can't answer the question, because you don't know the
requirement.

Q: What's wrong here?

A: Un-allocated memory is accessed and written to.


Is that the kind of answer you're looking for?

(And to which requirement to you refer?)

-JKop

> osmium wrote:
> >
> > Julie writes:
> >
> > > > int main()
> > > > {
> > > > int * x;
> > > >
> > > > *x = 10;
> > > > return 0;
> > > > }
> > > >
> > > > // What's wrong here?
> > >
> > > Absolutely nothing is wrong. All of the above is perfectly legal C++.
> >
> > Only a fool would give that answer if he wanted the job. If you don't
want
> > to work there, why bother with the interview?
> >
> > They are hiring programmers, not language lawyers.
>
> I'm not a fool, nor a language lawyer. However, I do answer the question
> _asked_. What do you do? Answer what isn't asked?!

Answer to osmium:

Oh, but you are wrong. Answering that question, in a job interview for a
programmer, whould mark you as a fool. It is a foolish, quibbling answer. As
a manager, I wouldn't want an employee who couldn't speak "in the
vernacular" and had to be given an iron-clad contractual specification for
everything wanted. That, of course, is absurd. No job for you, unless I
really want a headache.
[Before it becomes a flame war, notice I am not calling you a fool. That
answer, in that situation is foolish. I'm sure, based on previous posts
here, that you are no fool, but perhaps too "clever" for me.]

>
> In answer to the question, nothing is wrong. How can you determine what
is
> wrong when what is expected isn't defined? Suppose the requirement was to
> "create a program that exhibits undefined behavior" --
>
> The interviewer should ask "what is the result?" if that is what they are
> after. The answer to _that_ question is "undefined behavior due to an
> uninitialized pointer dereference."

And, yes, you answer what was meant. As I learned many years ago:

Don't tell me all about your indigestion.
"How are you?" is a greeting, not a question.
--
Gary

"Julie" <> wrote in message
news:...
> You didn't answer the question though. "What's wrong here?"
>
> You can't answer the question, because you don't know the requirement.

It's hard to see a candidate being offered the job after trying that tactic.

Walter wrote:
>
> "Julie" <> wrote in message
> news:...
> > You didn't answer the question though. "What's wrong here?"
> >
> > You can't answer the question, because you don't know the requirement.
>
> It's hard to see a candidate being offered the job after trying that tactic.

Well then, that is the misfortune of the company.

I find it somewhat dichotomous how we programmers deal with extreme precision,
something that isn't precise usually doesn't work or worse, yet we allow
ourselves to be treated as morons and never attempt to establish what is really
intended by those that we work for.

My original response was somewhat facetious, intended to bring up some points
about the interviewing process and the capacity of the interviewer.

Honestly, if I were in an interview like that:

interviewer: <code snippet>, "what's wrong with this code?"

me: "Without knowing the specific requirements, it is hard to really determine
what is really 'wrong' as it looks like it would compile just fine to me. I do
see it resulting in undefined behavior when executing, however. Can you tell me
what the requirements are?."

interviewer: "I'll get to the requirements in a sec; what do you mean by
undefined behavior?"

me: "Well, there is a problem when derefrencing x because it hasn't been
initialized. The standard indicates that doing such results in 'undefined
behavior', so just about anything can happen at that point, but will probably
result in a crash."

interviewer: "By the way, the requirement was to 'write a program that exhibits
undefined behavior' -- nice job, you have been the only candidate to realize
that requirements are an important part to the development process."

>
>/* File: c1.c */
>
>#include <stdio.h>
>
>extern char *str;
>
>int main()
>{
> printf("%s\n", str );
> getchar();
> return 0;
>}
>
>/* File: c2.c */
>
>char str[] = "Hello world";

Should this result in an executable program?

I was expecting a linker error.

I am aware that in certain contexts the name of an array can be converted to a
pointer and used as though if it were a pointer. I did not expect this to be
one of them though.

When executed the program crashes.

If the declaration in c1.c and the definition in c2.c are made to match then
the program executes without error.

Was MSVC++.NET correct in allowing this program to build?

Julie wrote:
> interviewer: "By the way, the requirement was to 'write a program that exhibits
> undefined behavior' -- nice job, you have been the only candidate to realize
> that requirements are an important part to the development process."

that's clever.

personally, i wouldn't want to work for an employer so machiavellian though.

besides, the narrow-mindedness behind that thinking is very dangerous.
an analogy:

"copilot, i just got a light on my board, is engine #2 ok?"
"yes sir, it looks fine"
(ten seconds later as the plane is about to crash)
"copilot, i thought you said engine #2 was fine!"
"it was sir. of course, it wasn't connected to the plane at that point.
but i watched it fall, and it was running beautifully."

i have never hired a programmer myself, but i have hired engineers. when
i hire an engineer, i expect them to be smart enough to make reasonable
extrapolations of the broader impact of their design decisions. given
that the candidate was specifically not given the requirements, i would
expect any decent engineer to attempt to extrapolate them from the code.
personally, i don't think it's such a leap to assume that "don't crash"
is one such requirement.

if i handed an engineer something like that program, i would *expect*
them to come back and tell me it's wrong - because otherwise they were
either too lazy or too stupid to assume a reasonable requirement set.
maybe programming is different from engineering, but i hire engineers
because they make reasonable logical leaps and think outside the box.
otherwise, i could just hire matlab.

mark