It is better to hire fewer employees that last. That is, more effort should be spent on retention and less on acquiring as many disposable employees as possible.
Most of the big companies treat their employees like trash and lose them rapidly. They think "Well we pay a lot so we have tons of people banging on our door to work for us, so we don't need to worry about getting new employees." This is a bad mentality.
New software engineers need to always be interviewed by those who are senior to the level at which the employee is being hired for. You will never be able to reasonably determine candidate level if you don't have more experience than they do.
The notion of "always hire employees smarter than yourself" is cute, but you don't have any way to determine rapidly that someone is.
Some recommend take home projects. I don't think those tend to work well for various reasons...
Things I do think work to find good employees:
* Give adequate time for whatever task is assigned during the interview. I nearly always see that the interview is rushed because there is inadequate time given for what is being done. If time is not available, just do a portion of the tasks and quick fail if the candidate does not pass that portion. If they succeed schedule additional interviews.
* Require open source contributions of meaning for higher level candidates. Have an interview ( an entire interview ) centered around reviewing their contributions with the candidate and discussing them.
* An interview ( 1 hr ) of the following type: Tell the candidate "Convince me why I should hire you. You have 30 minutes to present your case. I will say nothing that whole time. Afterward Q&A about what you said for 30 minutes.
* Ask questions of the candidate and don't bother with all the trickery. Bring me any software engineer and let me just ask them about random stuff freeform and I'll tell you if they suck or not within an hour. Don't demand some specific stupid process for interviewing them. You have to trust those you use to do the interview process and give them the authority to determine what the next best questions are always. The moment you turn the process into some "by the book" shit, you will get a shit process.
* If a coding test must be done, it needs to be just like on the real job in that full access is given to use websites to rapidly acquire the information needed to give the best result. Also, let candidate use their own IDE setup, and have them ready to go ahead of time. If anything, give a loose idea of what the coding task will be without details, to give the candidate time to prepare in whatever way makes sense for them to be able to tackle a task of that time.
* Give more time to accomplish tasks. So so so many of the stupid tasks I've been assigned in interviews cannot be reasonably and cleanly done within the 20-30 minutes usually given max to do them. Creating quality software takes time. Rushed software = crap software. Be real.
Possibly those that turned out to be most useful were the importance (and resilience) of integrations (Box guy), the quest to try to create monopolistic situations (Palantir guy), importance of a North star KPI (Facebook guy). But the course has lots of other concepts (understand your customers by doing things that don't scale, focus on what customers want, not on what competitors do, etc).
It's more akin to file diffing. Developers are notified of any differences in snapshots. The developer can they either accept the new snapshot, or investigate and fix.
"Where could a public health approach to violence be introduced next? One possibility is London, where in 2017 knife crime among under-25s reached a five-year high. In recent months, the Metropolitan Police commissioner, Cressida Dick, and the mayor, Sadiq Khan, have been among those calling for a public health approach."
Just to add a few details, Cressida Dick is the person who ordered the execution of a brasilian electrician, down in the London Underground. It does not surprise me that aristocrats are in favour of a medical approach to crime: to help enforce the state monopoly on violence itself.
I agree, and try to write all my react without it, using redux, thunks and reselect heavily.
I think it's easy to say it was a design error with hindsight. I'm happy React came along, and in the future it will either get better or we'll move on to something else, heaving learnt from it's mistakes.
My theory is that any technology that can be simpler will be replaced by one that IS simpler.
New technologies like react either need to fix their problems like lack of integrated state management or be replaced by something that does do it right.
I read your 2nd sentence as "the view library needs to become a framework".
Integrated state mgmt is out of scope for React JS per se. Some ppl feel mobx is a better approach than redux. They're free to mix n match libs to suit their prefs. The React ecosystem is a set of libraries; by definition that entails more choices, more "fatigue", more combinations of approaches, and more innovation, compared to all-inclusive frameworks like Angular. Don't get me wrong; Ng gets some things right, and there are valid reasons to deliberately limit choices and go all-in w/ a framework. But I respectfully disagree thst React "needs" to integrate state management.
That's a symptom of people not understanding the concept of complexity and falling victim to the law of leaky abstractions.
People don't work towards reducing complexity in large applications (which involves trimming dependencies, removing api surface area and minimizing interactions between different people's code, which is all hard), they work towards reducing complexity in simple toy applications (which is about cramming as many tools in until you can do exactly one specific thing in one short line and it looks nice).
That has the effect of reducing complexity at first glance, but increasing it in real world applications.
> As demonstrated by the instant downvote of my comment, media that isn't explicitly controlled is generally self-censored to protect the mythical reality supporting the war effort.
The downvotes of your comment don't demonstrate that.
You're making insensitive assertions with no evidence to back them up. Further, others have made more intelligent contributions on the rights and wrongs of certain state powers without getting downvoted.
Certain people seem to be annoyed that they don't just ask questions that can't be verified and take the candidates word at it.