I’m in the same boat. I’ve never directly applied to the 3 jobs (including a FAANG) that I’ve taken in Silicon Valley. One found me on angel list and the others LinkedIn or direct email. Similar to you, the places I did apply to would never respond, even with referrals in some cases.
It looks like someone from the company reached out in the comments section:
> I just saw your post this morning. I'd like to help resolve this as quickly as possible, if I can. I'm not exactly sure what happened in your case. This doesn't sounds fair or right, and isn't a TeamViewer business practice.
Not sure where it went from there though
edit: there’s a second page of comments where the issue appeared to be resolved but many others reported the same issue and were ignored
Oof! Does anyone recommend any tools for protecting against this sort of stuff? I feel like a VPN wouldn’t even be enough here since the MAC address is coming through the headers.
I think the full answer is to never trust anything on a page that isn't from the host domain: achievable via the uMatrix plugin. I dont understand why anyone would trust random scripts from a random company (and sometimes just an unnamed cloudfront endpoint).
A less intense version is to use a PiHole or otherwise block bad domains at the DNS level via a regular ad blocker.
> Today's JavaScript developer is acting like they have a 100 GHz CPU with terabytes of memory. And being lazy and uninspired as a result.
Not sure how I feel about a statement this broad. I work mostly with front end code and I try neat things and tricks to reduce resource use all the time. I also always push for the lightest way of doing things in PRs. I’m certain I’m not the only engineer who thinks like this.
I agree. I don't do frontend stuff, but I sit next to the team that does. They take a lot of pride in making fast-loading pages that render quickly and respond instantly. That's not compatible with writing giant, bloated, inefficient code.
>They take a lot of pride in making fast-loading pages that render quickly and respond instantly.
Maybe in your company. My experience browsing modern front-end SPA design however begs to differ. They pride themselves in loading megabytes of uncompressed images, layers of invisible background images, frameworks to load frameworks, auto-download/auto-playing 4k videos...
i agree with you but you have to keep in mind that pages which load fast on a fiber connection and render and respond quickly on the latest macbook don't guarantee the same for the average user.
giving devs 4 year old laptops would help but when shiny startup is offering new macbooks how can you compete?
Definitely can't generalize, but the average macbook pro sporting web dev often forgets what their users deal with. I had conversations at work where I pointed out the data we had on our users (and how they weren't even close to having that kind of hardware and internet connection), and no one would believe me until they saw the data themselves.
I went in for an interview recently for the react core team and the guy who interviewed me said Facebook was trying to edge away from open source. He mentioned it’s not worth it to them as much as it was before. Too much to maintain.
I manage the React Core team. That sounds wrong to me.
Facebook has not made any meaningful changes in its OSS strategy. It has always been the case that it takes energy to maintain projects in OSS and that for projects that are not used much by external folks it might not be worth the energy.
However, we are continuing to develop React with OSS as a first class citizen, doubling down on our investment in React Native in open source, and likely to still open source new projects as they make sense.
I think people on our team use VSCode, Sublime Text, and Vim. Almost all editors these days have good support for React, so we don't have any official one (nor do we feel the need to).
VSCode has particularly good integration with TypeScript, so perhaps choose it if you are otherwise undecided.
I’m not questioning typed JS, 100% behind that, we regrettably use flow, partly because React Native Typescript support wasn’t great (so I am told).
I guess I should have asked if FB recommended TS over flow nowadays
VSCode is also written in Typescript. I believe the teams work closely to ensure that new versions of TS are supported right away, and features are added to take advantage of them.
A shame, in an ideal world there would be the benefit of outside contributions that made less internal work needed, so overall would be a win for Facebook. But probably this is related to Atom itself being taken over by VSCode, the number of users (and maybe contributors) appears to be going down. I wonder if Atom Xray will ever come out https://github.com/atom/xray
That is only true if the outside contributes things that facebooks actually needs and if they are on a level of quality which facebooks wants. Often enough projects grow beyond the initial goal and at the end the maintainer is buried in meaningless work (for his own goals) and can't focus anymore on his own important things.
Good point. Although an OSS maintainer can be strict and refuse contribs on features they don't want to support. And by breaking down Nuclide, some individual packages like the Python debugger etc, probably can be very well defined and have a significant overlap between what they (Facebook) and other companies want, without much room for deviation. As opposed to say the general VCS support (they mostly want Mercurial that Facebook uses internally, whereas most outside users use git).
It still needs your requisite that contribs are of high quality.
Perfectly rational. Obviously they want to keep React closer to the chest as that directly impacts their core product. Things on the periphery are probably better left to others; I'd imagine it's more effective to donate dollars than hours for those kinds of projects.
I believe that their internal organisation has changed too. Product Infrastructure, who open sourced GraphQL, React, Relay, Flow, etc. was rolled into a core team, whose priorities are undoubtedly tied directly to internal a app metrics.
Good to hear that's still the case. I'm particularly worried about Flow, given that it's generally not trending well against TypeScript in terms of adoption, and because the team has never been super-engaged with the open source community. Would Facebook consider publicly clarifying intent to support less successful projects into the next 12 to 24 months?
I’m surprised to see an engineer admit this during an interview (assuming it is true, sophiebits has mentioned that it she doesn’t agree with this). Presumably this is the time when you talk about how much cool open source work you do?
An engineer at a big company is still just a dude or a gal. Not everyone in a multi-thousand person company will toe the company line or are in lock step.
Lying in the interview might bring them on but if they really want to do OSS and they don’t get that chance.. they’ll probably leave real soon, and then that’s wasted time onboarding someone.
Ooh! Actually, you can do this already with Slack by choosing "Direct message, mentions & keywords" under settings. Not exactly the same, but it helps.
I can understand the frustration with Slack but the comment about large companies using it doesn’t have much ground. I’m at a 3000+ employee company and slack works great for us. I think that one thing that has helped many people is to remember that you never have to reply immediately. Also, if you’re a stakeholder on something, then a final decision should not be made without your input. I’m sure that if you limit yourself to checking slack as much as you check your email, then it won’t be such an issue.
> ...remember that you never have to reply immediately.
Yeah, but you have to check immediately, unless you have immense willpower. And so the distraction is already made, the focus is lost, and the time spent switching contexts can't be recovered.
