Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interviewing programmers: coding test example explained

solipsys.co.uk

Post reply on HN
Print view View original

51–60 of 178 posts

Re: Interviewing programmers: coding test example explained

#51

Post by nickelplate »

tptacek wrote: post #36
mynameishere wrote: post #26

Earlier quoted context omitted.

Why would he be alone? Why is spelling less important in code than in normal writing? I would argue it is considerably more important.

If you truly think the market for C developers is so favorable to employers that someone who can write the in-place-whitespace-removal function off the top of their heads is easy to find, then by all means, ding candidates for their spelling during interviews. Thanks for making it that much easier for the rest of us to hire. In the industry I work in --- computer software --- it is ludicrously hard to find people com…

I personally would count that against any candidate during an interview. I wouldn't necessarily reject them, but I would definitely count that against them. I work in Toronto, Ontario. English is not my native language, but I always do my best to ensure that my code or documentation is as close to crystal clear as possible. This starts with using correct spelling. Code is written first for humans to read, and to me misspelling in code is no different than poor variable naming. It is the kind of broken window that, when left unchecked or dismissed as "not important", instills a sense of negligence that over time can turn a code base from "decent" to "poor old crappy code".

Re: Interviewing programmers: coding test example explained

#52

Post by cperciva »

loup-vaillant wrote: post #50
cperciva wrote: post #37

I'm sure RiderOfGiraffes doesn't want a third entry from me at this point, so I figure I might as well just post it here: #define C char #define F for #define R condense_by_removing #define V void V R(C*A,C B){F(C*J=A;*J=*A++;J+=*J!=B);} or without #defines: void condense_by_removing(char*A,char B){for(char*J=A;*J=*A++;J+=*J!=B);}

Here is the same code, without syntactic obfuscation: void condense_by_removing(char* s, char c) { char* d = s; while (*d = *s++) d += *d != c; } I would have sworn I found a bug. There is none. Brilliant. Now, I wonder if we could further optimize it. For instance by accessing memory several bytes at a time, in a fashion similar to strcmp().

Optimizing for performance, sure. But I was trying to optimize for character count. :-)

Re: Interviewing programmers: coding test example explained

#53

Post by jemfinch »

I wonder if I'm alone in thinking that the original `while` version is easier to read and understand than the ending `for` version.

I've never quite understood C programmers' love of the `for` loop. It's just a `while` loop with the different parts stuck in different places (`init; while (cond) { ...; inc; }` is the same as `for(init; cond; inc) { ...; }`) and it doesn't (at least for me) result in any greater clarity or ease in reasoning.

Re: Interviewing programmers: coding test example explained

#54

Post by huherto »

His solution is so similar to mine that is scary. I also went thru the same optimization process. (e.g started with a while and changed that to a for later) I didn't go farther because I didn't want to loose readability.

  void condense_by_removing(
      char *z_terminated ,
      char char_to_remove
      ) {
        char *rptr = z_terminated; // read ptr
        char *wptr = z_terminated; // write ptr
        for(;*rptr; rptr++) {
                if (*rptr != char_to_remove) {
                        *wptr++ = *rptr;
                }
        }
        *wptr = 0;
  }

Re: Interviewing programmers: coding test example explained

#55

Post by jemfinch »

ComSubVie wrote: post #12
roel_v wrote: 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.

In that case, I'd suggest `p_rd` (well, IMO, just `rd` would suffice) and `p_wr`. Then they're both fairly unambiguous abbreviations.

Re: Interviewing programmers: coding test example explained

#56

Post by [deleted] »

djb_hackernews wrote: post #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?

[deleted]

Re: Interviewing programmers: coding test example explained

#57

Post by RiderOfGiraffes »

Retric wrote: post #45
RiderOfGiraffes wrote: post #21

Earlier quoted context omitted.

"In place" usually means that the result is in the same place as the input, and you don't create an intermediate copy. Creating a fix, known number of additional variables to assist with the calculation is OK. Some people allocated memory, copied out the input, then put back the bits they wanted to keep. That is not "in place".

Your routine should modify the given zero-terminated string in place, removing all instances of the given char. The main point of the whole exercise is to see if the candidate can write any code - anything after that is a bonus. Now if the input and output of a function are correct I think you where simply less clear than you may have thought. If you had said "string in place (don't allocate any memory), " I suspect…

The main point is as you quote. Secondary points are to see if the candidate can understand common expressions and idioms, and if not, either to look them up, or to ask.

As it says elsewhere, the purpose is to get some code, then use it as a start for the discussion. If someone allocates memory then that's where I start. In that case they clearly they don't understand the usual meaning of the expression "in-place."

  > If you had said "string in place (don't allocate
  > any memory)," I suspect far more people would have
  > given you the output you wanted.
I suspect you're wrong, and I would be interested to see if anyone else comments on that point. I got nearly 100 submissions, and only one (from memory) allocated memory. All the others did the modification "in-place" as requested.

Re: Interviewing programmers: coding test example explained

#58

Post by jemfinch »

loup-vaillant wrote: post #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 thi…

Your code also fails (i.e., reads and writes past the end of the string) if c == '\0' and s is "\0".

Re: Interviewing programmers: coding test example explained

#59

Post by nevinera »

sram wrote: post #47

I always end up using perl when I have to do string manipulations and have let my c skills suffer as a result. Sad. Using perl regexp kills brain cells. #!/usr/bin/perl $in = ; $remove = ; chomp ($remove); chomp ($in); $in =~ s/$remove//g;

Bad boy!

    >hello|goodbye
    >| 
    >>Result is 'hello|goodbye'

    >That's a nice dog you have there.
    >.
    >>Result is ''
I usually handle this with:

    my $pattern = '\\'.substr($in,0,1);
    $in =~ s/$pattern//g;
but it still doesn't feel safe. String operations in perl usually do what you want, but be careful with them!

Re: Interviewing programmers: coding test example explained

#60

Post by RiderOfGiraffes »

jemfinch wrote: post #53

I wonder if I'm alone in thinking that the original `while` version is easier to read and understand than the ending `for` version. I've never quite understood C programmers' love of the `for` loop. It's just a `while` loop with the different parts stuck in different places (`init; while (cond) { ...; inc; }` is the same as `for(init; cond; inc) { ...; }`) and it doesn't (at least for me) result in any greater clarit…

Actually, they are not the same. See the trivia question in the lunk article.
Post reply on HN