A_Person

Apparently you don't read replies to your posts. So I'll email this as well as posting it here for the record. I have automatic copyright to all the posts that I've made to this forum. I now request you to delete all those posts, or at least edit them all to "XXX" (or similar), by close of business on Friday 20 July your time. If that does not occur, I'll engage local US representation to pursue that issue on my behalf. Thanks in anticipation

Obviously we have different ideas about what constitutes intelligent argument. Please delete my account. If you need a formal request to that effect, say here how to submit that.

You said the brits were risking their lives. I said they weren't, at least to the extent that you believed - and explained why in exhaustive detail. But you disagree, based on qualifications and experience that could roughly be described as: zero. I'll speak to doctors Dunning & Kruger and see if they can fit you in next week for a chat.

Try to follow along.

You: the two Brits were risking their lives.

Me: Not really, they'd have been following standard cave diving safety protocols.

You (effectively): Well, a Navy Seal just died, so that proves that it's dangerous.

Me: There's evidence that the Navy Seals weren't trained cave divers - they certainly didn't seem to be equipped as such - so all it proves is that cave diving is dangerous to those without specific training and/or proper equipment - navy seals or otherwise.

You: you'll change your tune if one of the brits dies!

W-T-F?

Here's a short list of how the diving equipment in some of the photos is absolutely noncompliant with proper cave diving equipment. This implies to me that they are not trained cave divers, and consequently, the risks they unknowingly took were enormously greater than the risks the two brits took:

(1) Single tanks! Fine in recreational diving, because if something goes wrong with your air supply (tank valve fails, hose bursts, regulator falls apart, whatever), you can go to your buddy for air, or at worst, bolt to the surface. No good in cave diving, where there isn't any air at the surface, and your buddy might be 20 meters away at the other end of a tight restriction. So all cave divers use twin tanks. We also follow gas management rules designed to let us survive the following two scenarios: (a) At the point of maximum penetration, you get separated from your buddy, and simultaneously, one of your two tanks completely fails; and (b) at the point of maximum penetration, you're still with your buddy, but both of your (or his) two tanks fail. Diving on a single tank is fundamentally noncompliant with all those standard safety protocols.

(2) Hoses curving out around their heads. These are common in recreational diving, but a serious entanglement hazard in cave diving. Cave divers route all their hoses tight-in, to reduce entanglement risks. This is especially important in low or no visibility diving. No properly trained cave diver would leave the house with hose routing like that in some of those photos. Even if an experienced cave diver was forced to use that gear by circumstance or in a dire emergency, she'd fix that up before she got in the water.

(3) K-valves! The top of each tank has a valve, onto which you attach the first stage pressure reduction regulator. Those valves come in two styles: K-valves, and DIN valves. Each style has a rubber O-ring to seal the regulator onto the valve. With K-valves, the O-ring can squeeze out, causing the attachment to fail. That's rare, but can happen. Bad luck if you're a kilometre into the cave - on a single tank - with your buddy at the other end of the restriction!! With DIN valves, the O-ring is trapped entirely within the valve body, so it can't pop out. For that reason, few if any properly trained cave divers would use K-valves.

(4) Funky hand held torches! They probably throw a nice wide beam, which is good for recreational dives. But cave divers need narrow beams (to cut through the murk, and facilitate signalling); with multi-hour durations, and hands-free attachments so you can use that hand for other tasks.

In summary, someone who is an experienced brain surgeon, gets into a Formula One car, prangs it, and kills himself. To me, that doesn't say much about the safety of properly trained and qualified Formula One drivers.

But you say that the death of a person, who may have had zero formal training in cave diving, says something about the safety risks the two brits took? Perhaos two of the most experienced expedition cave divers in the world?

I think you do not understand the issues. I don't intend to reply again.

Given that I'm sitting at home watching TV - and they're all busting their asses off in the cave - it's hard to discuss this without being disrespectful to them - which I certainly don't want to be. But anyway...

Looking at some of the photos, lots of the gear they are wearing is ordinary recreational gear - nothing like what an experienced cave diver would use. So it raises the question, in my mind, as to whether their navy seals actually do have any formal training in advanced cave diving. Combat diving is unlikely to be the same thing.

