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

141–150 of 178 posts

Re: Interviewing programmers: coding test example explained

#141

Post by akeefer »

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've personally interviewed way, way too many people with impressive-looking CVs that couldn't code worth anything. Some people probably exaggerate their experience and some people I've seen end up in manager/"architect" roles that don't require actual coding and seem to forget how.

Also, when you're hiring, you're getting a skewed picture of the overall programming population. Suppose (to make the math easy) that there are 100,000 programmers in the world, 90% of which are employed. So that leaves 10,000 programmers in the candidate pool. Most of the top 20% of those will be able to get a job from a referral and not go through a "normal" hiring process, so if you're screening resumes you're now down to the next 80%. But that's the bottom 80% of the 10% that's looking for a job. Of those, some are competent people between jobs or looking for a change, but a lot of them are just in the bottom 10% of the overall skill level, are basically unhirable, and are semi-permanently on the job market because of that.

To make another simplification, if you and I both screen 100 resumes in the same area, there's a reasonable chance that the 10 best candidates we see are different since they go off the market so quickly, but that the 10 worst candidates we see are the same, since they stay on the market. And unfortunately, some of those totally unhirable people have good-looking resumes.

Re: Interviewing programmers: coding test example explained

#142

Post by sokoloff »

akeefer wrote: post #141
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've personally interviewed way, way too many people with impressive-looking CVs that couldn't code worth anything. Some people probably exaggerate their experience and some people I've seen end up in manager/"architect" roles that don't require actual coding and seem to forget how. Also, when you're hiring, you're getting a skewed picture of the overall programming population. Suppose (to make the math easy) that th…

And unfortunately, some of those totally unhirable people have good-looking resumes.

Often because they've had PLENTY of time to work on their resume and plenty of feedback on what works and doesn't (for small values of "works")

Re: Interviewing programmers: coding test example explained

#143

Post by dkersten »

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…

Replacing the 3 additions of gapin the loop with a single subtraction (and an increment):

  void condense_by_removing(char* z_terminated, char char_to_remove) {
    int offset = 0;
    for (; *z_terminated; ++z_terminated) {
      if (*z_terminated == char_to_remove) {
            ++offset;
            ++z_terminated;
      }
      if (offset > 0) *(z_terminated - offset) = *z_terminated;
    }
    *(z_terminated - offset) = 0;
  }

Re: Interviewing programmers: coding test example explained

#144

Post by loup-vaillant »

Daniel_Newby wrote: post #111
loup-vaillant wrote: post #69

Earlier quoted context omitted.

Yes, but in doing so, you traded a memory write for a branch. And memory accesses are linear, so that's likely faster than the cannon. So surely we could go further? That's how I got the idea.

Many compilers will implement d += *d != c; with a branch, and depending on the data pattern the branch predictor will be bamboozled. The branchless version would involve a pair of subtractions and some bit banging.

Gasp! I thought it would be easy to just transfer the compare flag to a general purpose register. I suppose x86 doesn't have such an instruction?

Re: Interviewing programmers: coding test example explained

#145

Post by nuxi »

Xurinos wrote: post #77
tedunangst wrote: post #71

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…

I'm not convinced that NUL vs. C's "null character" is just a silly semantic argument. NUL is an ASCII abbreviation and the implementors probably wanted to avoid being tied to a particular character encoding - there is no mention of NUL in the C standard.

As for the NULL, it needn't be a pointer value, the standard permits it being "an integral constant expression with the value 0", so in certain implementations it can be the same as '\0'.

Re: Interviewing programmers: coding test example explained

#146

Post by avar »

cperciva wrote: post #127
avar wrote: post #63

Earlier quoted context omitted.

Actually it's the NULL pointer by definition. 0 is always equivalent to NULL in pointer context, even though you're working with some hypothetical crazy system where NULL is actually #define NULL 1337. It's mandated by the standard. If (NULL == 0) isn't true you're not using C.

Whoops, I forgot the point I was trying to make. NULL is (void * )(0), but the code void * p; memset(&p, 0, sizeof(p)); assert(p == NULL); isn't necessarily valid, since the binary representation of NULL isn't necessarily as a sequence of zeroes -- even though everybody writes code which assumes that it is.

Yeah, that's unportable. Although I'm not aware of any system where it doesn't work.

For the record, regarding 0 in pointer context the C standard has this to say:

       An integral constant expression with the value 0, or such an
    expression cast to type void * , is called a null pointer constant.  If
    a null pointer constant is assigned to or compared for equality to a
    pointer, the constant is converted to a pointer of that type.  Such a
    pointer, called a null pointer, is guaranteed to compare unequal to a
    pointer to any object or function.

    -- C89/C90 section 3.2.2.3 Pointers
The standard then goes on to say that NULL is a macro that's guaranteed to expand to a null pointer constant.

Re: Interviewing programmers: coding test example explained

#147

Post by btilly »

tptacek wrote: post #137
btilly wrote: post #108

Earlier quoted context omitted.

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 (impli…

I wasn't making a recommendation about who to hire. I was telling someone where they had room to learn more about an important topic.

In any case I don't care whether people can quote from Code Complete. What I care about is that they have good enough instincts that they can wind up writing reasonable code that I'd like to maintain. If you don't understand why people would want function names that describe what a function actually does, I don't want to maintain your code. Nor, in the long run, are you likely to be productive.

But it is a bar to meet, not a standard to judge by. Once you've met that bar, I don't care about the difference between OK, and best in the world. I'm on to caring about other things. Like productivity. Code quality and productivity isn't either/or. It is an and. (I've had to clean up enough after the super-productive producer of crap, and don't want to do it again.)

Re: Interviewing programmers: coding test example explained

#148

Post by JoachimSchipper »

wmil wrote: post #131
mynameishere wrote: post #43

Earlier quoted context omitted.

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.

It's worse than that, actually: the C89/C90 standard allows this behaviour. Yes, many programs would break if compiled with such a theoretically conforming compiler.

Re: Interviewing programmers: coding test example explained

#149

Post by Daniel_Newby »

loup-vaillant wrote: post #144
Daniel_Newby wrote: post #111

Earlier quoted context omitted.

Many compilers will implement d += *d != c; with a branch, and depending on the data pattern the branch predictor will be bamboozled. The branchless version would involve a pair of subtractions and some bit banging.

Gasp! I thought it would be easy to just transfer the compare flag to a general purpose register. I suppose x86 doesn't have such an instruction?

I lied! A quick test shows that GCC uses the x86 SETE instruction (set register on condition equal). Cool.

However, code like this:

    if (x == 14) {
        y = 10;
    } else {
        y = 20;
    }
uses branches, although I think x86-64 has conditional load instructions.

Re: Interviewing programmers: coding test example explained

#150

Post by JoachimSchipper »

bkz wrote: post #117

Funny how readable Python is: def condense(s, remove): return "".join([c for c in s if c != remove]) Cheating (2.6+): s.translate(None, remove)

You are aware that this is, to a C programmer, horribly inefficient? (Specifically, it violates the "in-place" requirement, but the actual overhead of that is dwarfed by everything else.)
Post reply on HN