Really **wonderful** website for C interview questions!!!!!

R

rajanarayan2005

Hello folks!!!!

I just found the BEST and the MOST comprehensive
website for C related questions and their answers. It
has a VERY, VERY, VERY good collection of the MOST
FREQUENTLY ASKED interview questions.

http://www.cracktheinterview.com

If you can understand the solutions on this site, you
can 100% get through ANY interview - I can say for
sure!!. I have taken the printouts for all the
questions and the answers!. Its really too good
to be true. Really someone has taken lot of pains to
consolidate the questions....

~Raja
 
R

rajanarayan2005

As of now, I want a Job!. Need money to run the family pal. But what
you say is right. Bookish knowledge does not help anyone. But thats how
the world runs :(. If you know the question and its answer, you have a
fair chance of getting in. Otherwise, someone else will :(
 
R

Richard Bos

I just found the BEST and the MOST comprehensive
website for C related questions and their answers. It
has a VERY, VERY, VERY good collection of the MOST
FREQUENTLY ASKED interview questions.

Caveat Lector. I just looked at five of the questions on that page, and
of those, four of the answers cause undefined behaviour, don't work as
advertised, or are otherwise inferior. While it's perfectly possible
that invoking UB in your interview will actually be to your advantage if
you're trying to get a job with, say, Microsoft or IBM, you wouldn't get
past my desk if you tried them on me.

Richard
 
R

rajanarayan2005

Richard, so where is that you work?

And what are the questions that cause UB? Kindly post atleast one here
so that we can understand what you mean by UB. All I can see on this
website (http://www.cracktheinterview.c­om) is a fairly good
collection of approaches to various frequently asked questions. For a
starter, I think this site is very good. I cant see any UB as far as
the first 5 questions go.
 
R

rajanarayan2005

Can you give examples of UBs in the 5 questions you mentioned? I dont
see any sir!. The site is quite well done.

Also, where do you work BTW?
 
R

rajanarayan2005

Can you give examples of UBs in the 5 questions you mentioned? I dont
see any sir!. The site is quite well done.

Also, where do you work BTW?
 
L

Lawrence Kirby

Can you give examples of UBs in the 5 questions you mentioned? I dont
see any sir!. The site is quite well done.

Also, where do you work BTW?

I'm encouraged that you are reading the responses to your post and
responding, so this isn't just spam. Note however that newsgroups aren't a
"chat" medium, don't keep posting (essentially) the same thing repeatedly.
You can expect to wait for hours and perhaps even a day or 2 in some
circumstances for proper response.

You should learn to quote the proper context of what you are replying to,
as I have done here.

Also this is a newsgroup about discussing C, people are under no
obligation to describe their backgrounds.

Some errors I spotted on a quick scan through the questions:

Reversing linked list

Method 1

It is legitimate for a linked list to contain no elements, i.e.
the head pointer is itself null. The code fails in this case.


Method 2

The code returns 1 from main(). The only portable return values from
main() are 0, EXIT_SUCCESS and EXIT_FAILURE. Many implementations would
treat a 1 return as a failure indication. EXIT_SUCCESS and EXIT_FAILURE
are defined in <stdlib.h>

temp = (mynode *)malloc(sizeof(mynode));

Don't cast unless you really need to. Casting the return value of malloc()
is a classic error when it is used to shut the compiler up. The real error
is not having a proper declaration of malloc() is cope at the call. The
cast (usually) makes this compile silently but the error is still there
and the code is broken. The correct fix is to #include <stdlib.h> and
remove the superfluous cast. You can also use a better form for the
argument to sizeof:

temp = malloc(sizeof *temp);

Simpler, clearer and best of all correct.

The code fails to test the return value of malloc() for failure.

Always use proper prototype form in function declarations and definitions
e.g.

void print_list();

should be

void print_list(void);

This puts extra type checking requirements on the compiler.

C doesn't define any function callled getch().


sprintf(str, "[%d]->",(temp->value));
printf(str);

Why use sprintf() here at all, just use printf(). By doing it this way
you've created a dependency on a buffer size and you've introduced a
possible bug. Never use non-format data as a printf() format string, if it
contained % characters they will be interpreted as conversion specifiers.
That may not happen with the code you have but is BAD pactice and somebody
maintaining the code might easily add a % character. This is a
maintenance nightmare. Always output string data using %s e.g.

printf("%s", str);

There's undoubtedly more but this is enough for one post. I didn't pick a
bad question specifically, this is the first one I looked at. But it is a
very good example of how NOT to answer an interview question. A good
answer should demonstrate at every possible turn that you know the tricks
of the trade, the pitfalls and how to avoid them. Code that jumps in
making a whole host of basic mistakes is not a good sign.

Lawrence
 
R

Robert Gamble

Hello folks!!!!

I just found the BEST and the MOST comprehensive
website for C related questions and their answers. It
has a VERY, VERY, VERY good collection of the MOST
FREQUENTLY ASKED interview questions.

http://www.cracktheinterview.com

If you can understand the solutions on this site, you
can 100% get through ANY interview - I can say for
sure!!. I have taken the printouts for all the
questions and the answers!. Its really too good
to be true. Really someone has taken lot of pains to
consolidate the questions....

Some "gems" from the site:

Does C have boolean variable type?
No, C does not have a boolean variable type. [...]

Is there a limit on the number of characters in the name of a header
file?
The limitation is only that identifiers be significant in the first six
characters, not that they be restricted to six characters in length.

How do you find out if a machine is 32 bit or 64 bit?
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("\nThe pointer is [%lu] bytes\n", sizeof (void *));
return (0);
}
This should show "4" incase of a 32-bit machine and "8" incase of a
64-bit machine.

Robert Gamble
 
J

Jason Curl

Robert said:
Hello folks!!!!

I just found the BEST and the MOST comprehensive
website for C related questions and their answers. It
has a VERY, VERY, VERY good collection of the MOST
FREQUENTLY ASKED interview questions.

http://www.cracktheinterview.com

If you can understand the solutions on this site, you
can 100% get through ANY interview - I can say for
sure!!. I have taken the printouts for all the
questions and the answers!. Its really too good
to be true. Really someone has taken lot of pains to
consolidate the questions....


Some "gems" from the site:

Does C have boolean variable type?
No, C does not have a boolean variable type. [...]

Is there a limit on the number of characters in the name of a header
file?
The limitation is only that identifiers be significant in the first six
characters, not that they be restricted to six characters in length.

How do you find out if a machine is 32 bit or 64 bit?
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("\nThe pointer is [%lu] bytes\n", sizeof (void *));
return (0);
}
This should show "4" incase of a 32-bit machine and "8" incase of a
64-bit machine.

Does C specify this? I always thought that was the convention, but not
necessarily the rule. I know that 'void *' must accomodate all other
known pointer types, and be able to convert back to the original pointer
type, but what if the compiler wanted to store "metadata" with the
pointer (e.g. a size as well as the address of memory for strict memory
checking)?
 
R

Robert Gamble

Richard, so where is that you work?

And what are the questions that cause UB? Kindly post atleast one here
so that we can understand what you mean by UB. All I can see on this
website (http://www.cracktheinterview.c­om) is a fairly good
collection of approaches to various frequently asked questions. For a
starter, I think this site is very good. I cant see any UB as far as
the first 5 questions go.

Richard said there was undefined behavior or other issues in 4 out of the
5 questions that *he* looked at, not the first five on the page. Of
course nobody reading your post would know this without looking at his
post because you failed to quote anything at all in your followup.

The majority of the examples I looked at were either incorrect, invoked
undefined behavior, demonstrated very poor coding practices or a
combination of the three. Let's take a look at 2 examples:

Example 1:
Write a C program for calculating the factorial of a number

Here is a recursive C program

fact(n) /* Return type of function not provided */
{
int fact;
if(n==1)
return(1);
else
fact = n * fact(n-1); /* What happens if n is too large (15 is
too large for many systems)? fact will
overflow causing UNDEFINED BEHAVIOR.
What happens if n is negative or 0? */
return(fact);
}

In addition to the point above, the code sample is a function, not a
program, the basic terminology is incorrect. It should also be mentioned
that while academically quaint, this method of calculating the factorial
of a number is probably, by far, the most inefficient. This might be a
good answer for an entry level college exam, but what I would be looking
for in an interview.


Example 2:

Write your own C program to implement the atoi() function:

#include<stdioi.h>

/* There needs to be a space between the "e" and the "<".
Additionally, stdioi.h is not a standard header */

int myatoi(char *string);

int main() /* Should be int main (void) */
{
printf("\n%d\n", myatoi("1998")); /* need to include <stdio.h> first */
getch(); /* Not a standard function */
return(0);
}

int myatoi(char *string)
{
int i;
i=0;
while(*string)
{
i=(i<<3) + (i<<1) + (*string - '0'); /* See note below */
string++;

// Dont increment i!

}
return(i);
}

So not only does the program have numerious issues, it doesn't even
accomplish what it set out to do which was to implement the atoi function!
There is no check to ensure that non-digit characters aren't processed, i
could easily become negative due to this lack of checking and then invoke
undefined behavior when shifted. The atoi function can handle
negative numbers, this program fails miserably when provided such input.

I could go on and on like this with the rest of the examples given at the
site but hopefully you get the point. Perhaps the biggest problem with
the site is that people who are not adept enough to recognize these errors
go to the site and pick up bad habits thinking that they are learning
useful and correct skills.

Robert Gamble
 
R

Randy Howard

rgamble99 said:
The majority of the examples I looked at were either incorrect, invoked
undefined behavior, demonstrated very poor coding practices or a
combination of the three.

Ditto. A cynic might say howtofailaninterview.com might be a better
domain name. At least he has comment opportunity on each page, and
I sent a lot of feedback already, but it seems hardly worth the time
to continue to give him free answers so he can make more ad revenue.

Note that he discusses inline functions, with no mention of them
being non-standard in C89.

Or, how about the list of valid main prototypes shown here:


int main()

or

int main(void)

or

int main(int argc, char *argv[])

or

int main(int argc, char *argv[], char *env[])


Oops.

Maybe if you're interviewing for a job writing non-standard C?
 
M

Malcolm

Jason Curl said:
How do you find out if a machine is 32 bit or 64 bit?
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("\nThe pointer is [%lu] bytes\n", sizeof (void *));
return (0);
}
This should show "4" incase of a 32-bit machine and "8" incase of a
64-bit machine.

Does C specify this? I always thought that was the convention, but not
necessarily the rule. I know that 'void *' must accomodate all other known
pointer types, and be able to convert back to the original pointer type,
but what if the compiler wanted to store "metadata" with the pointer (e.g.
a size as well as the address of memory for strict memory checking)?
You are right.
Pointer size is a property of the compiler, not the processor. Usually it is
fairly obvious that the sensible implementation is to use the same bit
representation as an address register, but for debugging or other purposes
you could attach other data.

The problem with many types of metadata is that C maintains no list of live
pointers. It is thus difficult to implement reference counting or similar
management schemes.

There is not much point having a 64-bit address space and only a gigabyte or
two of physical memory. So we can expect that the present convention of
having addresses and words of data of the same size, and for the address to
be essentially a simple index into memory, to change in the near future.
 
L

Lawrence Kirby

Robert Gamble wrote:
....
How do you find out if a machine is 32 bit or 64 bit?
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("\nThe pointer is [%lu] bytes\n", sizeof (void *));
return (0);
}
This should show "4" incase of a 32-bit machine and "8" incase of a
64-bit machine.

