The current issue is that most of the effort is done by humans right at the beginning of the process: CV screening & first calls.
If you're a recruiter, by the time you actually get to talk to a candidate, you're tired of screening and most of the time you do a half-assed call.
Plus it boggles my mind how very very few companies train the recruiters in understanding the technologies they have in their stack.
There are a lot of factors that add an incredible amount of friction and make it a very asymmetric process (as other have said above):
• plain human error
• job specifications with boilerplate text not being clear on what the role actually does
• often times the people doing the first screening don’t have a technical background
• resumes come in all shapes and formats, so it’s difficult to efficiently read them
And because of that asymmetry and supply-demand ratio, it’s actually quite hard to hire software developers that are suited to a company, tech environment & business needs.
(disclaimer, I work at WorksHub)
The way we're trying to solve the issue at WorksHub is by trying to get companies to open-source same part of their code-base so that a developer could submit a few PRs during the interviewing process.
This solves the issue of irrelevant technical interviews, gives an idea of how your coding environment will be right off the bat.
Basically the thing is to do as much of the process as possible using only tech and then leave the last part for the actual human interaction.
I've almost completely switched to decaf coffee (which still has 15-30% the amount of caffeine normally found in regular coffee) after reading "Why Do We Sleep" by Matthew Walker.
And half of the office here is either reading it now or wants to start reading it
The American standard for decaf coffee is to remove 97% of caffeine content[0]. (Note - I couldn't find specific CFRs on an official government site, so it's possible this is just a recommendation and not actually enforced. However, a quick google will confirm that this is the consensus on how things are supposed to operate - I make no comment on how they actually operate.)
> Ugh why did he have to ruin it with the block chain. He probably has enough solar and battery capacity to power all his nearby neighbors every day 24-hours a day
Technically, it's mining cryptocurrencies. Probably at peak crypto mining profitability (around Dec-Jan) it was making significantly over what he could sell to the neighbors; also implying his neighbors would just switch to his infrastructure, that would be a bit of hassle.
Maybe if he hooked up all those GPUs to a render farm, it would be an alternative.
> Apple's attempts to block data tracking as you travel around the web could have a real impact on companies that rely on your personal information to make their billions.
asking the people that working in adtech, cross-device usage prediction and the likes: do you actually think it will disrupt your business or there are always workarounds and are relatively chill about it?
Apple attacks the core primitives of Adtech very strategically with this update. This is very smart actually, much better than the first iteration.
They're going after the meat right away, like cookie synchronization ("Tracker collusion") and the first-party tracker hack that Criteo pioneered, effectively disabling almost all the tracking possibilities on iOS. As a user, this is awesome.
And if you want to track, you need to provide both value (i.e. an authenticated service) as well as get explicit consent from the user.
Unfortunately, this will also serve to concentrate the power in the hands of Google and Facebook, who have and/or will create such authenticated embeds.
Note that all this hardtalk specifically excludes the mobile ad IDs. Apple would face much more headwind from GOOG and FB if they went about killing these. This is going to be very interesting, as Apple will need to carefully tread up to a point, after which there could be harsher repercussions.
They also know that an iPhone without access to Google Maps, Search, Mail, Authenticator, Youtube and a whole lot of other essential services won't be worth much to end users anymore.
Source: I'm working in Adtech, but we chose a different approach of giving users an actual benefit and being careful, compliant and frugal with data. All these recent updates about Apple and GDPR mainly hit the really bad players of the industry that just hoard sensitive data through shady channels and arbitrage it to hell — and I consider that a good thing.
> They also know that an iPhone without access to Google Maps, Search, Mail, Authenticator, Youtube and a whole lot of other essential services won't be worth much to end users anymore.
I don't know. Apple Maps is almost as good as Google Maps for me. Search I could use DuckDuckGo. Mail I use the native iOS mail client and could easily switch out from my GMail account to anything else. Authenticator I don't use and don't know anyone else who does either. YouTube's an interesting one, but I use it tons less since I got Spotify Premium.
If it was a choice between Apple protecting my privacy and losing all Google services these days, after everything players like Google and Facebook have done? It wouldn't be a difficult decision to keep my iPhone.
> They also know that an iPhone without access to Google Maps, Search, Mail, Authenticator, Youtube and a whole lot of other essential services won't be worth much to end users anymore.
Google Authenticator => Authy (it reimplements google auth)
Search => Safari
Gmail => Native Mail (its not like Google will drop IMAP support)
Killing YouTube on iOS would be pretty bad for Apple, but I’m sure that wouldn’t be profitable for Google (cutting off a third of an already-unprofitable company? no thanks). What’s left bedides that, Google docs? Well Apple has their own suite so does Microsoft. And they both have web editors that rival Google Docs and support multi-user editing. In general I’m pretty skeptical about this assertion that Apple “can’t” step on Google’s toes.
Authy encrypts all of your data with a private passkey that is never sent to Twilio (the parent company) [0]. I found the ability to sync 2FA across devices to be convenient and a good compromise to “if you lose your phone, you’re screwed.” I can understand both perspectives, but I think Authy has done a great job at improving the usability of 2FA without sacrificing security. This is certainly more secure than SMS-based 2FA which most people currently use.
(Disclaimer: I am currently employed by Twilio. I am not involved with Authy in any way)
Microsoft Authenticator is another alternative and it doesn't need anything (plus is handy for MS 2fa). There's DUO. And I'd wager there are countless other apps as the standard is really simple.
I used to work in adtech, though not the parts focussed on tracking folks. I think this will cause some disruption for people in the short term, and if Apple stays committed to this line of attack, it could really have a long term impact.
But on the other hand, IP+UA is a very good signal when you don't have a lot of devices behind NAT, and if you just have a Facebook ServiceWorker installed, it could track all of the IP addresses you use. And there is nothing preventing first-party tracking, e.g. what if Facebook starts a "Facebook Publishing Platform" which is basically a section of Facebook.com designed to ensure that you get all the user tracking as before. Or what if publications now ask for "Login with Facebook to read this article".
I think there's actually very minor benefits to the type of tracking that unauthenticated that they're doing, so while they might be able to track less, it won't have a material impact.
while it's true that usually, you need to understand the basics of CS to write good functional code, we've often found that that doesn't need to be 100% correct.
we've placed a good amount of functional engineers from a Math, Physics, Logic sometimes even Biology background that had a strong affinity for functions and found OOP generally painful.
I think it's that functional programming is more of a niche with an even more disparity between demand/supply regarding the salaries.
Oh, and usually HR people have a pretty bad filter when it comes to functional engineers, so they only filter by keywords
To be clear, I was not calling bullshit - I experimented with UVEX blue-blocking glasses, and so a marked difference in "natural" sleep times. Similarly with early morning Vitamin D, and exercise, and I am not the only one.
However, I am not aware of any reasonably objective evaluation of these claims, so I don't consider them "truth" or "science" - they are anecdata, which might be interesting, but not science.
Atleast for me, using a red-tint filter on a phone or computer screen helps a lot with eye fatigue and afaik also with sleeping as I tend to be more tired when waking up after not using such a filter.
Additionally, I'm fairly certain that there have been numerous studies that found that the color of light heavily affects the circadian rythm, especially the blue component, not only in humans.
By proxy any blue-light filter should have similar effects. And by proxy of that a blue-light filtering pair of glasses should too.
If you're a recruiter, by the time you actually get to talk to a candidate, you're tired of screening and most of the time you do a half-assed call.
Plus it boggles my mind how very very few companies train the recruiters in understanding the technologies they have in their stack.
There are a lot of factors that add an incredible amount of friction and make it a very asymmetric process (as other have said above):
• plain human error • job specifications with boilerplate text not being clear on what the role actually does • often times the people doing the first screening don’t have a technical background • resumes come in all shapes and formats, so it’s difficult to efficiently read them
And because of that asymmetry and supply-demand ratio, it’s actually quite hard to hire software developers that are suited to a company, tech environment & business needs.
(disclaimer, I work at WorksHub)
The way we're trying to solve the issue at WorksHub is by trying to get companies to open-source same part of their code-base so that a developer could submit a few PRs during the interviewing process.
This solves the issue of irrelevant technical interviews, gives an idea of how your coding environment will be right off the bat.
Basically the thing is to do as much of the process as possible using only tech and then leave the last part for the actual human interaction.