Also, there were some candidates who managed to get 95% and above — but would then just be absolutely awful during the interview — we would later discover that they were paying someone to complete the technical test on their behalf.
Yeah my company shot itself in the foot by replacing technical interviews with an online test and hiring a bunch of cheaters. After a while we started doing a zoom interview where we’d go over the code they supposedly wrote and ask them to explain it to us. Even that simple step made it obvious who had or hadn’t actually written the code they were talking about. I’m pretty sure a few candidates had somebody talking in one ear and/or typing to them on a separate screen.
Car manufacturers should get out of the dashboard design business. Just have an API standard for devices to control the car, and a USB port for users to plug in whichever device works best for them. You want a bunch of physical buttons? Cool, go down to AutoZone and buy a button panel that matches your needs. You want a big screen with carplay and a bunch of widgets? Mount your old iPad there.
The regulatory side would be the hard part. Devices would have to meet some safety standards and the car would have to refuse to drive unless an approved dashboard was connected, but it could be done.
Three days later, on November 20, the Seko union, which represents postal workers, will stop delivering letters, spare parts, and pallets to all of Tesla’s addresses in Sweden.
It seems troubling that there aren’t regulations in place requiring postal workers to deliver mail indiscriminately.
What if the postal union decided not to deliver mail-in ballots they thought might support a policy they disagreed with, for example?
I use a “real name” domain. My last name ends in the letters “in”, so I bought a .in
domain, such that the domain name is my last name with a dot in it.
Can’t honestly recommend that approach. It’s a cute gimmick, but when non-technical people ask for your email address and it doesn’t end in a TLD they recognize, their heads explode. I usually give out my gmail address.
Is it the employer’s responsibility to determine that somebody is or is not a spy? Like the scam here was to do the actual job and send money back, not to steal company information etc. companies have legal obligations to make sure people are authorized to work in the US etc, but the government sets those standards. If you’ve got convincing enough paperwork, it’s the governments job to enforce this stuff, not the employer.
That said, I’ve interviewed several remote people who were clearly using fake identities and also clearly didn’t have the skills for the job. Seems obvious their scam was to just collect a paycheck doing nothing, so if that’s the same group, then the employers bear some fault for hiring unqualified people… but on the other hand if the North Koreans were actually doing the jobs they were paid for, no reason the company should care.
How much does your SDK do? If it’s just wrapping calls to an HTTP API, use something like OpenAPI / Swagger to document the API, then auto-generate client libraries based on the OpenAPI specs.
Then if you add any language-specific niceties on top of the auto-generated code (i.e. accessor functions to set up user credentials etc) you have to write tests for those parts in that particular language. But the bulk of the API you can test in whichever language you prefer, then just assume the code generator is doing its job and creating a compatible API in the other languages.
My salary, I guess.
Everybody on my team is required to do on-call once they have enough experience (except for the low budget offshore contractors who I wouldn’t trust to do it anyhow…)
We have 2 people on call at a time, 1 primary and one backup. You do a week on backup, then the next week you’re primary.
There’s no set time limits etc, but if you get sucked into some fire, people are reasonable about letting you take some time off the next day or whatever.
All in all, there are very rarely fires that happen inside or outside of normal working hours. Making the whole team be on call helps incentivize everyone to write more stable code since it’s your own ass on the line.
The question is more about “how much” of PD they support right? Like PD has standards for charging at higher or lower currents.
My understanding of the current-gen MacBook Pro is that they support some kind of “fast charging”, but only if you use their MagSafe port. You can still charge on the USB-C ports, but not as fast as you could with MagSafe. I’m not sure if that’s a violation of the regulations, or if PD simply doesn’t have support for the amount of power they’re pushing through the MagSafe.
But I think the point is that they’ll continue to look for ways to offer a better experience with their proprietary stuff, even if they’re forced to support a standard in addition.
The real test on this one is going to be in how well those regulations support the eventual transition from USB-C to something else.
There’s inevitably going to be a use case for new connectors that have some yet-unidentified advantage over USB-C for certain devices, and there’s going to be hurdles convincing regulators to grant exceptions for those devices or to adopt one of them as the new standard for everybody.
There’s plenty of examples of government regulations gone wrong trying to transition from an old technology to a new one. (i.e. the REAL ID format in the US, or the switch from analog to digital broadcast TV).
Yup. Nothing wrong with pushing up a draft PR and asking for feedback; but definitely need to be an active participant in fixing the issues, not just expect somebody else to do your work for you.
That does lead to some sticky inter-personal situations though. Like there’s people on my team that I trust enough to just rubber-stamp a PR that looks good but doesn’t have test coverage etc. Can generally trust those people will let me know if the failing tests uncover some substantial work that needs to be re-reviewed.
There’s other people I don’t trust and will insist their build passes before I review it. Once that person notices they’re being held to a different standard, it can be difficult (but necessary) to have a conversation about what they need to change in order to earn that trust.
Your corporate IT guy
That’s a big departure from the spare tire analogy. The spare tire analogy is based on the principle that affirmative action should be a stepping stone that gets us to the place we want to be and then stops being needed. Whether we’ve gotten to that point or not isn’t a topic I want to get too weighed down on, but I think the point is that the goal is a world where we don’t need affirmative action.
But a wheelchair is (in general) a tool that compensates for a permanent problem. People who need wheelchairs need them forever. Are you arguing that’s what affirmative action is? Systemic racism can never be undone and affirmative action has to live on in perpetuity?
Not trying to get too bogged down in the analogy itself, but it seems you’ve got a fundamentally different view of the issue than the person you’re replying to.
It doesn’t matter what browser you’re using. Everything Google was tracking here is the stuff all browsers send in incognito mode. This lawsuit was totally frivolous