Does C specify this?

Robert was giving examples of incorrect information. There is no single
definition of the "bitness" of a machine. Various have included register
size, Data bus size, ALU size, address bus size and possibly others. E.g.
the 68000 has 32 bit registers and instructions for 32 bit ops, a 16 bit
ALU so 32 bit ops take longer than 16 bit ops, a 16 bit external data bus,
possibly a 24 bit external address bus.
I always thought that was the convention, but not
necessarily the rule. I know that 'void *' must accomodate all other
known pointer types, and be able to convert back to the original pointer
type, but what if the compiler wanted to store "metadata" with the
pointer (e.g. a size as well as the address of memory for strict memory
checking)?

Right, there's no great corresponance between "bitness" and the size of
void *. int is arguable better, but both are likely to be wrong in, for
example, an 8 bit system.

Another problem is that the quoted text makes the invalid assumption that
CHAR_BIT is 8.

Lawrence
 
S

Suman

Richard said:
Caveat Lector. I just looked at five of the questions on that page, and
of those, four of the answers cause undefined behaviour, don't work as
advertised, or are otherwise inferior. While it's perfectly possible
that invoking UB in your interview will actually be to your advantage if
you're trying to get a job with, say, Microsoft or IBM, you wouldn't get
past my desk if you tried them on me.