So the very unfortunate incident might actually support my previous comment, not contradict it. Cave diving is very dangerous to the untrained or improperly equipped. But proper training and equipment can mitigate those dangers. The two brits would not have been wearing anything like the kind of gear in the photos :-(

Again, kudos to the people on the spot, doing their best.

I don't know that cave at all, but from various descriptions, it sounds like they may have had to crawl through several restrictions to get where they are. So it's not a matter of walking through vertically to get in, then just being gently pulled back out the same way It's a matter of squeezing through on your belly to get in - then to get out, reversing that, in unfamiliar bulky diving gear, completely underwater (literally no air anywhere), in pitch blackness, and zero visibility (as in, you'd not see an inch beyond your mask, even with a powerful torch). It's not easy even for experienced cave divers. I once went through a hole, then couldn't get back out! I tried for 10 minutes. At one point I even considered removing my tanks and pushing them out first. It eventually happened, but it gave me a scare - and that was in crystal clear water, in a site I'd dived before! Its just not as simple as people seem to assume. But again, I don't know the cave in question, I'm just going from what I've read.

You can't be serious. Taking 13 people, with an absolute maximum of Open Water level training (if that), back out through hundreds (or thousands?) of meters of low or zero visibility diving, including (apparently) tight restrictions, without risking the lives of all concerned? Aint gonna happen - unless the water level drops to the point where they can just float back out.

That's really not so. Cave diving has well established protocols for safe navigation, gas reserves, entanglement management, and so on. There's no way they'd have gone significantly outside those protocols. Those brits are highly experienced expedition cave divers, and undoubtedly pushed it further than a weekend warrior like me would do. But they really wouldn't have been dicing with death, as it were.

> claustrophobia can express itself in different ways

Too right. I'm a reasonably experienced cave diver, and regularly dive in a system of 11km of intersecting fully-underwater tunnels, with the single entry/exit being a small pond, a few feet across, in a small, underground air-filled cave. I'd typically go 700-800 meters out, with a dozen navigational decisions along the way (left? right? straight ahead?), then have to reverse all that to get back out. But a few years ago I had an MRI, where you're wheeled into a narrow metal tube, on your back, with your arms pinned to your sides, with the tube an inch away from your face. Result: GET ME OUT!! GET ME OUT!! I had to be wheeled back out & take a break, before I could grit my teeth and try again. I absolutely hated it. I told them I was an active cave diver, but I don't think they believed me :-)

I did know that, but I'm not sure how that applies. In your scenario, the tank ruptures, there's virtually no water expansion, so nothing happens. In my scenario, the tank ruptures, the internal gas content instantly expands by (say) 250 times, creating a massive force which I assume is transmitted virtually undiminished, through the water, to the sides of the container, which promptly explode outwards. I do accept that some of the force will go upwards, but I believe the container will still explode. Not really trying to disagree, just trying to get my head around it :-)

But only by 3% - so I still won't set up my chillout lounge right next to the tank fill station! :-)

I'm no scientist and you may well be right. But I'm skeptical of your statement that "much" of the blast would be directed upwards. If you look at the pictures of tank explosions, they often show the entire room flattened right to floor level - not a big hole in the roof and minor damage everywhere else.

It's always surprised me how many people do not know that water is incompressible! For example, when someone is filling a scuba tank, it's common to put the tank in a large, often metal-sided container of water. When asked why, the shop staff member will typically say: "In the unlikely event of the tank blowing up, the water will absorb the force of the explosion." But in fact, water being incompressible, it will absorb approximately 0% of that force - which is then transmitted undiminished to the metal walls - which then explode like a giant hand grenade, promptly maiming or killing everyone standing nearby! The purpose of the water is instead, to absorb the heat from adiabatic compression, and keep the tank cool.

The other day I dropped in on a local scuba store that I've patronised as a customer and/or instructor for nearly 30 years. They've changed hands recently, and had a few new folk behind the counter. I waited for over 5 minutes, unacknowledged, literally 3 feet away, while two of these bozos had a private conversation. Then, when they eventually dragged themselves out of their customer service torpor - it got worse! And not for the first time. So I walked out, and finally decided to never go there again - and to start bagging them (instead of recommending them) whenever I could.

