Why do you think this is madness?
FB doesn't use git for these monorepos, so that's not really relevant, but I don't understand why you think that it's better to break a repo up because the SCM can't handle the size vs fixing the SCM so it can handle the size.
I work for meta (nothing to do with the teams working on this though) and I can assure you people have considered the tradeoffs of breaking repos up just to accommodate existing SCMs vs improving the SCMs.. I think if you believe improving the SCM instead of breaking up the code is madness you should probably provide a bit more of a justification
The questions are designed to allow an interviewer to get as much signal in the 45 minutes spent in the interview.. that's why they're contrived rather than your typical piece of work.
They're not designed to test you on something you would never encounter though.
If a company is asking these kinds of questions and the job only ever requires dealing with npm packages that shields the engineer from this complexity then they shouldn't be doing that in my opinion.
But most of the companies asking these questions are in the business of building software that requires this lower-level knowledge
I conduct interviews for Facebook and we do not discriminate on age. I assume the recruiter just got the impression you really didn’t want to interview with us.
I only do the coding interviews but every piece of interview feedback I write is focused on the same criteria and that definitely does not consider age. We don’t even refer to the gender of an applicant in the feedback, and comments on an applicants age would be a quick way for me to get dropped from the interviewer pool.
I said "You know I'm over 60, right?" in a friendly and informative way in case that could be an issue. The correct response would have been your comment, but instead was a quick exit and putting me on the no call list. You may not age discriminate, but that doesn't mean everyone one at Meta (Facebook at the time) does not.
I was aware of Mark Zuckerberg's comment which is why I brought up my age.
“I want to stress the importance of being young and technical,” he said. “Young people are just smarter. Why are most chess masters under 30? I don’t know. Young people just have simpler lives.” -- Mark Zuckerberg, Stanford University in 2007
Edit: I believe you when you say you don't age discriminate. That's because everyone is watching everyone else, including internal lawyers, to make sure you don't so as to avoid law suits. However, the person that called me was on a private phone call with me that wasn't being recorded, so they could get away with it.
This may be off topic, but I don't believe "most chess masters" are under 30, whatever MZ meant by that exactly. ("Chess master" is not a term used in chess.) Most top players seem to reach their highest rating between 35 and 45. Looking at ages of the current world top 100[0], about half seem to be over 30, half under. There are not so many players over 40 or 50 at the top these days though. A classical chess game often goes for 5,6,7 hours, and playing a tournament means doing that every day for a week or two. As most players reach 40 or 50, they start to fade after 5 or 6 hours play. It's stressful and tiring - a single mistake often can lose the game, and lose many hours work, sometimes lose weeks/months/years work.
Your coding interviews are THE filter that discriminates older people. They designed in leetcode-manner and that's clearly a sign that you want younger developers.
This is the correct explanation (thank you)
There’s no intention to hide the fact that certain links are blocked. The bug is that the status of failed message sends (not limited to blocked links) only shows an exclamation mark against the last message on web.
At the company I work for UI accessibility issues are automatic high priority bugs. You'll be an asset (as a frontend developer) to any company that values accessibility (and I'm certain that many do).
Contrary to your concerns, I think that being visually impaired and being a frontend developer will most likely open up opportunities rather than close them down.
In firefox it skips one letter at a time and maybe that is the intended behaviour, but it doesn't seem consistent with what I'd expect from a WYSIWYG editor.
I'd expect there to be 2 positions between the "e" and the "t" that the cursor would stop at so I can either insert text with the formatting of "one" or "two"
The "approach from the direction you want to take styling from" breaks down when you cannot approach from the other direction, or if there are >2 possible insertion points in the middle of a piece of text. I'm going to use Markdown to show the markup in HN, but pretend like it's rich HTML:
A string that ends in *bold!*
//
AB
Only position A is possible in Firefox's "approach from" algorithm; there is no way to tack on non-bold text to the end, short adding it and then re-/unformatting it.
You can then pretty quickly see what goes wrong here:
A string that have *_italic bold_ and bold!*
///
ABC
In Firefox, only positions A and C are possible; there is no way to start editing at B.
I think you could turn any of these into interesting box forms like one of the links in this thread that has two colored boxes, and you could have text somewhere (like between A & B in the second example here) and delete that text, and suddenly not be able to get a cursor back there, short of laying some text down and reformatting it.
Markdown, and other markup/syntax based inputs, make this trivially obvious, to a large degree. (Some ambiguities in the syntax can cause issues, but those seem to be rarer than issues w/ Slacks WYSIWYG editor.)
Don't Fuck with Paste, extension that disables anti-paste event handlers some banks use, triggers this when pasting into rich editors. Even Facebook and old Slack editor, IIRC.
There are lots of positive comments in this thread in support of this approach and I think it's great when anyone challenges the status quo.
It is more common these days than it was for websites to support multiple styles/layouts. Whether that's because they're responsive or because they allow you to enable dark mode or because they support rtl layouts. Class names such as text-dark-soft or align-right will be misleading if text-dark-soft ends up closer to white and align-right is left aligned as a website is evolved to support these features.
Not a criticism of this approach; this is easily fixed by using names such as text-emphasized-soft or align-start (for example), just pointing out the examples in this article could be lead to problems
CSS variables can also be used to encourage picking colors or padding/margin from a curated list. The approach in this article is not required to solve that problem
Distributing an altered binary to specific targets should be impossible as WhatsApp don't control the distribution, Apple and Google do. They would also have to be complicit too for a targeted attack to be feasible.
By having to distribute the same binary to everyone it is much harder to conceal a backdoor
Are you sure that there's no way for whatsapp to download and execute some code which will lead to upload of protected information?
Simple example: I'm sure that whatsapp main window is webview. Imagine that application inserts some kind of resource (e.g. CSS) from whatsapp server. So now whatsapp server can serve slightly altered CSS which will leak secret data via custom fonts, etc and you won't be able to find that, unless you're intercepting all traffic and can decrypt it (and apps nowadays love to pin certificates).
This is imaginary attack, I have no idea whether whatsapp does that. But HTML is a powerful and dangerous beast, yet it's used a lot in applications for rich media.
I think the interviewer may have been a bit standoffish because he/she was expecting you to work out how to reverse a linked list rather than memorizing the algorithm.
My CS degree only taught me what a linked list is, not how to reverse one.
It's not a great question to ask because it's such a common one and many people will have learned an algorithm from a text book, but if you haven't memorized the solution it's simple enough to understand the requirements yet difficult enough to work out that you can get a good amount of insight into how a job applicant can solve rather than memorize problems.
After all, being able to separate candidates who can solve unseen problems from those who can't is one of the goals of interviews
