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.
Interviewing programmers: coding test example explained
101–110 of 178 posts
Re: Interviewing programmers: coding test example explained
#102Earlier 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?
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
#103Earlier 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…
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
#104So, 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 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
#105hmm, 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…
Re: Interviewing programmers: coding test example explained
#106Earlier 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…
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
#107Earlier 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?
Re: Interviewing programmers: coding test example explained
#108Earlier 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…
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
#109Earlier 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.
Re: Interviewing programmers: coding test example explained
#110Interesting. 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…
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);
}
}
}