What type of questions can be asked in an technical interview of C

  • Thread starter Cherrish Vaidiyan
  • Start date
M

Malcolm

Richard Heathfield said:
I agree that making code unreadable is not the solution, but I do not >
agree that ('a' == str) is unreadable.In itself it doesn't damage readability too much. The problem is the
cumulative effect of too many constructs like that (such as for(;;),
typedefing every single basic type, complex indirection, etc).
 
R

Richard Heathfield

Malcolm said:
Richard Heathfield said:
I agree that making code unreadable is not the solution, but I do not >
agree that ('a' == str) is unreadable.In itself it doesn't damage readability too much. The problem is the
cumulative effect of too many constructs like that (such as for(;;),


....which I don't use...
typedefing every single basic type,

....which I don't do...
complex indirection, etc).

....and which I only do when it is necessary.
 
M

Malcolm

Régis Troadec said:
What is wrong with

3)

for(i=0;i<strlen(str);i++)
if(str == 'a')
answer++;


I'm not sure that someone can say this code is wrong or not, since > the type of i is unknown.
If i is declared as size_t, it should work.

The question is, what is wrong with it? What's wrong is that C evaluates the
strlen() call on every loop iteration, so we have an O(N*N) algorithm which
can be trivially transformed into an O(N) algorithm. This is just a stupid
waste of processor cycles, which may or may not matter depending on where
the bottlenecks are in the program.
 
J

Joe Wright

Richard said:
Malcolm wrote:

Richard Heathfield said:
I agree that making code unreadable is not the solution, but I do not >

agree that ('a' == str) is unreadable.

In itself it doesn't damage readability too much. The problem is the
cumulative effect of too many constructs like that (such as for(;;),



...which I don't use...

typedefing every single basic type,


...which I don't do...

complex indirection, etc).


...and which I only do when it is necessary.

Has no one mentioned that..
answer++;
...treats an undefined variable?
 
M

Malcolm

Joe Wright said:
Has no one mentioned that..
answer++;
..treats an undefined variable?
All the examples are code fragments. If you are looking at real code then
you won't always know what is in scope at any one time.
There's also not much point giving as a problem something which will be
picked up at compile time.
 
C

Christian Bau

"Régis Troadec said:
Christian Bau said:
Joona I Palaste said:
Malcolm <[email protected]> scribbled the following:
I need to attend technical interview on C. wat type of
questions should be expected?

See if you can answer these.

What is wrong with

3)

for(i=0;i<strlen(str);i++)
if(str == 'a')
answer++;

Am I blind or something? Other than doing more work than necessary (and
such slowing the program down) I can find nothing wrong with this.


If strlen (str) == 1000000, then this would be wrong enough to count as
a serious bug.


I'm not sure that someone can say this code is wrong or not, since the type
of i is unknown.
If i is declared as size_t, it should work.


You failed the interview.
 
R

Régis Troadec

"Christian Bau" <[email protected]> a écrit dans le message
de
Hi,
Régis Troadec said:
"Christian Bau" <[email protected]> a écrit dans le message
de news:[email protected]...
Malcolm <[email protected]> scribbled the following:
I need to attend technical interview on C. wat type of
questions should be expected?

See if you can answer these.

What is wrong with

3)

for(i=0;i<strlen(str);i++)
if(str == 'a')
answer++;

Am I blind or something? Other than doing more work than necessary (and
such slowing the program down) I can find nothing wrong with this.

If strlen (str) == 1000000, then this would be wrong enough to count as
a serious bug.


I'm not sure that someone can say this code is wrong or not, since the type
of i is unknown.
If i is declared as size_t, it should work.


You failed the interview.


I'm sorry but I don't think so. I agree with Malcolm's answer concerning the
problem of inefficiency but my opinion is this problem is as much a feature
of algorithm analysis and can occur in many other languages. Another point
is that you outlined a possible serious bug in your previous message when
strlen(str) == 1000000. Sure, It could be wrong enough and turn into an
infinite loop according to the type of i, if it's a short int for example,
wasn't that you meant?

Regis
 
C

Christian Bau

"Régis Troadec said:
I'm sorry but I don't think so. I agree with Malcolm's answer concerning the
problem of inefficiency but my opinion is this problem is as much a feature
of algorithm analysis and can occur in many other languages. Another point
is that you outlined a possible serious bug in your previous message when
strlen(str) == 1000000. Sure, It could be wrong enough and turn into an
infinite loop according to the type of i, if it's a short int for example,
wasn't that you meant?

How long does it take to make one million calls to strlen () when the
length of the string is one million? How likely is it that the user of
the program believes that the program just crashed and gives up? If this
program runs on a portable computer, will it finish with one battery?

