Live data from Hacker News

Interviewing programmers: coding test example explained

solipsys.co.uk

11–20 of 178 posts

Re: Interviewing programmers: coding test example explained

#11
hmm, is it normal to assume all strings in C are \0 terminated? What are the memory usage implications for that?

I won't pretend to know C but suppose you have a string that is 'ab{100}\0' and you wanted to remove all of the bs, you'd end up with 'a\0b{99}\0' in memory correct?

Re: Interviewing programmers: coding test example explained

#12
post #8

Am I OCD when I cringe when I see 'p_rite' where he (I think) means 'p_write'? That alone would knock a few points off a candidate doing this test when he's interviewing with me. 'rite' can mean 'write' or 'right' or even 'allright' - why the unnecessary confusion?

I think he used p_rite so that the variable names length is identical to p_read, which can make the code look more pretty.

Re: Interviewing programmers: coding test example explained

#13

hmm, is it normal to assume all strings in C are \0 terminated? What are the memory usage implications for that? I won't pretend to know C but suppose you have a string that is 'ab{100}\0' and you wanted to remove all of the bs, you'd end up with 'a\0b{99}\0' in memory correct?

C works at a very low level. You have lumps of memory, and you can put stuff in it. By convention a "string" is actually a lump of memory with chars in it, and the end is indicated by a '\0'. The lump stays the same size and doesn't need tidying.

This is the source of the notorious "fgets" bug/hack/exploit.

This is not the time or place for a tutorial on C strings and memory management, but suffice to say that some people find it horrible, some people find it easy and obvious. It stems from C being a sort of macro-assembler with a simplistic type system glued on top of it.

ADDED IN EDIT: I don't know why you got down-voted - it's a reasonable question from someone who hasn't done C. I've up-voted you to get you back to "1".

Re: Interviewing programmers: coding test example explained

#14
post #9
post #6

Interesting, when I solved the problem originally on my own, I got to the exact same solution just with different variable names and braces. I suspect that this is probably the most common way to solve it.

Yeah, I had almost exactly the same code. I'm sure most people did too. The only other "obvious" algorithm is the n^2 one.

You will be surprised.

Re: Interviewing programmers: coding test example explained

#15
I haven't touched C in quite a number of years, so I was happy I got something working in pretty quick order that matched my initial brain-boarded algorithm. Years of Java apparently can't wash away C.

As in the article, I started simple and condensed to the version that I actually submitted. In hindsight, I wonder if that is the best approach when answering an interview question via email. In person, there's obvious benefit to walking through optimization (of all sorts, including visual), but if all the other party sees is the final version, they lose out on that demonstration of the process. If you were to receive just the more condensed version from an interviewee, would that be a benefit or detriment to the person? Does it make sense to send an analysis, or is that just risking overwhelming the interviewer?

I've asked for non-specific code samples in interviews before and that did serve to weed out an applicant once, but only because they sent on very easily searched for code (public API example code from a big developer). Asking for any sort of code example or coding example from an interviewer who isn't in the room always introduces the opportunity for cheating. Getting an analysis (I started here and ended up here) would probably help assuage my suspicions.

Re: Interviewing programmers: coding test example explained

#16
I'm nowhere near an experience C coder, but doesn't the in place part mean that you don't create any additional variables or strings and just modify z_terminated? Is that even possible? This is an honest question, because the solution is obvious this way, but a bit harder if you can't create additional variables.

Re: Interviewing programmers: coding test example explained

#17

hmm, is it normal to assume all strings in C are \0 terminated? What are the memory usage implications for that? I won't pretend to know C but suppose you have a string that is 'ab{100}\0' and you wanted to remove all of the bs, you'd end up with 'a\0b{99}\0' in memory correct?

Yes, C strings are \0 terminated and that is what you'd end up with.

Memory management is between you, malloc() and free().

Assuming this were malloc()d memory, if you wanted to free up the unused bytes, you'd probably:

  char *condensed = strdup(z_terminated);
  if (condensed)
    free(z_terminated);
  else
    // out of memory

Re: Interviewing programmers: coding test example explained

#18
post #7

1) In TFA, s/cersion/version/, but that's an amusing typo. :-) 2) Initializing inside the for loop requires C99; is that to be considered idiomatic? I didn't think so. I'll be curious how many submissions were either identical to your suggested idiomatic solution or its K&R equiv: https://gist.github.com/3f4daf24595788258a01 :-)

  1) In TFA, s/cersion/version/,
     but that's an amusing typo.
     :-)
Bother - now fixed. Thanks.

Re: Interviewing programmers: coding test example explained

#19

I'm nowhere near an experience C coder, but doesn't the in place part mean that you don't create any additional variables or strings and just modify z_terminated? Is that even possible? This is an honest question, because the solution is obvious this way, but a bit harder if you can't create additional variables.

The solution in the link only uses pointers to the string. "In place" as I understood it means not allocating additional memory for the string. His code does that, but it does need two pointers (the one passed in, and the one created to keep track of secondary position) in order to traverse the string.

Because the resulting string will only be shorter (never longer), this works. You simply keep track of where you're copying to and where you're copying from, and move character by character until you reach the end. The resulting string may have extra stuff at the end, but since it's null terminated the standard C string functions will not see that cruft as they will stop at the first null.

Re: Interviewing programmers: coding test example explained

#20
And I thought my solution was as simple as possible. If only I decoupled my two increments, I may have avoided this unreadable, inefficient crap:

  void remove_char(char *s ,char c)
  {
    int from = -1;
    int to   = -1;
    do {
      from++; to++;
      while (s[from] == c) from ++;
      s[to] = s[from];
    } while (s[from] != '\0');
  }
Maybe that's why simplicity doesn't actually rule: it's hard to find. Or, people are silly (including myself in this case).
Post reply on HN