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.
What I don't understand is that surely there must be a wide enough passage for them to have got in in the first place. It may be flooded but if one can walk into them vertically, surely they should be fairly accessible to a diver horizontally. Can't they just follow / be attached to a string or something like that?
My wife and I were doing a dive under very controlled circumstances. My wife tried to swim through a circular opening wider than your outspread arms. She couldn't. Fighting panic (rule 2: dont panic!) She kept trying, growing ever more aware of being both underwater and underground.
Then our dive master reached out and pushed her down a foot, and suddenly her tank could clear the top. From her perspective she kept swimming lower, but that was counteracted by buoyancy and she couldn't tell, with every failed attempt reducing her mental capacity to figure it out.
Fight or flight is not the reflex we need in diving, but it is the reflex we have.
It's a 2.5 km (a bit less than 2 miles) underwater swim. Right now they've been without food for 10 days and are barely able to stand. At the moment they wouldn't be able to walk the distance, much less spend many hours (it was about four hours for the experienced divers, so more for the boys) swimming underwater in unpredictable currents with no visibility due to silt, so if they get confused and let go of the string for a moment in those hours then they die.
As one of the rescuers said, "When it starts raining the flow is so hard you can barely swim against it." - and that's a pro diver, imagine how would it be for a boy who didn't even know how to swim and thus doesn't have the relevant muscles trained. It's also narrow enough so that only one person can fit through, so you can't have the divers guide them by hand, only accompany them behind them.
I think they would have them tied to a rope between divers, so that one of them can pull (gently, in narrow areas) and the other can guide the package to prevent it from scratching the rocks.
It's not logically following to me that just because it's easy to walk through a place it must necessarily be easy to dive through it. Diving is always significantly harder (you're wearing bulkier equipment for starters). It costs more energy to swim through water than it does to walk through air, the water has currents which you have to fight against, and the waters are murky so you have to go slow and can easily get disoriented.
You have those small engines/jets/scooters for divers, so exhaustion from swimming should not be a problem, right? They also can place long glowing ropes in murky water; it's been done all the time in caves (or bind them to scuba divers, one in front, one in the back of a group). Once those boys get proper proteins/water and wait for a day or two to recover, they should be able to work it out, unless rain picks up - they are old enough to be considered adults in some Asian cultures, perfect age for an adventure of lifetime. But then even their current position is under danger as it could be flooded further or if a large flash flood occurs, then all bets are off.
I'm no expert but I don't believe those diving jets are going to help in such an environment because A) takes up space of which they most likely don't have and B) it kicks up a lot of silt and dirt, making visibility conditions terrible. This can make or break such a rescue attempt and be really dangerous even for a seasoned cave diver.
> Narongsak explained that the divers had fixed rope lines along the passageway and distributed oxygen tanks along their route, allowing them to advance through the exceptionally narrow passageway unencumbered by bulky equipment.
The (extremely skilled) divers aren't wearing tanks due to how narrow some parts of the passage are. Using a thruster in a cramped environment is not a silver bullet.
Could it be that the route divers explored != the route the group has taken? So they might have descended using much more difficult route than the one the group took?
Unlikely. I am a Thai so I have been reading a lot of info since the beginning, and most people initially suggest that they shouldn't be in too deep since that Monk junction section is very narrow, steep, and hard to pass, even on foot.
It comes out later that the group frequent this cave many time before.
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.
Think about thin vertical passages.
You can talk trough them easily but diving would be very difficult.
I know nothing about that cave, but passages between caves can be connected by tight restrictions. They might have crawled they way up. And now that restriction is flooded.
Add a bunch of regulator hoses, fins, air supply etc to someone not used to having them attached and the gap needs to be huge to not snare a hose and rip a full face mask off.
Even a semi experienced diver is far less aware of all their apparatus than a human who has been crawling around things since birth
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.
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.
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.
No, I think you let your knowledge of cave diving cloud your vision: this is dangerous, and to enter that situation willingly is brave.
You can make it sound like it isn't by hauling in everything and the kitchen sink in terms of technology but that does not change the ground rules.
In the meantime, with all your knowledge and background you're armchair quarterbacking a rescue operation that is most likely doing what can be done given the tools at hand.
So the people that are doing this are doing it because they feel they have to, because they feel the lives of those kids matter to them even if they have only potential downside for themselves.
That we are even having this discussion is beyond bizarre.
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.
Edit: it looks like you've been making a habit of being uncivil to other commenters on HN (for example https://news.ycombinator.com/item?id=17435527). We ban accounts that can't or won't stop doing this, so would you please not do it anymore?
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.
> 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 :-)
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.
That's just wrong. The the blast from the tank would have to displace water before of the energy of the blast can exit the side or top of the container. That spreads out the energy from the blast and the container would redirect much of that energy upwards both of which reduces the effective radius of the blast.
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 definitely both the cooling (otherwise the cylinder would get hot, just like a can of duster gets cold), and the safety thing. The walls of the container would generally be more than enough to withstand the acoustic shock and send that energy upward as a burst of water, but your real enemy is shrapnel from the cylinder, which the water will promptly slow to non-lethal speeds. I'll agree that a guy doing it in a plastic tank or a smallish metal one would be asking for trouble.
On the flipside, water is used for the periodic pressure testing of scuba tanks, precisely because it is essentially incompressible. So if a tank does blow up during testing, you have a very small expansion and thus very small energy release.
If you draw a curve of gauge pressure as a function of volume, the energy release is the area under the curve, and as the curve steepness goes to infinity (i.e. compressibility goes to zero) the energy released starting at a given pressure goes to zero.
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 :-)
I'd have to do the math (and know the material properties and thickness of the tank walls) before saying one way or the other, whether that scheme is effective.
What it could also be doing, is keep the tank from going off like a missile through the building (added inertia of the water plus it takes much longer for the tank to tip sideways).
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.
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!
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?
My first thought is, "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 the interviewer wants form me, and I don't play guess-the-rules type of games." If this were real code, I'd have context. Not just a snippet. I'd see the things I don't see in the snippet, and I'd know why I'm looking at it and what I'm looking for. In real work, there is always a motivation for everything you do. In this case, there is none. You might as well show a sequence of bits. "What do you think of these bits?"
So by your prejudice, you'd probably categorize me in the first camp. Congrats, you probably turned down someone who's been coding for 20 years. Then again, if this really is the kind of line of business code you regularly deal with, maybe it's for the (my) best.
This is a pattern I see all the time. Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react. They think they came up with something clever, they always do. They have no idea.
I get the impression that good people get regularly turned down because they didn't guess the rules of the game right, or they don't even play because they got an offer at some place that doesn't play these silly games. Then there is so much complaining about talent shortage, and complaining about terrible interview practices, and complaining about having to deal with a stack of 1000 job applications.
> Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react.
Agreed that a lot of interviewing issues that I've seen boil down to a misunderstanding of the rules/expectations of an interview, which can be problematic on both sides. Some examples:
* I've had candidates do poorly on a warm-up question because they expect it will be difficult. Ideally, they would say the easy answer they know, but I've had candidates stay quiet while thinking of a hard solution that doesn't exist, then get frustrated when they find that the easy answer is what I was looking for. On my end, this problem is especially tricky because I don't necessarily want to say that something is a warm-up question.
* I've had candidates who have had trouble because they viewed problems as either too concrete or too open-ended. In some cases, I hope that candidates will notice ambiguities in the problem and ask clarifying questions, or come up with creative alternate solutions. In other cases, I know that a particular high-level structure makes a good, consistent problem, and I want them to follow that structure.
* I've had candidates who have written code that's either too hacky/messy/unpolished or too professional such that it slows them down.
My best advice to interviewers is to be straightforward about expectations and open-minded about what assumptions the candidate might have coming in. For example, these days, I try to explain the code quality balance I'm looking for, something like "I'm looking for reasonably production-quality code that might pass code review, but it's still an interview setting, so it's fine to leave off things like docs and unit tests".
I think my best advice to interviewees is to keep a conversation going and be open about your thought process and your assumptions. If you're interpreting the problem wrong, a reasonable interviewer should be able to notice and correct that. The main failure mode I've seen here is people being hesitant to communicate their thought process or ask clarifying questions, which means the interviewer isn't able to know when the candidate is doing poorly because they've misunderstood the problem.
The last two places I interviewed with, there was none of this puzzling or challenges or problem solving. No warm up questions. No games, no rules. We just had introductions and then chatter about what I've done, the tools I've used, how I prefer to work, that kind of stuff. The second place didn't even ask to see any code even though I'd prepared to show them some and had my laptop open on the table. I presume both places trusted I know how to code and solve problems, since both offered a position and even tried to outbid each other.
I really liked this type of interview. It's not so much an evaluation of coding skill as it is a way to get to know the candidate.
With offers lined up, I turned down interview invites from other shops that were publicly complaining about talent shortage and simultaneously had a needlessly complicated & time consuming interview pipeline. I think companies are overthinking it.
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?" ?
Once again you posted a snippet without context or meaning. Once again it's like "what do you think of these bits?" Except that you didn't even ask a question. You just posted something that is presumably code.
So it's hard to engage meaningfully. Give me motivation. Tell me what I'm doing or why I'm looking at this code in the first place. Show me the context and maybe I will see whether I should care about Z possibly being zero or not. Tell me what the language is or how it handles divide by zero (does it have exceptions?) and I might figure out that we don't give a fuck about divide by zero because it's handled elsewhere or not at all relevant to this snippet. I regularly write divisions without zero check because I know the divisor is a positive compile time constant. Here, I just see a snippet out of context; again my thought is "what the hell does this guy want from me?" Show me real code with real context and a real purpose so we can talk real talk.
What's wrong with my x /= z;? Nothing, it's doing the perspective divide just right. And you don't go about checking for divide by zero because I've already clipped my primitives. There's nothing wrong with the names either.
Sure the snippet you posted could be a snippet from some real codebase but without context it is nothing. What do you think of 100101010100000100010001000110? Sorry, wrong answer! Next guy please. That's also real binary from a real file and it's easy to figure out what it says but hard to say what I want from you. Try it!
> I can only say that I don't believe you've ever worked on large codebases.
I don't suppose the operating systems and web browsers I've worked on are the largest of them all but damn. You can keep your religion though.
In a parallel universe, a candidate who is worried about a divisor of zero has his head stuck in the tiny details and is unable to do big-picture thinking. Personally I've gone my entire career without seeing a divide-by-zero bug. It's the last thing on my mind. If it's possible for Z to be zero, it will be caught in CI before we deploy/cut a release.
In your first snippet, would you expect a candidate to tell you that `f` might be undefined?
> 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?
As someone who has worked on several legacy JS codebases, I can tell you with certainty that in some kinds of projects you'll find in the "real world", `f` being undefined is infinitely more likely than a divisor being zero. Maybe Freddy isn't blind. Maybe he just has a different background than you.
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!
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?
Asking someone to evaluate code that doesn't mean or do anything seems like a very poor idea. 90% of the important questions are whether you're doing the right thing in the first place, not whether you're using the Hot Trick of the Day.
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?
> Does anyone take the different approach displayed above?
I do. I find getting people to reason about code is a great method of finding who can program. Given we read a lot more code that we write, it's a critical skill. Often people seem to get hung up on the stylistic issues though and don't recognize obvious bugs.
More importantly, it's code _they_ didn't write, so it removes the natural inclination to be defensive about it.
One time an interviewee told me the problem was that the code was in Java. I told them that the majority of the code we write was in Java (as per the job description). They told me that our best option was to rewrite everything in Ruby.
I hope you're more communicative about what you're asking in person than that one liner you introduced the code with here.
I'd fail your interview just because I don't think about whiteboard code the way I think about production code. Yeah, 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 or in pseudocode. It would never occur to me, because of the context, that you're asking me to respond like I'm reviewing production code unless you specifically said that.
> 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 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.
Gosh, I must say there seems to be some misunderstanding of RDBMS concepts in some posts in this thread!
I was writing database systems professionally, back in the days before the RDBMS concept was even a thing. So here's my (enormously long and convoluted) 2 cents worth. Please be sure to pack a sandwich and get hydrated before you continue.
Say you were dealing with doctors and patients, and needed to store that information in a database. Back in the day, you'd typically use a so-called hierarchical database. To design one of those, you need to decide, what is the most common access method expected to be: getting the patients for a given doctor, or the doctors for a given patient? You'd design the schema accordingly. Then, the preferred access method was easy to code, and efficient to run. The "other" access method was still possible, but harder to code, and slower to run. The database schema depended on how you thought the users would access the data.
But that is absolutely what NOT what to do with an RDBMS. Certainly you look at the users' screens, reports, and so on - but that's just to determine what unique entities the system must handle - in this case, doctors and patients. Then you ignore how the users will access the data, and work out what are the inherent logical relationships between all the entities.
Your initial answer might be this. A doctor can have many patients, and a patient can have many doctors. As any competent relational designer will instantly know, this means you need a resolving table whose primary key is a composite key comprising the primary keys of the other two tables. So if Mary was a patient of Tom, you'd add Mary to the patients table (if not already there), Tom to the doctors table (ditto), then add a Mary/Tom record to the resolving table. By that means, a doctor could have any number of patients, a patient could have any number of doctors, and it's trivially easy to write simple, performant SQL to access that data however you want.
But then you'd have a ghastly thought: patients can also be doctors, and doctors can also be patients! Say Tom was also a patient of Mary! Now you need a Tom record in the patient's table, but that would inappropriately duplicate all his data from the doctors table! Something's clearly wrong. You'd soon see that from a data modelling viewpoint, you don't want doctors and patients as separate entities - you want a single entity Person, and a resolving table to relate arbitrary people in specified ways.
So what?!!
So this. IMHO, many developers using relational databases have absolutely no idea about any of that. They design hopelessly unnormalised schemas, which then need reams of ghastly SQL to get anything out. The query planner can barely parse all that crap, let along optimise it. The database has to stop every five minutes to wet its brow and take a drink.
So here's my advice to any inexperienced relational database designers who have actually managed to get this far!! If you can answer the following questions off the top of your head, you're probably on the right track. If you can't, you're lacking basic knowledge that you need in order to use an RDBMS properly:
- what is a primary key?
- what is a foreign key?
- what is an important difference between primary keys and foreign keys?
- what is a composite key? When would you use one?
- what are the three main relations?
- what is normalisation?
- what is denormalization?
- what is a normal form?
and so on.
I'm guessing A_Person is making some up of what he/she said (to be entertaining) (I don't mean the DB facts - which are right, of course, and the questions at the end), but it was an amusing post anyway :)
I imagine you've written more than your fair share of PROGRESS 4GL code in the past .. your qualifications questions are pretty much straight out of the PROGRESS 4GL user guide .. ;)
Nope! I've never used postgres at all. Most of my RDBMS work was done on HN NSFW ALERT - oracle :-) But your comment supports my general point, which is, that data modelling and relational schema design skills are product agnostic; normalization is normalization, as it were.
Yes indeed, I meant PROGRESS 4GL, which was sort of around before all the "RDBMS" hoopla congealed all this wonderful info into a single art. Its just that your last paragraph really sounded like a quote, near-verbatim, from the very guides published by PROGRESS just for the purposes of educating people on how to make their data relatable .. but of course that is because these are natural laws for databases.
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!).
Yes indeed. I haven't checked his research dates, but I was writing database software in the late (uh) 60s and early 70s. I think that was even before "goto harmful". I still remember our standards officer saying, let's try some of this structured programming stuff!
About 20 years ago I inherited enough money to retire on for the rest of my life. But the only evidence of those assets was, a dot matrix printout that anyone could have done in five minutes. So over the next few weeks, I created accounts in the various share registries and online banking websites, and manually cross-checked the printed list against those accounts. All was good, but I wanted to do that on a regular basis, and it was clear that doing it manually, on a regular basis, was not gonna happen.
I am personally -- NSFW SPOILER ALERT!! -- a long time Windows/IE user, and I knew that IE has a comprehensive automation interface. In literally a few lines of VBScript (say), you can programatically start IE, navigate to URLs, parse the DOM, create new local documents, and so on. But although those interfaces are very simple, they're not robust against failures, and have various weird and wonderful corner cases that will sometimes trip you up.
So over the next 10 years or so, I created a robust, general-purpose IE automation wrapper, and wrote some applications on top thereof. The result is that at any time, I can click a few buttons on a handsome user interface, and enter a single master password, at which point my application will automatically log into each share registry and online banking website in turn; download all new and amended data therefrom; transform all data into common formats; store it in a local cache, so it doesn't matter if it later disappears from the website; then creates a single share holdings document, showing all share holdings from all share registries, and a single online banking document, showing all transactions from all accounts at all banks since the start of time. Both documents have dynamic, user-defined sorting and filtering. They also hilite significant changes; check all share holdings against banking credits to confirm that all expected dividends were received; and so on.
In other words, I've completely automated various important financial checks that I simply couldn't do by hand on a regular basis. The downside is, I'm tied to IE - and - several hundred thousand lines of VBScript! If anyone would like to re-write all that code for Chrome or whatever - for free - you're more than welcome to contact me!!!
Well put :-) I was actually taking a subtle dig at folk who say, "just ditch IE, how hard can it be?" If you have an enormous corporate or personal application, the answer could be: "impossibly hard", unless a good fairy appears from the sky and rewrites it for free!
If you wanted to re-write that for Chrome or whatever (including headless) I would suggest Selenium or WebDriver suite, including PhantomJS. However, my knowledge (expert level at the time) is a bit outdated and there are probably new toolkits based on the Selenium/WebDriver protocol, it is a good direction to point you to.
I have had my bank remove records from my online account, or not have the ledger balance add up, so your idea interest me. I contacted the controller of the currency about my bank messing with my records, and they did absolutely nothing.
A lot of it is in fully-franked shares in a self-managed superannuation fund. The fund is now in pension mode, which means it pays no tax on earnings. Where I live, fully-franked shares, in a zero tax environment, get a refund, from the tax office, of all the tax that the issuing companies payed on those earnings!! It's a sweet deal, but actually makes me feel a bit guilty. It's all 100% above board (and managed by one of the big 5 accounting firms), but it means I pay less tax than all my friends and acquaintances, all of whom earn much less than me. Reference: Warren Buffet's secretary :-)
I don't think that would make it much simpler (if that's what you're getting at). There's tons of grunt work that just has to be done - eg. calculating expected dividend payments (by automatically matching portfolio details to dividend schedules from corporate websites), and automatically matching those to bank account credits - all through code. Despite the laughs that the VB languages get on HN, VBScript is in fact, a fully featured traditional imperative programming language, and has all the features you'd expect in such a language (but no IDE :-(). So I doubt that rewriting in python would make much difference. And I'd still be bound to the IE automation model.
> I'm not OP, but I suspect they meant that Python and some libraries would have solved your problem in a few days of work.
I wrote software professionally for 30 years. I have a good understanding of the work required to implement a business requirement! I cant really see myself spending 10 years on a one-week task :-)
> And I'd still be bound to the IE automation model.
Why? You fetch data, calculate stuff and give out reports. Unless there is heavy javascript involved, you don't need a browser for any of this. But now you are dependent on the fragile setup you have created, hopping that VBScript, IE and your datasources will continue to work as long as you live.
Becoming independant and gaining a future ground would be a valid reason to change to a better environment. It doesn't need to be Python, but considering the requirements, Python is a very good choice for this it seems.
All of the websites concerned have strict authorization requirements and none have public APIs afaics. At the start, it just seemed easiest to automatically scrape them. I guess I could have reverse engineer their private APIs and used those - but as the doctors say, the retrospectoscope is a rare and expensive piece of equipment!
Is authorization done with some activeX-applet? Otherwise I don't really see what IE is offering that Chrome offers too, but scrapping-libs can't.
BTW There are libs to use chrome programatically for those things. It's called headless-mode or chromeDriver. Similar things exist for other Browsers. So you could probably rewrite your app to become more indipendant without lossing the existing functionality.
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 :-)
Nope, never heard of it. My software certainly has to click lots of thing! But it also has to do lots of data processing behind the scenes. So the clickety click is only part of the story :-)