Richard

On the same note: have a look at the strlen() function they have (at
the
risk of generating even more revenue for the owner of this page,
but we have done him a lot of good already, so...)
/* code on their site */
int strlen(char *string)
{
char *p=string;

while(*p!='\0')
p++;

return(p-s);
}
and check with (as it is somewhat closer to, the signature part)
/* code from K&R, a not-so-old version */
int strlen(char *s)
{
int n;

for (n = 0; *s != '\0', s++)
n++;
return n;
}
as well as the signature of what we have on most systems ...
size_t strlen(const char *s).

This might just tempt you all the more to stay away!

Regards,
Suman.

P.S: Don't flame me for pulling down K&R, to their standard & win the
argument by sheer experience.
 
P

pete

Suman said:
On the same note: have a look at the strlen() function they have (at
the
risk of generating even more revenue for the owner of this page,
but we have done him a lot of good already, so...)
/* code on their site */
int strlen(char *string)
{

This might just tempt you all the more to stay away!

I emailed corrections about
mymove
strcmp
strlen
toupper
this morning.

mymove used a relational operator on two pointers
which were not guaranteed to point to the same object.
strcmp didn't interpret the characters as unsigned char.
strlen for what you said.
toupper assumed ASCII.
 
M

Mark

Robert Gamble said:
/* There needs to be a space between the "e" and the "<".

Isn't that a style issue? I personally leave a space and think
it 'should' be required, but I've known coders who don't and
I've never encountered an implementation which cared one
way or the other.

What in the standard leads you to believe it is required?
From the standard: 6.10.2/2
A preprocessing directive in the form
# include <h-char-sequence> new-line

Yes, there is a space between the "e" and "<",
but there is also a space between "#" and "i" and between ">" and new-line.

Is there another section which I've overlooked which supports your claim?
 
R

Robert Gamble

Mark said:
Isn't that a style issue? I personally leave a space and think
it 'should' be required, but I've known coders who don't and
I've never encountered an implementation which cared one
way or the other.

What in the standard leads you to believe it is required?
From the standard: 6.10.2/2
A preprocessing directive in the form
# include <h-char-sequence> new-line

Yes, there is a space between the "e" and "<",
but there is also a space between "#" and "i" and between ">" and new-line.

Is there another section which I've overlooked which supports your claim?

You are correct, it is not required, but it is poor style (which is
something of importance when you are trying to make a good impression
during an interview).

Robert Gamble
 
R

rajanarayan2005

You people shockingly funny. You didnt mind moneys posting shit like
"Turn $6 into $15,000 in 1 month with paypal!" and when some-one like
me posted a link to a good website like

http://www.cracktheinterview.com/

all of you came on me as ton of bricks. This site has a good collection
of C questions, the answers are always debetable. The C language is a
big mess if you ask me, but the sites does a decent job of helping
people attend interviews with more confidence. Maybe its not correct
answers, but atleast it has something than plain old forums.

Forums on the internet have become bash-him-up zones these days. And
the last one who posts is the winner, I suppose.
 
M

Martin Ambuhl

You people shockingly funny. You didnt mind moneys posting shit like
"Turn $6 into $15,000 in 1 month with paypal!" and when some-one like
me posted a link to a good website like
said:
all of you came on me as ton of bricks.

You are shockingly ignorant. The posters of such spam are not going to
see any responses to them, so what is it you expected to be done? Get real.
 

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,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top