Live data from Hacker News

Interviewing programmers: coding test example explained

solipsys.co.uk

91–100 of 178 posts

Re: Interviewing programmers: coding test example explained

#91
Interesting. I didn't try to do the assignment when I read the first part, but just tried it now before looking at the second part. When I started to write the main loop, I felt uneasy when I realized I'd be doing unnecessary copying in the common case when char_to_remove is never found. My code ended up a tad more complex than yours due to desire to avoid that:

  void condense_by_removing(char *z_terminated, char char_to_remove) {
    char *p = z_terminated;
    for (; *z_terminated != 0; ++z_terminated) {
      if (*z_terminated != char_to_remove) {
        if (z_terminated != p) *p = *z_terminated;
        p++;
      }
     }
     if (*p != 0) *p = 0;
  }

Re: Interviewing programmers: coding test example explained

#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, or is the job market really this pitiful? Can someone who has been involved in hiring recently comment with some anecdotal evidence as to what they've seen?

Re: Interviewing programmers: coding test example explained

#93
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 love higher language's foreach construct. Have to work with what we've got though, and in C, the `for` loop is it.

By the way, I don't know what a Hoare triple is, and reading a little on Wikipedia didn't enlighten me. Any chance for an explanation?

Re: Interviewing programmers: coding test example explained

#94
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;

No, you have to do it in c so that there are all sorts of obscure bugs.

Re: Interviewing programmers: coding test example explained

#95

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…

It isn't that pitiful, per se, but there are a lot of people who want to be programmers trying to pass themselves off as actual programmers. Then again, there are a small handful of people who can't code that apply all over the place because no one will hire them. There's more of the unhireables than you'd think.

Re: Interviewing programmers: coding test example explained

#96

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…

To be honest, the people we hire tend to fall down in ways other than coding skills. Sloppiness in following procedures or pure laziness are much bigger impacts. Does anyone have a test for that?

Re: Interviewing programmers: coding test example explained

#97
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.

Yes, but less readable. This is a trivial, sure, but I really dislike seeing misspelled variables. My favorite, of course, is $cue, which usually (but not always) means that the variable in question is related to a queue.

Re: Interviewing programmers: coding test example explained

#98

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've been involved in hiring, I've seen it, it's true. There are people who have excellent CVs who cannot write this code.

Re: Interviewing programmers: coding test example explained

#99
post #89
post #41

Earlier quoted context omitted.

This is not a simple misspelling though. If someone would write 'int countar = 0;' because he doesn't speak English well or whatever, that's fine. But spelling 'write' as 'rite' is indicative of a certain mindset - of favoring a certain quirky sense of beauty or style over clarity. And I didn't say it'd be autoding, just that it lowers my opinion of the author a bit. If the rest was OK that would be noise in between…

Some would argue that if it lowers your opinion of the author it is an "autoding" already (whether you're willing to admit it or not). Take this scenario: You have a single position you are interviewing people for. You've got two candidates with entirely even qualifications. The only perceivable difference between them is that one of them writes interview code with variable names spelled like in the original post. Th…

I don't understand your logic. Two people who are in every respect exactly the same, but one can't spell or at least has weird, non-standard spelling habits. The rational choice here is the person who spells correctly.

My point was, spelling in variable names is only a very minor factor when deciding on hiring or not hiring a candidate. If his reasoning and experience and work ethic etc. are all ok, spelling wouldn't make those factors irrelevant.

When a factor is automatically excluding, that means that no matter how good in other respects the candidate is, I still wouldn't hire him (for example someone with a swastika tattooed on his face applying for a customer-facing job). I never suggested any such a thing anywhere (and I don't think you're claiming I am). So I don't see how you're coming to the conclusion that I think that making spelling mistakes automatically excludes a candidate.

Re: Interviewing programmers: coding test example explained

#100
post #77

Earlier quoted context omitted.

How can "null-terminated" be incorrect when that is the language used by the C standard?

I stand corrected. I looked at my old ASCII tables. This is a silly semantic argument. http://www.asciitable.com/ The character shorthand is "NUL", but the full name is "null". I still stand by my (silly semantic) point that the use of NULL is overloaded here. NULL is a pointer value, not a character value. The string does not terminate at a pointer; it terminates with a magic character. This has, in fact, bitten me…

if '\0' was a legitimate member, it was not a string, it was a character/byte array, probably of fixed size.
Post reply on HN