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

131–140 of 178 posts

Re: Interviewing programmers: coding test example explained

#131

Post by wmil »

mynameishere wrote: post #43
tptacek wrote: post #36

Earlier quoted context omitted.

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 think you exaggerate. If you actually look at advertisements for c/c++ developers, they tend to contain words to the effect, "Must have 4-5 years experience in high speed algorithmic trading", etc. But if you know any good-paying jobs that only require the skill level you suggest, point me in that direction. (I mean that--I can get away from my current huge and horrible codebase. Speaking of which, I remember being…

In the original C implementation function names could be as long as you wanted, but the compiler only looked at the first six chars.

Re: Interviewing programmers: coding test example explained

#132

Post by cabalamat »

rottencupcakes wrote: post #92

So, I've never been involved in hiring, so I have no perspective on the state of the job market. However, I have trouble believing that anyone who would be willing to rep themselves as a "C Developer" couldn't write this particular piece of code in a manner similar to the author's solution in a matter of minutes. Do these FizzBuzz articles keep getting promoted to the front page to boost everyone's collective egos, o…

> I have trouble believing that anyone who would be willing to rep themselves as a "C Developer" couldn't write this particular piece of code in a manner similar to the author's solution in a matter of minutes

Believe it. A friend of mine once got a job as a Cobol programmer (he didn't know Cobol but said he did). He managed to bluff his way through the job until the company went bankrupt 6 months later!

Re: Interviewing programmers: coding test example explained

#133

Post by callahad »

Vocalspace wrote: post #119

Sadly, the code YOU wrote is suboptimal. It doesn't check for bad pointers, has no comments, doesn't take memory corruption into consideration, and assumes the replacement character is not '\0'. You would get a C- if I graded your test. Now you'll argue that it's just a test, but the fact is your best work should not come only when under unexpected scrutiny, as it does with impromptu tests, it should be a mental proc…

has no comments,

Does the copious prose not count?

Re: Interviewing programmers: coding test example explained

#134

Post by gjm11 »

jemfinch wrote: post #74
edanm wrote: post #68

Earlier quoted context omitted.

I think for loops are better than while loops for looping over arrays. I'll try and explain my reasoning: Whenever you see a `for` loop, it tells you something that a `while` loop doesn't. It tells you the kind of loop you're about to do. A `for` (usually) means you're going to be looping over an array, with a specific length, with a specific "step" (usually one). This is information you immediately get by seeing a `…

> I think for loops are better than while loops for looping over arrays. I'll try and explain my reasoning: > Whenever you see a `for` loop, it tells you something that a `while` loop doesn't. It tells you the kind of loop you're about to do. I won't disagree with that in theory, but I don't really think the "for" loop is the solution. The real solution, I think, is a "foreach" construct (whether it's a loop built in…

> I wonder if anyone has provided a suitable Hoare triple for C's for loop.

Basically the same as for a while loop, as given e.g. at http://en.wikipedia.org/wiki/Hoare_logic since (apart from the behaviour of continue)

  for (inits; cond; steps) { body }
and

  inits;
  while (cond) { body; steps }
are equivalent. And if you do want to deal with continue (and presumably also break) the Hoare stuff gets awfully cumbersome; you're probably better off using informal correctness proofs and writing down a lot of loop invariants.

Oh, all right, here's how you do it. Suppose you have the following three Hoare triples.

  {P & Q0 & !cond}
  body; steps
  {P & body never invoked break or continue}

  {P & Q1 & !cond}
  body
  {P & body invoked continue}

  {P & Q2 & !cond}
  body
  {R & body invoked break}
where Q0, Q1, Q2 are mutually exhaustive (but not necessarily mutually exclusive). And suppose you have

  {P0}
  inits;
  {P}
Then you have

  {P0}
  for (inits; cond; steps) body
  {R | (P & !cond)}
That's if you adopt the convention that any precondition is valid for code that doesn't terminate. Otherwise, you need to do some stuff with loop variants.

  for (char * rd=str; *rd; ++rd) {
    if (*rd != remove) *str++ = *rd;
  }
  *str = '\0';
We can take

P0: str points to a zero-terminated string. P: so does rd, rd and str point to tails of the original string, rd >= str, and what's between original_str and str consists of an appropriately crunched version of what was originally between original_str and rd. Q0,Q1,Q2: true,false,false. R: not needed.

We deduce that at the end of the for loop, rd points to a tail of the original string (P), it also points to a zero character (!cond), hence it points to the end of the original string. Hence what's between original_str and str consists of an appropriately crunched version of the entire original string. Hence all we need do is put on the final zero character, and we're finished.

Re: Interviewing programmers: coding test example explained

#135

Post by RiderOfGiraffes »

gjm11 wrote: post #134
jemfinch wrote: post #74

Earlier quoted context omitted.

> I think for loops are better than while loops for looping over arrays. I'll try and explain my reasoning: > Whenever you see a `for` loop, it tells you something that a `while` loop doesn't. It tells you the kind of loop you're about to do. I won't disagree with that in theory, but I don't really think the "for" loop is the solution. The real solution, I think, is a "foreach" construct (whether it's a loop built in…

> I wonder if anyone has provided a suitable Hoare triple for C's for loop. Basically the same as for a while loop, as given e.g. at http://en.wikipedia.org/wiki/Hoare_logic since (apart from the behaviour of continue) for (inits; cond; steps) { body } and inits; while (cond) { body; steps } are equivalent. And if you do want to deal with continue (and presumably also break) the Hoare stuff gets awfully cumbersome; y…

You should write that up as a proper tutorial - I'm pretty sure a few people here would find it interesting.

Re: Interviewing programmers: coding test example explained

#137

Post by tptacek »

btilly wrote: post #108
angrycoder wrote: post #73

Earlier quoted context omitted.

The counterpoint to this is that if you are they type of boss who would nit pick a candidate over something like this, he probably wouldn't want to work for you anyway. Especially when you take a quirky/cute spelling and try to expand it into inferring all sorts of other traits. It reminds me of people who say they would never hire a developer who doesn't write comments. Really? Writing comments is a precious skill t…

Do you really think that ordering someone to write comments and use good variable names is sufficient to get good results? The relevant chapters in Code Complete may help you understand how much more complicated the subject is than that. (It may also fix your apparent belief that comments are necessarily a good thing.)

If you want to narrow your shop down to the programmers who can quote chapter and verse from _Code Complete_ and who are inclined to care a lot about how people choose to abbreviate or mangle their variable names, that's totally fine. The rest of us can chop up the pool of developers who actually get stuff done. This isn't just snark; the Venn diagram we're dancing around here favors businesses that hire in my (implied) style.

Re: Interviewing programmers: coding test example explained

#138

Post by nuxi »

cperciva wrote: post #126
tedunangst wrote: post #70

Earlier quoted context omitted.

The C standard exclusively uses the phrase "null-terminated" to refer to strings.

Huh, you're right. I wonder when they changed that.

They didn't, it's there from at least ANSI C89 (ISO C90): "A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string literal."

Re: Interviewing programmers: coding test example explained

#139

Post by dkersten »

RiderOfGiraffes wrote: post #125
dkersten wrote: post #115

Earlier quoted context omitted.

Ehh, good point. :-/ The second version is identical to the first, except that it ises the z_terminated pointer instead of a separate index. void condense_by_removing(char* z_terminated, char char_to_remove) { int gap = 0; for (; *(z_terminated + gap); ++z_terminated) { if (*(z_terminated + gap) == char_to_remove) { ++gap; } if (gap > 0) { *z_terminated = *(z_terminated + gap); } } *z_terminated = 0; } Interestingly…

Have you sent it in? You should ...

I missed your post the first time around and only did that today, so I assumed it was too late to send in.

Re: Interviewing programmers: coding test example explained

#140

Post by [deleted] »

dkersten wrote: post #115
anatoly wrote: post #112

Earlier quoted context omitted.

I see what you're trying to do, but it won't work this way. Since your termination condition is z_terminated[index], you must never look beyond index, yet you access [index+write]. This alone means the code's buggy. The second version is similarly flawed. Note that your code instantly becomes much easier to understand if you rename the variable 'write' to 'gap'.

Ehh, good point. :-/ The second version is identical to the first, except that it ises the z_terminated pointer instead of a separate index. void condense_by_removing(char* z_terminated, char char_to_remove) { int gap = 0; for (; *(z_terminated + gap); ++z_terminated) { if (*(z_terminated + gap) == char_to_remove) { ++gap; } if (gap > 0) { *z_terminated = *(z_terminated + gap); } } *z_terminated = 0; } Interestingly…

[deleted]
Post reply on HN