Hey, I'm a SWE at Google currently hosting an eng resident. I'd encourage staying through the residency in general, but I of course don't know your specific situation. (I'm also not sure which rotation you're on, but it's worth noting that even if one of your rotation teams doesn't have headcount the other might, and that even if neither does right now they might by the end of your residency.)
If you want, feel free to contact me internally and schedule a 1:1 so we can chat in more detail. My google username is the first 5 characters of my HN username.
If you want to make the meeting private, that's absolutely reasonable. I will not mention anything about it to your team or manager unless you ask me to.
Personally, I have a password that my password manager generated that I use for it. I had it written down in my wallet for a while, but after typing it multiple times a day for a while I memorized it and since destroyed the paper. It's a shorter password than what I use for my stored passwords, but I think it strikes a good balance. (And it's not a GUID, but if you think you could memorize that then it probably couldn't hurt. That's risky, though -- if you forget, there go all of your passwords for everything!)
I don't know of any off the top of my head, but there was that time a few years ago when Dropbox accidentally let anyone in without a password. This isn't to pick on Dropbox, but security lapses happen and it's wise to have multiple layers of strong defense to reduce your risk. (Also, if someone compromises the email associated with your CloudDrive, they can use that to get your CloudDrive by invoking a password reset.)
EDIT: Wolfram|Alpha estimates the entropy of a password generated using the constraints I used for mine as roughly 85 bits (the relevant space would take 14 trillion years to enumerate). It actually has a pretty information-heavy password strength estimator (though I can't attest to its reliability as I'm not familiar with the internals).
3 combined with 6 sounds like a recipe for disaster if someone manages to compromise your CloudDrive account (probably not by breaking the password, but by social engineering or a method similar to the one in this article). If they get that, they have your encrypted password database, and if that has a weak password... you're totally SOL. The password database's password is one you want to be /very/ strong.
If there's malware on your computer, it could just as easily keylog your password and one-time code the next time you try to log in to google, silently drop those packets on the floor (so you think there was just a connection issue), and then use your credentials to get access to your account.
If there's malware on your computer running as you, with access to things like USB devices, it becomes significantly harder (if not impossible) to do anything security critical on it.
Let A be a countable set. Now, suppose that there was a surjective function (one that hits every element of P(A)) f: A -> P(A). (Note that f takes elements of A, and produces subsets of A.)
Now, define Y ⊆ A as follows: For all x in A, x is in Y if and only if x is not in f(x).
Thus, Y, which is in P(A), is distinct from every output of f, and so f is not actually surjective.
This means that no surjective function f: A -> P(A) exists.
Cockpit view is generating an error: "The Google Maps API key used on this web site was registered for a different web site. The developer of this web site can generate a new key here.
The readme does in fact make that claim: "The Reverse State monad allows you to do the reverse: send information backwards to the past, or receive information from the future."
I'm curious as to what exactly that means, but without further explanation I'm going to assume that the thing running in the "past" just waits for information from the "future". It's possible they mean something else, of course, but that's my first guess.
That video assumes that nonprofit jobs aren't high-paying, but that's not always the case. KA, for instance, pays competitively. If you can both have a high-paying career that enables you to donate while also using your skills to help advance causes you care about (especially if the skills in question are skills that many or most people don't have), then by the reasoning in the video, that's better than either option they present.
This is assuming you don't count the algorithm design and analysis class as math, or any of the "logic and languages" (Intro PL, constructive logic, Automated program verification, basic logic, computability and incompleteness) as math.
I find it somewhat strange that generating functions are introduced significantly before recurrences are (and that recurrences are introduced last!). Does anyone know why the authors did that?
I think they addressed this in the edit they made:
>Correction: this post was edited on the 6 January to reflect the argument that if an n-clue grid is uniquely solvable then adding a digit to make an n+1-clue grid must also be uniquely solvable. So if there are no uniquely solvable 16-clue grids, there cannot be any grids with fewer clues that are uniquely solvable. Thanks to RealMurph and abooij.
If you want, feel free to contact me internally and schedule a 1:1 so we can chat in more detail. My google username is the first 5 characters of my HN username. If you want to make the meeting private, that's absolutely reasonable. I will not mention anything about it to your team or manager unless you ask me to.