I have done at home prescreener tasks, as long as they were sub one hour, clearly academic, and patently not related to the business. These are not paid.
I have also done on-site dev tasks and tests which were squarely related to the core business, and have invoiced my day rate each time, which was paid.
If a company asks for more than an hour, for tasks related to their business, and don't want to pay, run, don't walk away, and better still, spread the word so people become aware and avoid them in the future.
This. They pay terribly, the work is usually boring CMS and cookie cutter tasks, and there is undue stress because the overpaid account managers can't even run a basic plan and leave all the coding work till the last minute, even when they knew about it months ago.
Grab a nice cup of tea, maybe a rich tea or two, pen and paper, make an exit plan, execute it, and good luck!
Sad to see it all go. Still have the old Mandrake boxes knocking around somewhere.
I recall it being installed, under the radar, in one London financial company, as a desktop for a trader to build out some modelling and pricing tools. This was their first linux box - all other nix boxes back then were either sun or hp-ux. Happy times.
Careful there! It's easy to paint a broad stroke, when the reality is more nuanced.
When employers adopt a race to the bottom on salary and skill level, then yes, the plumber replaced by an eastern European counterpart, or a programmer replaced by someone who will "do the needful" may feel some resentment.
But it is easy and cheap to paint a nation with the same viewpoint.
I do wonder sometimes, if all the startups that followed Googs lead into open offices have been pranked, much like the interview folks who blindly followed Googs wacky and wanky interview questions, which have also been shown to be a useless idea.
There is probably a pranks team in Goog that publicises the ideas to see who will blindly follow.
A good set of questions - they don't rely on too much esoteric knowledge, and look to see how the programmer would apply any experience gained to date in solving them.
One question we often use early in interviews is "could you show me something neat you have learnt whilst programming?" - we want to see if they have actually programmed before, if they took the time to dig in a bit more than hello world or the fabulous Paula bean (dailywtf classic) and importantly, why they thought it was neat.
Not sure what's worse here - people relying on third party benchmarks (hint: always do your own; see how a tool performs on your data, on your hardware, for your problem set), or the fanboy-ish panic when they are unsettled that a benchmark might make their chosen toy less shiny?
The money moves around and around and around (notionally) a dizzyingly large number of times because the more opaque the process and end product, the less immediate introspection it receives, the less well the average Joe can understand it, and the firm can continue 'alchemy'.
Kudos to the regulators for the arduous task of unravelling the large ball of string and following it to the conclusion!
It reminds me a lot of large code bases. At some point people face a choice between a) forcing sufficient simplicity and clarity that one has a chance of understanding what's going on, and b) saying "fuck it" and letting complexity metastasize to the point nobody really understands what's going on.
The difference, of course, is that with software the opaqueness is pure cost. Whereas in the financial markets the opaqueness is often a profitable resource from somebody.
I think the ability to use YAGNI scales with the experience and abilities of the developer and the team. I have walked into wonderful lean codebases where an experienced hand has kept featuritus down to a minimum, but I have also walked into codebases where multiple kitchen sinks were not only present and plumbed in, but a pile of new ones were ready and waiting by the side to join them, and it was a massive distraction.