Scuba stores have traditionally survived on markups from equipment sales. Everything else is a loss leader. But now, people can get a wider range, of better equipment, delivered faster, at half the price - via the internet! Yet STILL, bozos like those guys can not be bothered to service someone who's made the effort to walk in the door!

It makes me wonder how many small businesses go under because of good ol' garden variety hopeless customer service, rather than anything else.

> Wow, congrats on insulting people

I posted a detailed exposition of my own approach to interviewing. I expected nothing more than some intelligent comments thereon.

In response, someone says I'm "prejudiced", and why would he "give a fuck" about my concerns; another says my concerns exist "in a parallel universe"; and another says my views are "religious"!

Equeeze me if I don't take well to copping random insults in what is meant to be an intelligent discussion forum. Particularly from people who've contributed zero to the discussion so far - like you! I suggest you get out of the basement and get some exercise. Maybe ask your mum for a bike?

Quite possibly. I've worked mainly in languages where undefined functions kill the compile, and division by zero is a runtime error. Perhaps JavaScript just facilitates sloppy coding practices? Many other languages don't. Perhaps you're the one with the skewed perspective!

> In your first snippet, would you expect a candidate to tell you that `f` might be undefined?

No. Because I'd expect the candidate to focus on subtle issues, and not waste time on bleeding obvious ones!

Of course f() might be undefined. Blind Freddy knows that. But Blind Freddy can't necessarily see the other (much more subtle) problems in those 4 lines of code.

I want to know, is this candidate more than Blind Freddy? Does he inhabit what some of us call "the real world", where things like division by zero are things to be consciously managed by proper coding practices?

(Edits for clarity)

> it's hard to engage meaningfully

There we agree!

> I don't think about whiteboard code the way I think about production code.

Isn't that the whole point of an interviewer writing code on the whiteboard? To see how the applicant would view that code if hired to work in the offered position? Why would an interviewer want the applicant to view that code in any other way? Is an interviewer likely to think, "I'll treat the interviewee's comments as if he was just writing the code as a hobby throwaway, nothing to do with the offered position"?

> the variable names and magic numbers are bad practice / but it's on a whiteboard. I'm not going to waste time writing long descriptive names out by hand on a whiteboard

Great! But in my post the interviewer wrote the code on the whiteboard. The interviewer did not ask the interviewee to write any code on the whiteboard. Where did you get the idea that the interviewee was to write on the whiteboard? Software development requires attention to detail, yes?

I'm truly bemused by your response.

First, if you truly believe that the code I showed is "a snippet of code completely made up or taken out of context and then anonymized by renaming variables", I can only say that I don't believe you've ever worked on large codebases. There are millions of lines of code, in hundreds of thousands of application, in dozens of different languages, all over the world, precisely like the snipped I showed. If you've been coding for 20 years, as you say you have, and haven't seen snippets like that on a thousand occasions, you must have worked in very strange environments. If you really want me to, I'll spend 5 minutes and give you multiple links to exactly similar snippets in various large open source projects.

Second, I'm mystified by your comments regarding my trivially simple code question. that "Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react".

Wut? Let's make the question even simpler:

    X := Y / Z

Would you not expect an applicant to say, "What if Z is zero?" ? Would you actually expect the candidate to say - quoting you:

"This looks like a snippet of code completely made up or taken out of context and then anonymized by renaming variables. I have no idea what it's supposed to do, I have no idea why I'm looking at it, and I have no fucking idea what you want from me, and I don't play guess-the-rules type of games."

Are you seriously telling me that you'd hire a candidate who said that? Over one who said, "What if Z is zero?" ?

I think one of us is missing something...

My long-time financial advisor has a fantastic saying: "I like to buy low, and sell high!" It's amazing how tempting it is to do the opposite. Wow, thing X has tripled, let's get into that. No!

Huh? (1) It's exactly the kind of code that you'll commonly see in a working line of business application. (2) The entire point of my comment is that I dislike hot tricks of the day as interview questions. What "hot trick of the day" do you see in my post?

Wow! That sounds like a fail to me :-)

It just amazes me that employers ask complicated CS-type questions for ordinary programming jobs. I've been out of the game for 20 years, and only did a few interviews anyway (as the interviewer), so what would I know! But FWIW, here's the kind of question I'd ask.

