Live data from Hacker News

Interviewing programmers: coding test example explained

solipsys.co.uk

101–110 of 178 posts

Re: Interviewing programmers: coding test example explained

#101
post #88

Earlier quoted context omitted.

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!

perl -pe'BEGIN { $x = quotemeta(shift) } s/$x//g;' should do what you want. `quotemeta' is the function that does the escaping for your properly. I was hoping to be able to use tr///, since it seems like it was built for this, but it creates its conversion tables at compile time, so there's no chance to interpolate the argument without some nasty nasty eval'ing.

Yeah, tr was my instinct as well.. Thanks for quotemeta, it helps with something I'm working on right now!

Re: Interviewing programmers: coding test example explained

#102
post #93

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 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?

I assume you read http://en.wikipedia.org/wiki/Hoare_logic ?

Basically, the (relevant) state of the computation is represented as a set of logical propositions which are true before a statement, and a set of logical propositions which are true after the statement. For each kind of statement the language supports (`if` statements, `while` statements, etc.) there are natural ways to reason about those triples.

Do you understand the "While rule" on the link above? I can explain it in natural language, but I'd rather not expend the effort if it's not something you've already seen.

Re: Interviewing programmers: coding test example explained

#103
post #99
post #89

Earlier quoted context omitted.

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…

His logic is that you are in fact "dinging" the candidate. He used an artificial scenario to illustrate that.

In reality, you never have two candidates who are absolutely equivalent except for spelling ability. The interview process is extremely high-error, brutally timeboxed, and infamously ineffective. The most important capability you need to assess is "ability to code". You know a priori you're going to do a crappy job assessing that capability.

Whether or not he thinks you should be wasting time on trivialities like variable name spelling (I myself would dodge this problem by using names like "x" and "cp" for utterly trivial, well-known example problems like this), I don't know. My bias is pretty clear.

Re: Interviewing programmers: coding test example explained

#104

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…

The problem isn't the job market --- although it is pitiful, and it is dreadfully hard to hire talented developers, particularly in C.

The problem is that the hiring process is necessarily ineffective. You have a very short period of time to come to a sweeping conclusion about the entirety of someone's capabilities. Dev interviewers do a notoriously crappy job at this.

The specific problem "FizzBuzz" tests solve is this: candidates who can talk about development (including people who know that the difference between otherwise equivalent for() and while() statements is whether the increment runs when you hit a "continue"), but who, when asked to sit down and code something, fumble horribly.

These people, all of whom are smart and extremely knowledgeable about software development, have not developed the real world programming survival skill of being able to sit down and just code when they need to. Most development shops want to avoid these people. Hence: a test that isolates specifically your ability to just start coding, apart from any domain knowledge or computer science.

Re: Interviewing programmers: coding test example explained

#105

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 p…

fgets() bug/hack/exploit? You mean gets(), right?

Re: Interviewing programmers: coding test example explained

#106
post #99

Earlier quoted context omitted.

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…

His logic is that you are in fact "dinging" the candidate. He used an artificial scenario to illustrate that. In reality, you never have two candidates who are absolutely equivalent except for spelling ability. The interview process is extremely high-error, brutally timeboxed, and infamously ineffective. The most important capability you need to assess is "ability to code". You know a priori you're going to do a crap…

Let's clarify terminology first - I shouldn't have used the word "autoding" because it's slang and its use in another message board that I visit may not be universally accepted. I meant "an automatic disqualifier" - a condition that would completely negate any positive aspects.

Under that definition, I don't see any way to construe my earlier remarks as meaning that I would such a high importance on spelling of variable names.

Re: Interviewing programmers: coding test example explained

#107

Earlier quoted context omitted.

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 p…

fgets() bug/hack/exploit? You mean gets(), right?

Er, probably. Brain fried, too much multi-tasking. Sorry.

Re: Interviewing programmers: coding test example explained

#108

Earlier quoted context omitted.

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 m…

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.)

Re: Interviewing programmers: coding test example explained

#109

Earlier quoted context omitted.

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.

I think p_wt is better than p_wr. Honestly though, aligning the length of variable names is, in my humble opinion, retarded - he should have went for p_read and p_write.

Re: Interviewing programmers: coding test example explained

#110
post #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…

This is what I came up with, but I'm not a C programmer.

  void condense_by_removing(char* z_terminated, char char_to_remove) {
    int index;
    int write = 0;
    for (index = 0; z_terminated[index]; ++index) {
      if (z_terminated[index + write] == char_to_remove) {
        ++write;
      }
      if (write > 0) {
        z_terminated[index] = z_terminated[index + write];
      }
    }
  }
Or, getting rid of index:

  void condense_by_removing(char* z_terminated, char char_to_remove) {
    int write = 0;
    for (; *z_terminated; ++z_terminated) {
      if (*(z_terminated + write) == char_to_remove) {
        ++write;
      }
      if (write > 0) {
        *z_terminated = *(z_terminated + write);
      }
    }
  }
Post reply on HN