urthen
Joined 14 years ago
Joined 14 years ago
Not only did the "real" team try and gaslight me into thinking my implementation didn't work (It did, they copied it wrong), but it took 3 engineers twice the time it took to copy my work into Java as it did for me to do the original development. The kicker: The Java process was so bloated it took nearly 2x the compute resources to get the same throughput.
TL;DR I challenge every time someone says "This is complex/high throughput, so let's use Java instead of Node"
I understand that they're investing in growth, but the key points still stands - money is flowing down the drain with the promise that it'll all be worth it "some day."
Other than basic filtering questions so I can see if someone is trying to fake their way through an interview, I never ask functional specifics. Even then it's usually just to make sure they at least basically know everything they claim to on their resume - if you don't claim to know JS, I'm not going to ask you about what bind() does, but if you rate yourself a 10/10 JS expert, you should probably have a good answer.
Interviews should be about your thought process and how well you can solve real world problems, not trivia about how well you've memorized an API. I don't understand why so many other interviewers (Even at companies I've worked for) ask coding "gotchas" and reject candidates because they don't remember the semantics of some obscure language feature.
(insert "it's your fault for trusting other companies with your wallet!" comment from the crypto kiddies here)
Keeping your crypto wallet in off-network storage and having to dig it out to spend money or whatever is the digital equivalent of keeping stacks of cash under your mattress. Does it work for some people? Sure. But don't pretend it's what the average person wants to do.
The other 900 hours were great though!
:D
And the worst part is, assuming it works and the epidemic curve is flattened out, people will still see this as "proof" that it wasn't necessary.
"You were instructed to keep the store open, but were unable to perform your job-required duties because you got arrested attempting to do so, therefore you are fired. Request to pay your legal fees is denied."
So, possibly faster than some estimates, but it's not exactly tomorrow. The headline heavily implies it's ready to go.
Also, super hilarious that instead of the headline saying "Canadian Company" it says "Pentagon-Funded Company" - USA! USA! USA!
This is in contrast to something like a hardware patent, where if you patent a tool, and I build a better tool that does the same thing, the mere fact it does the same thing is not infringing unless I copy specific aspects of your patented physical design.
The reform is that an ideal implementation of software patents is largely the same as an ideal implementation of software copyright. I can't just copy what you did, but if I figure out a different way to do it, that's perfectly fine. That's why so many people say scrap software patents altogether and work on improving software copyright instead.
This is just picking on an open-source team which already has shown themselves to take user feedback about privacy seriously. If you are so suspect of third parties that any device or application sending any network traffic without previous authorization is of serious concern to you, there's a lot more important and impactful products to voice concern about. Like pretty much any other part of Microsoft.
I've never had a problem with people that have extremely strict views of privacy. In fact I usually think they're right. But it's incredibly impractical, and most people don't currently care, which is the real problem. Treating relatively trivial things like this as if it were some conspiracy on behalf of the surveillance state doesn't do anything to get people to listen.
Get people to start dropping Facebook and Google, then we can start tackling the smaller offenses like this. Until then, treating this like you're going up against the NSA is a vanity exercise.
I've used both Java and Node professionally, and have in the past few years made recommendations for new projects to be started in both Java and Node depending on their unique requirements. I've even worked on projects migrating existing systems both from Java to Node, and Node to Java.
That said, I do strongly believe that Node is better suited as a language for web-scale projects that deal more with asynchronous requests (such as to DBs and APIs) than doing heavy data crunching themselves. If you need heavy data crunching, Java might be better for you, and there are a lot more available frameworks.
If you're looking for a job specific recommendation, it sounds like that might be partly regional. If you can't find Node jobs in your area, then maybe picking up Java is the right answer for you.