Off the top of my head, a cron scheduler for a server that reads from a database and sets a timeout upon boot. Every time the server is reboot the timeouts are reinitialized (fail safe in case of downtime). If upon boot there’s a timeout > 25 days it’ll get executed immediately which is not the behavior you want.
I once froze in an interview when asked a simple technical question - I'd been giving a presentation for an hour on how to launch a new product and I was asked by the CEO how to do something technically trivial - my brain could not do it. So he probably thought I was some marketeer pretending to be technical - which isn't really true.
I suspect quite a lot of people who are labelled as "can't code" are freezing like I did.
- give them ~30 minutes on their own machine
- they get to pick the language they code in
- I leave the room for large parts of it
- I bring them a drink
- I tell them I want to see what they can do and that I don't care if they complete it
- permit them to search on the internet (as long as they don't copy/paste a solution)
I see this usually:
- they finish in a few minutes
- they just can't do it, even with hints
I suspect some do, and some will be a lot when you bunch them all together.
However, counter point, I've had people forced on me through much of my career who just can't code for the most part, and despite being pretty reasonable about it ( it's part of the nature of the work I do ), I'm very rarely surprised by competency.
I once worked with a guy who was an incredibly good developer and I was surprised when he didn't see anything special about the number 64 (i.e. a power of two) - turns out that he'd never done any bit fiddling type work so he hadn't had to think in those terms. It wouldn't surprise me if a lot of people hadn't heard of "mod" either....
A huge majority of programming work is basically just CRUD stuff and other data shuffling. It’s not surprising that someone wouldn’t have needed to work with big shifting (or modulus) in that case.
He was an expert in complex multi-organisation enterprise integration and was the go to guy to work out why horrific distributed transactions were failing... He also did a lot of cool stuff as side projects in his own time - just none of them happened to involve worrying about powers of 2.
You don't actually need mod to do fizzbuzz, even if that's the most obvious way for people who know what mod is.
But without any "real" math at all you can do it with, eg, two counters and some if statements. Or if you recognise that there's a repeating pattern you can work out that pattern manually and just write code to emit it over and over.
Even if that's so, modulus (or at least the concept of remainders) are elementary school math and any competent programmer could bang together an (inefficient) modulus operator in a few minutes.
So even in a language w/o a mod operator, it's not a hard problem if you understand how to solve problems with code.
Unless you specifically want a compiling and running version of FizzBuzz you don't actually need to use or know about the mod operator.
At least for me it would be sufficient if the person used a function like IsMultipleOf(x, m), or Remainder(x, n). This would at least make it clear what the function did even if they didn't get the exact operator.
The other thing to note is that the mod operator works differently on different languages and platforms.
> the mod operator works differently on different languages and platforms
Not with positive inputs, which is the domain of FizzBuzz.
Even if you don't know what "mod" means, if you have no idea know what a remainder is, and that the problem calls for it, and you can't derive the mod operator using integer addition, subtraction, multiplication, and division, then your math and problem solving skills are pretty weak, which FizzBuzz tests.
I stopped using fizz buzz a long time ago. 90% of candidates can't define a 2d array in their chosen language without first filtering the candidates, where you get to about 50%.
Yeah I know how to implement FizzBuzz since it's such a meme, but I've basically never used the mod operator in real code. Maybe it comes up in more math-y code I suppose, but for most backend/frontend/SQL code I've never reached for it.
I’ve used it for coloring alternating lines differently in UI code, and as a lazy way to log only every so many times some loop runs.
I only know it well because it was covered near the beginning of one of the first programming books I picked up (on Perl 5) and it stuck with me because it seemed wild to me that they had an operator for that.
I failed FizzBuzz the first time someone gave it to me in an interview...
The specific failure was that I first attempted to solve by using repeated subtraction. The guy kept asking me to "solve it a different way", or saying "there is a better way to solve this". I tried using arithmetic tables, I tried using results about base10 remainders and I even tried using one of the corollaries to Fermat's little theorem to speed it up for larger inputs... every time I was told I was getting it wrong because "there was a better solution".
In the end he pointed out that the only solution he would accept was use of the mod operator.
Since then I have actively kept a tally: I naturally use the mod operator an average of twice a calendar year, it has always been in personal life code when dealing with complicated geometry problems, the bit of code containing it almost always fails on some edgecase because at the point of using mod it is convoluted.
Honestly sounds like a bad interviewer. repeated subtraction is a good first step and I would try to push more if that was the first implementation. But If you could derive a base 10 remainder you know conceptually what problem the mod operator is trying to solve.
a % b = a - (b * a/b) /assuming a sane language with integer division, else cast a/b to int/
Figuring the above operation (or getting close) is when you should more or less pass, and That's a good point to show the interviewee what the operation is. That should be the point of an interview problem, to show the thought process, not that you know fancy tricks.
But alas, I was shown an XOR swap in an interview last week and spent 3 minutes deriving it on paper instead of 3 seconds saying "oh yeah, a => b and b => a" to a trick that I haven't seen since college some decade ago. The current market loves tricksters, I suppose.
And yes, the actual real world use of modulo is surprisingly sparse, despite easily imagining situations where you could use it.
I am highly reluctant to use type casting as a mathematical function!! I was burnt by early languages struggling with this problem... Even modern languages still have issues with this! Try running this in Python3.11
FizzBuzz is a highly artificial problem. It makes sense that people who are not familiar with it will assume that there is an elegant solution. But in the end the right approach is to be very boring and to notice that you need to check for divisibility with 15 before you check for divisibility with 3 and 5.
FizzBuzz is a problem that doesn't have an elegant solution. That is the point: to see how you approach the problem. (there are 3 possible solutions, each in-elegant in their own way)
I don't like FizzBuzz because it over-weights the interviewees knowledge of the relatively obscure modulo operator. Yes, there are other ways to do it, but the expectation of FizzBuzz is that the candidate has that "Eureka" moment and remembers modulo.
If I need a "Non-Programmer Weed Out" question, I'd rather give a problem that is 1. as easy as FizzBuzz, but 2. is just 'if' statements and loops and cannot be solved by knowledge of a particular operator (or bit twiddling tricks).
Same experience, used FizzBuzz at many places and always got surprised by the amount of people it can filter. The best interview process I've ever ran at a company consisted of a basic FizzBuzz for about 15-30 min followed by a pairing session no longer than 1h30m on a problem that could get as tricky as we wanted to assess their skill level.
We would both test the basics as well as go through with the candidate on how they think, how they collaborate, help them out if we felt nervousness was impacting them showing their skills, and in the end got a much better grasp on how skilled they were than if we were looking at Github repos or giving DS&A trivias to solve.
There is no connection to recent problem with the 737 MAX 9 where a door plug was not installed correctly. Instead, this occurred on an older (previous generation) 737 airplane. The cause of this incident is that the door had not been closed properly prior to take-off.
(original Dutch: "Er is geen enkel verband met de deurplugproblematiek van de 737 MAX 9: het gaat in dit geval om een 737 van de vorige generatie, waarbij de deur voor vertrek niet goed luchtdicht was afgesloten.")
One flight attendant physically closes and arms the door, so it is in automatic mode such that the slide will deploy if its opened, then a separate flight attendant physically checks that it is closed and armed. I have no information the sensor redundancy, but the physical checks are redundant.
How can a plane take off if the door isn't properly closed? How isn't there a detector, and a mechanism that just prevent the plane to even move if the door isn't closed. That's what trains do (and the earlier iteration of this design in train is decades old and really basic: on old trains there's a wire running through all doors which are acting as switches mounted in serial: if one is open, there's no current)
On trains, "stop" is generally a safe action. On planes in the air, "stop" is a deadly action.
As described, that sounds like a mechanism that could potentially go very wrong on a plane. By way of example, consider if the plane was in flight and a door opened: the pilots need full control of the plane in order to land it.
There should absolutely be mechanisms to detect and avoid this situation, but hard interlocks like you're describing could cause catastrophic failures in flight.
> On trains, "stop" is generally a safe action. On planes in the air, "stop" is a deadly action.
Having worked in this industry (edit: train industry) I'm fully aware of that.
> By way of example, consider if the plane was in flight and a door opened the pilots need full control of the plane in order to land it.
Not necessarily. Or at least it depends how you define “full control”: of course everything related to flight is mandatory. But, for instance, the ability to unlock the parking brakes of the landing gear likely isn't something you need while piloting mid-air and this is enough to implement the safety mechanism I talked about.
Also, you could have a bypass for the safety lock in case something goes wrong. For instance in PWR nuclear reactors, you don't want to accidentally overflow the steam generator, so there's one pump, designed to feed it when the reactor is stopped, that is disabled when the reactor is running. But in case of accident you may actually need this pump, so there's a key (literally a physical key) that you can use to disable the protection and make the pump usable in that mode too.
In flight maybe not, but after flight there comes landing, and landing on wheels that have parking brake engaged (because of that interlock) may or may not be safe. Yeah, you can add logic to prevent that, you can add more manual overrides, but eventually there's a point when new feature (even one added "for safety") will cause more problems that it will solve.
That's true that there's a balance between the safety benefit you get from the feature and the overhead it ads for the operators (the key example in nuclear reactor I was talking about has actually caused a issue once leading to the enforcement not an additional procedure around it).
What I meant in my response is that the answer cannot simply be “interlocking in a plane would be too dangerous”, so my original question still stands: why is it the case in airplanes when it looks so fucked up from a train perspective.
> Also, you could have a bypass for the safety lock in case something goes wrong. [...] there's a key (literally a physical key) that you can use to disable the protection
I'm entirely in favor of having a safety mechanism with explicit warnings and a bypass mechanism, with that bypass mechanism being something that should never happen in normal operation.
I was solely arguing against the kind of interlock that a train has where "current can't flow" if the doors are open, since the plane should absolutely be able to operate with the doors open in order to safely land.
I understand what you mean. Just to clarify, when I said current couldn't flow it's obviously some dedicated very low voltage current that is merely supposed to act a sensing mechanism, it's the not actual current powering the train that is being cut hard by the doors.
To answer my question for The Netherlands, it is my impression that cops are held to a higher standard and are punished equally—if not more harshly—than normal citizens when caught.
I have recently heard about a case in Poland where a police officer was punished for not being professional. Something like a Ukrainian made a negative comment about "Polish police" when stopped for speeding or leaving his car or something and the officer responded with something like, "if you don't like it here, then get the fuck out to your country" and that got him some kind of punishment. I guess this would be unthinkable in the US.
Corruption is everywhere, not just in big cities. The more rural the county in US, the greater the chance that "stuff like this only happened in 3rd world countries" is necessary to get anything done [permits especially]. Anecdotal personal experience - living ~30 years in rural Virginia versus ~15 years in a city in upstate NY.
Yeah that one bullet point destroyed any trust I might have otherwise given this service. I was excited to try it until they mentioned blockchain.
There’s no plausible reason to use a blockchain instead of a traditional database, and many possible risks/downsides. So either the company is incompetent, or they’re not really using a blockchain and their marketing is misleading, but either way it leaves a bad taste in my mouth.
Surf's a bit too minimal for my taste, but I found a couple of the other lightweight-ish webkit-based browsers on Linux serviceable, last I checked.
My motivation was I was trying to make a crappy dual-core low-clock Celeron rooted Chromebox with 2GB of memory usable as a light-duty workstation, a couple years back. I didn't find anything not webkit-based that I tried light enough to even be in the running. Firefox wasn't remotely close (nor were close Chrome-derivatives). Even light webkit browsers were practically limited to 1-3 windows/tabs depending on the weight of the pages, before they got unusable.