Since this thread is about a job interview: How likely is it that
customers will complain and stop buying your software if the programmers
do nonsense like this?
 
C

CBFalconer

Régis Troadec said:
"Christian Bau" <[email protected]> a écrit:
.... snip ...
What is wrong with

3)

for(i=0;i<strlen(str);i++)
if(str == 'a')
answer++;
.... snip ...

You failed the interview.


I'm sorry but I don't think so. I agree with Malcolm's answer
concerning the problem of inefficiency but my opinion is this
problem is as much a feature of algorithm analysis and can occur
in many other languages. Another point is that you outlined a
possible serious bug in your previous message when strlen(str)
== 1000000. Sure, It could be wrong enough and turn into an
infinite loop according to the type of i, if it's a short int
for example, wasn't that you meant?


Nobody seems to have bothered to point out that str itself may be
volatile and is being dynamically modified, in which case those
who want to store the entry value of strlen(str) are introducing
bugs. As a matter of fact, there is no need to EVER call strlen
for this:

for (p = str; *p; p++)
if ('a' == *p) answer++;

The original code is inefficient, not wrong. Bubblesort is also
inefficient, not wrong.

The thing that is *wrong* with the original code is the lack of
blanks in the source.
 
C

Christian Bau

CBFalconer said:
Nobody seems to have bothered to point out that str itself may be
volatile and is being dynamically modified, in which case those
who want to store the entry value of strlen(str) are introducing
bugs. As a matter of fact, there is no need to EVER call strlen
for this:

for (p = str; *p; p++)
if ('a' == *p) answer++;

You mean str points to volatile data, not str is volatile, right? If the
string pointed to by str is dynamically modified, then your code is very
likely to fail: str[101] might be zero, but when p == &str [50], str
[101] is changed to nonzero and str [0] is set to zero.

The original code is inefficient, not wrong.

When the code becomes so inefficient that it cannot do what it is
supposed to do, that makes it wrong.
 
J

J. J. Farrell

Christian Bau said:
Régis Troadec said:
"Christian Bau" <[email protected]> a écrit dans le message
de news:[email protected]...
Malcolm <[email protected]> scribbled the following:
I need to attend technical interview on C. wat type of
questions should be expected?

See if you can answer these.

What is wrong with

3)

for(i=0;i<strlen(str);i++)
if(str == 'a')
answer++;

Am I blind or something? Other than doing more work than necessary (and
such slowing the program down) I can find nothing wrong with this.

If strlen (str) == 1000000, then this would be wrong enough to count as
a serious bug.


I'm not sure that someone can say this code is wrong or not, since the type
of i is unknown.
If i is declared as size_t, it should work.


You failed the interview.


Why? If the interviewer is looking at knowledge of the C language, then
this is an excellent answer and I would be pleased to get it. Given
certain assumptions about the types of i, str, and answer, there is
nothing "wrong" with this as an example of C code. Pointing out how the
code would go wrong with inappropriate types for these variables would
be a great answer about C itself.

Having got (or not got) that answer I would then go on to say "Is there
anything wrong with that code as a section of a real-world program?" and
I would expect to get the performance answer.

The moral is to think about all aspects of the question, and don't assume
that the questioner is really asking the question that his words make up.
Talk about all aspects of the question.
 
D

Dan Pop

In said:
Hope everyone is doing fine.i feel pointers to be the most toughest
part in C. i have just completed learning pointers & arrays related
portions. I need to attend technical interview on C. wat type of
questions should be expected? Which part of C language do the staff
give more concern?
The interviewers have just mentioned that .. i will have interview on
C.
Also can anyone can help me with sites where i can go thru sample
programs in C?

If you read (and understand) the FAQ, you should be well prepared for
an interview dealing with language technicalities.

Dan
 
A

Arto Huusko

There is a completely different, equally likely explanation.

I'd like to know what the other explanation is?

And besides, considering the initial question, there actually
isn't anything wrong with the above code, as such. Given some
more context, it most likely is a logic error, but...
 
C

Christian Bau

Arto Huusko said:
I'd like to know what the other explanation is?

I thought that would be obvious. 50 percent chance that he meant to use
== instead of !=. 50 percent chance that he meant to use && instead of
||.
 
P

Peter Nilsson

Arto Huusko said:
I'd like to know what the other explanation is?

if( ch == '.' || ch == ',')
And besides, considering the initial question, there actually
isn't anything wrong with the above code, as such.

Execpt that "it will always evaluate as true."
Given some more context, it most likely is a logic error,

Can you give a context [outside of ioccc] where an always true
condition should be obfuscated in this way?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top