"I'm going to write a few lines of code on the whiteboard, tell me what you think of them." The code would be something like this:

  If f(a,b) then
    X=6
  Elseif flag1 then
    X=8
  Endif

My bet is, people would fall into one of three camps.

(1) The Bemused :-)

These people would have no idea what to say. That would be fine for a new developer, I'd just prod them in the right direction. For example, "what do you think about inline constants?" But if an experienced developer had nothing to say about that code, that would be a big red flag for me.

(2) The Defiant!

These folk would say, "Gee that looks like very old code, I'm really more interested in functional languages, do you guys do any Haskell?" This would also be a big red flag. First, he's saying that he has no interest in my priorities as the interviewer, he'll just ignore my questions and substitute his own. Second, he shows that he's not really interested in code as such. It's like a guy who says he likes cars, you take him around the corner and show him your one-off Porsche EVO hybrid, and he says "Wow, an infinity pool! What did that cost?" Fail.

(3) What I'd Expect

Here's what I'd expect from an experienced developer, off the top of his/her head:

"Ok, I see in-line constants, and short variable and function names. Those are often undesirable, I can talk about that more if you like.

But the more interesting thing, is that X is only set if one of the two conditions is true. If neither condition is true, X does not get set to anything.

That might be a bug: the programmer meant to initialise X before the first test, but forgot. Or perhaps X is initialised much higher up. But if that was the case, I'd like to refactor the code to bring that initialisation closer to the code on the whiteboard; and/or rename X to something less likely to be used by mistake in the middle; or at least, add a comment saying "X initialised above". Or you could just add an else branch to the code on the whiteboard, to ensure that X gets set even when both conditions are false.

Another slight possibility is that when the first condition is false, the second condition is necessarily true, and the developer has written in the second condition as a form of comment. But in that case, I'd rather make it more explicit, by changing "Elseif flag1 then", to "Else /* flag1 must be true */"; or even asserting that, just to be sure.

Also, if the code in question is really complex, or just messy from years of maintenance, there might still be cases where X does not get set at all. In that case you could initialise it to an impossible value, say NULL, right at the start, then assert not null at the end. Or you could even re-write the code in truth table style, which I can talk about more if you'd like."

Me: "The truth table approach sounds good. How would you do that? What kind of data structures would you use?"

And so on.

Does everyone really use CS-type questions these days? Does anyone take the different approach displayed above?

I just had the exact opposite experience! I was discussing scams with my regular painter. He said he got one recently, and showed it to me on his phone. It was an SMS that said, "Dear <FORENAME>, we have been trying to contact you without success. Please ring BlergCo on 99999 about your outstanding ATO debt". I thought, easy enough to check. I went to the ATO website; clicked the link about what we do if you don't pay; clicked the link about which collection agencies they use; checked for green padlocks throughout; and voila - BlergCo, 99999! Since the number on the SMS exactly matched the number on the verified ATO website, I couldn't see how the scam would work. So I told my painter I'd changed my mind, it was probably legitimate, and he should ask his tax agent to follow it up. Which he did. Then paid the overdue provisional tax that he'd completely forgotten about! It made me think, legitimate SMSs (like that one) should probably have extra words to tell the recipient how they can check that it's legitimate. For example, "NOTE: to verify our company name and contact number, please go to the ATO website at xxx.yyy.zzz (and remember to check the green padlock!)", or somesuch.

Thanks :-)

I just don't see enough cost benefit from rewriting hundreds of thousands of lines of working code at this time. I can't see IE going away, any time soon, due to corporate tie-in. Hopefully VBScript ditto. If it all falls over down the track, I'll review my options then :-)

I remember when 4GLs were the hot new thing. Let's get into those! Oops, nope, forget that, now it's Data Dictionaries, let's get into those instead! Rinse & repeat ...

Further to my other reply, I've just checked the intertubes, and found that Codd's paper "A Relational Model of Data for Large Shared Data Banks" was published in 1970, and Dijkstra's "Go To Statement Considered Harmful" in 1968. So I think my fading memories of all this are accurate (for once!).

Ok. Oracle had/has a presumeably similar thing (PL/SQL). I misread his comment to mean, postgres SQL.