|
What's the deal with hyper-absolutist declarations
So I'm reading this weblog ( http://weblogs.asp.net/Rick_Schaut/archive/2004/03/06/85357.aspx ) that deals with stupid interview questions. It's an interesting read. The question is "explain a ^= b ^= a ^= b;". Whatever.
I'm browsing through the comments and come across the following crazy statement. As with all of these, it starts out quite reasonable:
"I don't want to know the answer to the interviewer's question, nor do I want anyone who works for me to know the answer. Anyone who knows the answer might be tempted to try to make use of the technique at some point in their career."
This is perfectly logical, sane, and right. Bravo. Continuing on:
"There is no reason why that line of code ever needs to come near a compiler. Don't write it. Ever. Don't even think about writing it."
Here we begin to see signs of trouble, though I'd still agree with the above. Nervously. Continuing:
"If you see it in legacy code, fire the person who wrote it (because it probably doesn't do what they thought it did anyway), research the behavior (if you need to match it), and most importantly get it out of your code base."
ALERT, ALERT, ALERT. Here is the insanity. Why? Aren't there any exceptions to this general prescription? Continuing, after I skipped some text:
"The type of person who believes that knowing the answer to that question is a useful measure of engineering ability has no understanding of what engineering is or why it matters."
ALERT, ALERT, ALERT - this is not even true! This is projecting--assigning motives to the interviewer that may not be true at all. If this was a true/false test, the answer would be FALSE. This poster must not have tested well on true/false quizzes, because he violates a central principle of understanding these tests: absolutist statements are ALWAYS FALSE[1].
Why do we, the computer people, have to do this ALL THE TIME? I think that a mandatory interview procedure is this: the interviewer researches the candidate, and finds one such statement ("I'll never work for anyone who drinks espressos regularly! I'll never work for a boss who doesn't know the difference between MAC address and IP address! I'll never X given Y! etc"). Then the interviewer takes time to VIOLATE the candidate's conditional. So long as the candidate's principles are as ridiculous ("Any employer who blocks Hotmail should go out of business."), the interviewer should really poke at the sore spot.
I don't know if this is some sort of pride issue, or just overinflated posturing, but this sort of attitude is rampant. And I hate it.
So stop it already. All of you.
[1] - the statement "absolutist statements are ALWAYS FALSE" is an absolutist statement, and as such is FALSE. Let's try again: "Absolutist statements are usually false, or at the least incomplete." Now, that wasn't hard, was it?
pds
Monday, March 8, 2004
The xor exchanger idiom is something most computer engineers who have been around a while have seen. It is quite useful when doing embedded programming and you do not have any ram memory to spare at all and you need to exchange two variables.
So, although off topic, I don't agree with the blogger or the poster that knowing about this is a bad thing.
I would not want to see it used it regular program code since it merely obfuscates in that context. If I found such a usage in legacy code, firing the person who wrote it seems counterproductive. Best to leave old code alone if it works. Failing that, tidy it up if desired.
Dennis Atkins
Monday, March 8, 2004
Maybe it's not good programming practice, but any good programmer should be able to look at that statement, know exactly what it is supposed to do and how it is supposed to work. Any programmer that has any knowledge about the binary number system that is (which should be all programmers).
Elephant
Monday, March 8, 2004
I entirely agree with Elephant, and the spirit of the original post -- I may not agree with the use of that specific line of code (though it's fairly clever), but it if you have any comprehension of unary bitwise operators, this isn't rocket science, and I would expect anyone with any real experience to be able to look at it and figure it out relatively easily -- the idiom might not immediately be obvious, but if you give it some attention it should be clear. If people really took personal issue with it, I suspect it's because it wasn't clear to them, therefore it shouldn't be clear to anyone but crazies (they took a timeout from their anti-goto/early return campaign).
Dennis Forbes
Monday, March 8, 2004
I've been programming C++/MFC/STL for 7 years and I had no clue what that piece of code did.
Let the insults fly...
Monday, March 8, 2004
Actually it seems like a very good question because if it really is undefined (as the blogger claims, but one of his commenters disagrees), then "try it and see" isn't a reasonable approach. The kinds of questions I hate are the kind that expect you to have something memorized when "try it and see" would work just as well and almost as quickly. But of course when it comes to C and undefined expressions, "try it and see" won't wash.
Kyralessa
Monday, March 8, 2004
Why are there undefined things in C/C++ anyway? I'm certainly not a compiler expert, but wouldn't it have been pretty easy to simply state that anything not explicitly defined in the grammar is illegal in the language. Then you wouldn't get all this goofiness about undefined statements behaving differently in different compilers. Just curious.
dave
Monday, March 8, 2004
As I understand it, it's because leaving some things undefined allows certain optimizations you couldn't use otherwise; it sacrifices safety for speed.
Kyralessa
Monday, March 8, 2004
It does not reflect badly on anyone if they have not seen the xor exchanger - it's too obscure a bit of trivia to expect anyone to know, but it does come it handly. If someone does know about it, perhaps that says something about them, perhaps not.
Comments in the blog are interesting. First, the blogger is not correct regarding the subexpression rule - subexpressions are not involved. But the commenter's point about sequence points is fascinating and correct. From the c++ reference:
http://www.zib.de/benger/C++/clause5.html
I don't see this note about sequence points in the K&R. Thus, the xor exchanger really is undefined in C++, as is stuff like "a = i++ + ++i;", but in C, they are defined.
As I said, the xor exchanger really only makes sense in embedded applications in which case you are using assembly or C most likely so this is not a problem that it is undefined in C++.
On the issue of things not defined in C++, a graver concern is the fact that C++ does not have a disambiguated grammar. In my eyes, this is a serious flaw.
Dennis Atkins
Monday, March 8, 2004
I agree with the blogger. This type of esoteric arcania is picked up too often by dumb interviewers or dumb junior managers as being a useful test for candidates, and it's not.
When lawyers get interviewed, they don't get grilled on the fine points of Joe vs Gro 1923, and doctors aren't expected to describe catalytic formation of esters ( or whatever.)
It's yet another example of the mess that's wrong with software as a profession.
hello
Monday, March 8, 2004
This really is one of those questions that many people think are horrible, but with a good interviewer, and a creative, interviewee, this can be gold. I'd never seen this before, and day to day I seldom have the joy of working with C, or barely anything that involves bitwise operators apart from ORing flags, but I could logically give an answer that it appears to swap values by utilizing xors, but that it'd be suboptimal because various other solutions would yield even more efficient machine code, while remaining clearer to read. Easy enough. Of course, a real super C guru could take it even further, and proclaim that the operation may be undefined on some compilers due to the lack of concrete behaviour in the C spec with multiple assignments of a single variable in a single statement, leading to some compilers to optimize out the value midpoint, leading to undefined results. That would be a great answer.
There are two problems that I think lead to these sorts of questions being deemed unsatisfactory:
-Interviewees who can only compute questions that can yield only one possible discrete answer. "What is the maximum value held by a System.DateTime type?" "<Bleep>The answer is 100 nanosecods before January 1st, 10000". These people are thrown off course by any probing question that has many right (or wrong) answers, and can't liberally interpret. These people have a mental meltdown when they encounter a question like "What are your weaknesses"
-Interviewers who can only compute questions that can yield only one possible discrete answer. Perhaps the interviewer above would only accept "That is an exchanger idiom", and the guy who questioned the use of it would be declared wrong. The various "clever interview questions to make you look really smart" I think cause this sort of situation.
Dennis Forbes
Monday, March 8, 2004
>> "On the issue of things not defined in C++, a graver concern is the fact that C++ does not have a disambiguated grammar."
Yeah, I seem to vaguely remember this from a compilers course in school. I also seem to remember that FORTRAN also lacked a disambiguated grammar. FORTRAN, I think, is in such a state because it was created before all of the language theory machinery existed - or at least before it was popularized. Does anyone know what the justification for this design decision was when creating C++ ?
[DISCLAIMER: My memory ain't so hot, so the above paragraph may be completely off base! :-( ]
dave
Monday, March 8, 2004
Hmmm... can't comment on the statement, but on firing the person who wrote it:
Someone I know who manages the care and feeding of millions of dollars worth of aircraft told me a story about a guy who caused thousands of dollars in damage through accidental misuse of a piece of equipment (not in his shop though). I made a comment about how fast the guy must have gotten fired and he said not if it had been up to him. The reason: once educated as to the damage caused and why it happened, that employee was almost garanteed to *never* make that particular mistake again. If he fired him, he would have no such garantee from his replacement. Is this a reasonable parrallel?
Sorry a bit off topic, but since the firing suggestion was already brought up...
MacSqueeb
Monday, March 8, 2004
I worked in a shop that gave c++ programmers a technical "test". Yep, you were given a test and it was scored.
I think it had more to do with the ego of the test-giver than the skill of the test taker.
Oddly enough, the people that did really well on the test always declined our offers. Once the CTO caught wind of it the practice was ended.
Monday, March 8, 2004
Dennis (Atkins) It's undefined in C as well - the C standard has identical wording, although sequence points aren't mentioned in K&R.
I suppose it's always possible that the interviewer was aware of this, and wanted to weed out people who'd write this sort of thing.
as
Monday, March 8, 2004
Maybe there's a black hole in everyone's monitor blocking the part where I mentioned that this interview question is not the intended subject. Maybe your internet filter(s) blocked the part where I said that this sort of irrational absolutist nonsense is all over everywhere? If you missed it, that's ok. I'll just restate the conclusion:
Please stop making irrational, blanket declarations already. Thanks.
Maybe instead of linking to a programmer weblog I should have done the homework and instead used this:
---
"I boycott everything that involves corporations," said Jennifer Durocher, a first-year anthropology and history student. "I think everything in this world should be boycotted."
source: http://www.doktorfrank.com/archives/001734.html
---
Now, pay attention, because this is where I get to the point of this. If your statement unintentionally resembles the above quote--if you see a correlation--do me a favor. Please rewrite something. If you are about to write "I will never use VB6 again," maybe you could reword that to "I never, ever want to use VB6," or "I loathe/despise VB6, forever," or "I will make every effort to avoid VB6 in the future." See, the third one says the exact same thing as your original statement, only it's less idiotic-sounding.
Now you may all continue discussing the C++ wonkiness.
pds
Monday, March 8, 2004
"It does not reflect badly on anyone if they have not seen the xor exchanger - it's too obscure a bit of trivia to expect anyone to know, but it does come it handly. If someone does know about it, perhaps that says something about them, perhaps not."
Not directed at Dennis, but I advocate that even if someone hasn't seen this, they should be able to figure it out. Personally, I had never heard of the xor exchanger prior. I had heard of a simmilar notion where through additions and subtractions, two integers are swapped without allocating additional memory. Thus, I don't advocate that I made a complete mental leap, but I have never used or seen this used in C/C++ Code before. Seeing it though, I instantly knew what it did.
Thought process could go like this. Operation stored in a, then in b, then back to a. Three steps as in a swap operation (the most common operation with 3 steps). This line of code probably does something useful like a swap because people that ask these sorts of questions don't ask questions that have answers "both a and b now hold garbage values irrelevant to their original values". Use two 4 bit numbers to verify. Yup it's a swap.
A: 1011 \\ 1101 \\ 0110
B: 0110 \\ 1011 \\
If an interviewer asked someone what it did, the answer is pointless if they know the answer. In that case, having them explain how it works could give you insight into a candidate. If they don't know what it does, or don't figure it out instantly, then the thought process on figuring out what it does could have some value. Largely though, I wouldn't ask someone this question as I don't think you can glean enough useful information from the response. I, however, don't agree that the entire class of questions though is useless.
On the topic of ambiguity in C++ statements, I think interesting responses could be gleaned from someone explaining what the possible outcomes of a statement were, what the outcome that the developer most likely expected, and how one would remove the ambiguity to achieve the expected result.
Having never tested my theory though, I don't know if it actually would produce any worthwhile information.
Elephant
Monday, March 8, 2004
"but I advocate that even if someone hasn't seen this, they should be able to figure it out"
That's more dangerous than just admitting you don't know.
you're fired!
Monday, March 8, 2004
as,
I can't find the identical wording in the K&R spec section, but, just now looking again, I did find that the results are indeed undefined in C as well, per section 2.12 pp52-54.
Dennis Atkins
Monday, March 8, 2004
"That's more dangerous than just admitting you don't know. "
ESPECIALLY when we're talking c/c++ here. Enough rope to hang yourself and all that.
Monday, March 8, 2004
you're fired!
Have you never been shown a piece of code before and had to figure out what it did (code maintainence)? Or whenever you're asked to figure out someone else's code you just say, "I don't really know what it does, so I'm going to have to refer you back to the person that wrote it." Untangling a knot of cryptic code while not hanging yourself can be a valuable trait. Not even trying is not an admirable trait.
Elephant
Monday, March 8, 2004
"Please stop making irrational, blanket declarations already. Thanks."
Including that one?
Philo
Philo
Monday, March 8, 2004
There's a big difference between guessing and figuring it out.
Monday, March 8, 2004
Being able to figure things out is good.
Saying you should be able to figure out what that piece of code does DURING the interview is bad.
Very very bad. That's called _guessing_, and as someone who started his career maintaining C & FORTRAN code, I know whereof I speak. Burnt myself plenty.
you're fired!
Monday, March 8, 2004
Why is expecting someone to figure out what a piece of code does during an interview bad? Talk about hyper-absolutist declarations. . . It's all about the thought process, not the answer. Seeing how someone attepts to figure something out during an interview can often be quite useful.
Elephant
Monday, March 8, 2004
IIRC a fav interview question mentioned on JoS (although I've never faced it) is "write a program to reverse a string in place".
Something like:
void strrev(char *start) {
char *end = start + strlen(start)-1;
while(end > start) {
*end-- ^= *start++ ^= *end ^= *start;
}
}
Now if you give a bit of spiel with a normal temporary variable and then announce "ah wait! You can save a register and a bit of stack" etc and reduce it to 3 statements... wow, impressive!
Of course, using a temp would be much much faster on all architectures I can think of, but then again don't expect the interviewer to know that!
i like i
Monday, March 8, 2004
> Including that one?
How witty!
_
Monday, March 8, 2004
Sure.
you're fired!
Monday, March 8, 2004
Why don't people just ask questions about stuff you will be using? Reverse a string: str = reverse(str); Or would I be dumb enough to create my own library or worse, just cut/paste when I needed that code. And of course let me see how many times I've done reverse .... like never. I was interviewed by a guy (famous author) at Yahoo once and he asked me a question and I just said I didn't know. He said he didn't know either, that's why they had reference books. Honest to goodness, it's a shame that people just don't read a programmer's code befoe they hire them.
Me
Monday, March 8, 2004
Me: Then what would all these wankers spend their time talking about?!
:}
Monday, March 8, 2004
Most of the time, the absolute declarations you're hearing are coming from people who are either blowing smoke or have poor self-esteem and need to make themselves appear tough and decisive.
The truth is, good software engineering is about accurately evaluating cost/benefit on everything you do. What's appropriate for a container library isn't important for a data collection app. People that don't taylor their style to market expectations are _bad developers_. If someone writes a complex error handling and recovery system, testing for low memory conditions, etc. for a simple dialog entry form, they're a _bad developer_ because they wasted their own time and the time of anyone who reads or tests their code.
I'm tired of people seeing development methodologies in black and white, when it's really all about cost/benefit and retaining as much simplicity as possible. That's why experience matters in this industry - how good are you at adapting to varying requirements in quality/performance/time to market, etc.?
My experience: For most apps, people who "get it" in non-development areas of their lives (relationships, inner fulfillment, finance, fun) are better developers, since they've successfully demonstrated the ability to calculate cost/benefit and see shades of grey. I believe these skills are generally portable across professions.
Thoughts on this?
Bill Carlson
Monday, March 8, 2004
I think there's a pretty complex psychological process going on behind these declarations. Part of it is a desire to paint the world in absolutes, and part of it is just common hyperbole. Do you think, that if push actually came to shove, that these people would fire an otherwise capable developer?
An interesting (to me) observation is that software people sometimes swing the exact opposite way. Instead of making absolutist statements (which, as you point out, are almost invariably false), I've seen people go through TONS of trouble to avoid making a false statement. And I don't mean in an evasive or weasely way. I mean that A implies B 99.9% of the time, but they don't feel comfortable saying "if A then B" because of that .1%. And even if they don't enumerate the other possibilities, they at least get mentioned.
Brian
Tuesday, March 9, 2004
I have noticed in this profession that I have had a large number of colleagues who like to paint things in absolute terms.
I often wonder if it is a byproduct of working in a digital or binary domain. The computer is something that, when working well, should be behaving in a totally known way. I know many programs are nothing like this but, for example, to get any chance at successfully debugging an app, you need to bolt things down to known states.
Now comes the possibly the more contentious part. Could it be that the sort of people drawn to work with tools like computers like to have things bolted down in absolute terms? In the realm of programming we need to be control freaks to keep things working. However when interacting with people, being a control freak is not going to work that well. I talk from the experience of having trashed one marriage due to being too critical in the relationship towards my ex-wife. Nowadays I know better and try very hard to separate my working mindset from my people interaction mindset.
I do reckon that programming jobs should maybe carry psychological health warnings.
Another possible point is that it is not worth getting emotional with a computer. This then means that we might be more likely to get emotional, and hence absolutist, with people. i.e. the "bottled up intellectual" problem. (We have a guy at work, an ex-chemistry professor, who is well known for throwing chairs around in a tantrums when it all gets too much. Probably good for his health actually!)
Charles Tolman
Thursday, March 11, 2004
Wow! How cool that a comment I made on some random blog was worthy of getting flamed by Joel!
Just for fun, I'd like to respond to a comment of Joel's
> ALERT, ALERT, ALERT ... If this was a true/false test, the answer would be FALSE. This poster must not have tested well on true/false quizzes, because he violates a central principle of understanding these tests: absolutist statements are ALWAYS FALSE[1].
That's a nice bit of rhetoric, but neither the interview question nor any of the discussion surrounding it had anything to do with a true/false test. It was an essay question designed to test the interviewee's knowledge of something (I'm really not sure what). I think my answer gave the interviewer a great deal of information about how I approach problem solving, programming, and corporate norms. All of which are important for the interviewer to understand.
I also stand by the assertion that, if the collective wisdom of the net is unable to agree upon whether K&R defines a repeatable behavior for this code to follow, it is not code that should ever be used in a production system because it will be encountered by a maintenance programmer who will not be able to figure it out and who (possibly) will not even be able to get it to recompile to the correct behavior.
-Don
Don (the original one)
Monday, March 15, 2004
Don:
If you're still checking this, which you probably aren't:
1. I'm not Joel Spolsky. He does post on the forums, but I am not he, and he is not I, etc.
2. This has jumped off of the Joel On Software's main discussion page, so no one will check this page again, unless they click via Rick's new blog entry.
3. I would like to clarify my position, in case you're still reading this. Here it is:
---
The type of person who believes that knowing the answer to that question is a useful measure of engineering ability has no understanding of what engineering is or why it matters."
---
That is your quote. While it's a useful proposition to make, it is too boldly worded. I am not attacking your position; I agreed with your position. It's bad code to write; no one should write it. We agree.
My problem is with your above quote, and your tendency to ... overcompensate. As I said above, this happens EVERYWHERE on the Internet, particularly Slashdot. Here's part of your other quote:
---
"...fire the person who wrote it..."
---
This is posturing. Your overall argument is valid, and your supporting arguments are valid, but was this line necessary? You could have said something else--anything else.
Let me rephrase: it is not WHAT you said, it is HOW you said it. Your statements above resemble the oft-heard:
---
"I swear I'm moving to Canada if [insert some likely political event]"
---
And I hate these types of statements. So, as I said above (and rephrased about halfway through this long thread), please stop doing this sort of thing.
Have a nice day.
pds
Tuesday, March 16, 2004
 Recent Topics
Fog Creek Home
|
