The problem with testing algorithms is that it in no way tests intelligence. I would think that 9 out of 10 programmers that know an algorithm would not be able to derive the algorithm from first principles. So you are just testing esoteric knowledge - it's qualitatively no different that asking someone questions about a specific framework / API.
You could make the argument that algorithms tend to be studied more by smarter people, but if that's what you're going for you may as well ask them about their hobbies, and hire the person that is into playing chess, or doing astronomy (or whatever intellectual pursuit you care to name).
If on the other hand you are interested in a person's ability to code, ask them to do so. The last time I had to hire someone, I wrote a small application with one module that was deliberately written in an obfuscated style. I asked candidates to bring that module under control - rewrite it in a readable code style. To do this, successful candidates needed to identify what the current code was doing by examining the public interfaces in a debugger, documenting what the calls seemed to do, prepare unit tests, and then rewrite the module in a readable style. It took about a day for most candidates to do.
At the end of that, you get to see a candidate's ability to read code, use a debugger, write unit tests, write documentation, and write well structured code, which is a pretty good coverage of the typical tasks in a developer's day. I feel this gives a much more realistic assessment of a candidate's capabilities that asking questions about a more or less randomly chosen algorithm.
I don't think someone with an IQ of 80 could program Djikstra's algorithm given a mathematical description of it with diagrams. I'm even skeptical of programming binary search. They might understand an intuitive explanation involving a phone book but I don't think they could program it. And even if they could, I think someone with an IQ of 120 would do it much faster, though both solutions would likely have the integer overflow bug that was even in Java's implementation for a long time. So I think algorithms do test intelligence, just not as well as an actual IQ test. It can easily be gamed by sheer memorization, whereas good IQ tests can't. I agree that other things like ability to play chess would probably test just as well as algorithms. If the industry switched to testing candidates to see if they can solve chess problems, or play a computer self-limited to some specific ELO, you can bet that everyone who was serious about getting a job in the industry would start playing a lot of chess, and those with higher IQs will on average play better chess.
When I have to give an interview and have to include an algorithms section I make candidates type code. Whether that's on a phone screen with a shared online text editor or in person with their laptop / an interview laptop, I want them to type stuff, not just rely on whiteboard pseudo-code and diagramming. As a vim user I discount that their editing environment may not be what they're used to but even if I was forced to use Notepad I could still bang out a function to test the even/oddness of a number (my own fizzbuzz) pretty quickly. So I at least make sure to test coding, even if poorly.
I agree work-sample tests are the best, but as another commenter noted if they take a lot of time for the applicant you're going to get people who refuse that just as some refuse to play the algorithms game. Especially if people have a github repo, especially if some of the projects they've worked on have had more than themselves as commiters, especially if they're currently employed as a developer at some other company that does general software. Unless you're trying to build a top team, which most projects don't need, you're wasting a lot of time trying to rank beyond "would work out ok" and "would not work out at all". I have a section in my phone screen that tests for regex knowledge, I'm primarily just testing to see if they know the concept or if when faced with a problem that regexes can solve (which actually does happen from time to time) they reach for writing some custom parser or not. If they vaguely remember there's a way to specify a pattern and find matches, that's a Pass. If they know grep/their language of choice's regex syntax and can give a full solution, great, I'll rank them slightly higher than someone who just knows the concept, but all I really care about is the concept. If they don't know the concept, that's a strong sign (to me) they won't work out.
I tried to do a semi work sample test with an intern candidate a few months ago instead of a different test, based on experience with a prior intern who struggled on something I thought was basic and left me wondering why I didn't catch that in the phone screen. Basically I gave them some stripped down code from several files that looks a lot like what we have in production (JS, using Backbone) explained the overall mapping from bits of code to what could be shown on the screen, and essentially asked them to add a new component (already written) to one part of the screen by modifying/filling-in-the-functions in a few places. It required them to read and understand some alien code, see what they can ignore, understand what was asked, and then do it (initialize something, pass it around, up to I think 3 indirect function calls of nesting, call a couple things on it). The candidate got through it, I'm not sure the old intern would have...
Regardless, Enigma was pretty low-value intelligence. It would give you things like the daily position of u-boat packs, but generally speaking there isn't much you can do with this type of information - maybe increase the ability of your conveys to avoid U-boats, or increase slightly your ability to hunt them.
The real game was the Lorenz-stye encryptors that were used for communications between German commands. These delivered the strategic information about mid-to longterm movement of units and so on which allowed they Allies to correctly anticipate attacks. These were the messages that Colossus was used to decrypt, as opposed to the Bombes which were decrypting Enigma traffic, and which were largely derivative of earlier Polish efforts to decrypt Enigma.
I read a book a while back https://www.goodreads.com/book/show/1127838.Colossus that looks at all of this in detail. Surprisingly, if the book is correct, Turing seemed to have limited contact with the Colossus effort, and was more involved with the Enigma decryption. The Colossus people didn't seem to be terribly occupied by ideas such as Turing-completeness, they were just building machines that were capable of doing certain operations at high speed.
10ms is the absolute maximum difference in time, if the source was located on a line running through the two detectors. If the source was located on a perpendicular bisector of the line running through the two detectors, the difference in time between detections at the two detectors would be zero. Any value between the two is possible depending on the geometry.
Because Falcon9 is a big launcher taking a serious payload into orbit. This means that the first stage has to have very large engines - so large that they can't be throttled down to hover, they have to kill velocity at the point of touchdown.
It's the difference between slowing your car down gently to stop at a red light, and having your car going at max speed and slamming on the brakes as hard as you can at exactly the right moment so that you will eventually stop at the lights. One is easy to do, the other will most likely get you killed.
If this was true, Lehman Brothers would still be in operation today. Derivatives, by their very nature, are harder to truly evaluate in terms of value, and the chance of them going horribly wrong has already been demonstrated as being non-zero (see GFC).
Lehman went bust because liquidity in the credit markets dried up - i.e they were unable to roll short-term financing to fund longer-dated balance sheet. The markets thought Lehman had big exposure to the US residential and commercial mortgages, hence they couldn't borrow, hence they went bust.
A shame because they weren't actually bankrupt - PWC has now recovered 100% of liabilities with assets to spare.
How long did the recovery take? PWC recovered those assets now, rather than then. In the mean time there was a huge reflation of the stock and housing markets, powered by the Federal Reserve in the short term and a return of confidence in the medium term.
You can't treat mass psychology as an externality. Austerian policies rely in part on disciplining debtors to restore confidence in market transparency and the rule of law. If thousands of households lost their homes when their cash flow could not meet their debt payments, why shouldn't a bank go bankrupt when its cash flow cannot meet its debt payments? Lehman was just the bank that couldn't find a seat when the music stopped, and that's fair.
Yes, but that has nothing to do with the notional value of derivatives or derivatives "blowing up." They had a liquidity crisis because of fear; people stopped trusting their commercial paper and were skeptical of lending to them with repos backed by difficult-to-value mortgage-backed securities.
"The markets thought Lehman had big exposure to the US residential and commercial mortgages, hence they couldn't borrow, hence they went bust."
This is the sort of thing I mean when I say derivatives are hard to evaluate correctly. So yeah, Lehmans totally went bust because of their large amounts of trading in CDS.
It's not so much the problem being simple, but more about it being a problem you have already solved. If you give me a blitter API and ask me to write a composited then yes, I can churn out the required quantity of code with ease each day. I know the problems, I know at least one solution, so I won't ever have to head up dead end alleys, stop and research options on the Internet, discover that I've chosen a really inefficient algorithm that requires a near complete rewrite to avoid, and so on. Ask me to patch an existing code base that I'm unfamiliar with to add a new option on a settings screen, and those 5 lines might take me two or more weeks to write, even though the task is simple.
Firstly, you assert that everyone wants their own big car. This is not true. I don't want one, and I'm not alone in that amongst people living in cities with good public transport.
I choose my mode of travel (including cars) as a function of the time it's going to take to get there, and how much stuff I'm lugging. If I am carrying a lot or travelling out of peak hour, I take a car. If I'm under time pressure, I'll probably take the metro.
In Paris we have Autolib, which is a wonderful car service where you can reserve a car at one station and drop it off at another. There are over a thousand if these stations in the city, so there's normally one near you and your destination. But the brilliance of this is that I can go to work using public transport (because peak hour), gi to the gym after work and then drive home. Or catch public transport to a restaurant in a Saturday evening, and drive home, or whatever. Self driving cars will make this type of system even better because I can use one without having a station near me, I just call a car.
At the moment city centres get clogged by cars because public transport in the suburbs is horrible. But if you can get a car to a transport hub and then commute into the centre, I think a lot of people would prefer that to being stuck in heavy traffic for hours. Maybe not you, but many people.
I personally would prefer it, too – I actually don’t own a car, and live in a european city (Kiel, Germany) ;)
I’m trying to look at it from the american perspective, because I’ve long given up the hope that any non-american perspective is even considered relevant on here.
Actually, self-driving cars, while nice, won’t really improve your abilities inside the city – you’ll still use bus, metro, etc.
The "transport hub at edge of the city" is already a common concept over here, called "Park+Ride", with parking spots usually at places which have bus stations and train stations or metro stops.
>At the moment city centres get clogged by cars because public transport in the suburbs is horrible. But if you can get a car to a transport hub and then commute into the centre, I think a lot of people would prefer that to being stuck in heavy traffic for hours. Maybe not you, but many people.
That is actually the "first mile, last mile" concept the author of the article puts on the table as being an interesting problem to solve and considers autonomous cars to be, maybe, part of the solution.
Cars are still bloody expensive. Many many people make the decision not to buy a car when they live in a city with good public transport. It's only in places like Australia and most of the US where you practically need a car that ownership is ubiquitous. Elsewhere people find that there are better things to spend all of that money on...
I'm not convinced that people linking immigrants and terrorism are particularly worried about the actual immigrants turning out to be terrorists in disguise. It's more a worry that they will just add to the ghettoisation of Islamic communities, which is precisely where this latest crop of French terrorists seem to have sprung from.
> I'm not convinced that people linking immigrants and terrorism are particularly worried about the actual immigrants turning out to be terrorists in disguise.
You'd be really surprised. Your point is a valid one, but one I seldom see brought up - most people are just worried that for every 100 immigrants there's a couple of actual terrorists in the lot... Mostly because nobody's told them how stupid that notion is.
> Mostly because nobody's told them how stupid that notion is.
Oh some people try. Hell, I told that to many people myself. People don't care about things like actually being reasonable. Instead, they're afraid and are looking to rationalize it.
Well, it is possible that ISIS would try to infiltrate operators this way (in fact, they caught a convicted terrorist in Italy hiding as a refugee a few days ago).
Possible, yes. Efficient, not really. If they don't get in this way they'll get in another way - closing down borders is about just as efficient as the ban on drugs at stoping drug cartels.
You could make the argument that algorithms tend to be studied more by smarter people, but if that's what you're going for you may as well ask them about their hobbies, and hire the person that is into playing chess, or doing astronomy (or whatever intellectual pursuit you care to name).
If on the other hand you are interested in a person's ability to code, ask them to do so. The last time I had to hire someone, I wrote a small application with one module that was deliberately written in an obfuscated style. I asked candidates to bring that module under control - rewrite it in a readable code style. To do this, successful candidates needed to identify what the current code was doing by examining the public interfaces in a debugger, documenting what the calls seemed to do, prepare unit tests, and then rewrite the module in a readable style. It took about a day for most candidates to do.
At the end of that, you get to see a candidate's ability to read code, use a debugger, write unit tests, write documentation, and write well structured code, which is a pretty good coverage of the typical tasks in a developer's day. I feel this gives a much more realistic assessment of a candidate's capabilities that asking questions about a more or less randomly chosen algorithm.