This really just highlights the difference between the artificial coding interview via some web based half-assed IDE, and being watched coding on the job.
The comparison would be more direct if the surgeon was asked to operate on a dummy using a kitchen knife in front of the interviewer.
Then there's the problem that there's no way in hell a software company is going to let another company watch their employee work on proprietary code.
>If Software Engineers want to get rid of algorithmic interviews, all they have to do is come up with a professional exam and a strict licensing body... just like most professions carrying a tittle (MD, Lawyers...).
By the time the exam is designed - not complete, designed - it will be obsolete. By the time the exam is completed, there will be 3 new languages invented.
This would be like changing what animal you have to study as a doctor every six months for the test.
Our imperialism, weapons tech, and exploitation of the working class are top notch. The amount banks take from people with no money in overdraft fees alone should be cause for a revolution.
>Ask HN: Do you think Agile/Scrum is beneficial for software delivery?
Yes.
>Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
It is. Management being able to change direction every 1-2 weeks is fantastic for management but can be really bad for burnout.
Every day you have to talk about what you worked on and what you planned to work on like you're toddlers who can't be trusted to do work.
Every two weeks you have agonizing meetings where you're expected to analyze the past weeks, and come up with plans to improve them as a team. This sounds good on paper but after years of it, you mostly want to shoot yourself.
And that's assuming your team doesn't agree to a 1 week sprint, where the total meeting load can be 10% of the time spent working.
And that's at companies that are pretty good at it.
So yes, it's good for software delivery. But for something called agile/scrum, it's awfully process heavy, and it sucks as an engineer.
My professor (head of CS dept) referred to these as 'weed out classes'.
If that sounds evil, imagine the grief, wasted money, time, frustration, and stress of letting people get 3-4 years into computer science and then dropping out because it's fucking hard.
So my second hardest classes were freshman year. 3rd year (micro-architecture and assembler)finally bested them.
>The people who know the domain should be able to maintain (and really, create) any automation of that domain themselves.
This is a recipe for disaster 100% of the time. One needs to know both the domain and software to change software in the domain. People who 'know the domain' but not software, when given the tools to modify software within the domain inevitably create an unmaintainable rats nest of more difficult to change rules, almost invariably in some proprietary WYSYWIG tool that creates more problems than it solves.
Such a shame.