hknd

A "patch" in Google/Facebook/Twitter is the same as a commit. It has a (mostly) descriptive commit message, references to bug tickets and might contain links to documentation, screenshots and mocks.

You basically work on a "patch" (changelist), get feedback from others and send it out to review at the end. Before you can submit (commit) it, you'll have to sync to "head" (to have the latest changes) and run all tests. ^ most of this happens automatically, and as most changelists ("patches") are small, this happens very fast and async in the background.

It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those.

A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool.

Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc.

If you have a question to a specific example I'm happy to answer it in the way it would've been done within Google/Facebook.

How does it make sense to compare the processes of a company with >100k people touching code and products with more than 1B qps, to a startup with <5 people touching code?

This comparison makes absolutely no sense.

I think we should not take "rewrite" too literally.

But both, search and adwords, have been rewritten multiple times since their launch.

You can have a look at the papers created by Jeff Dean (1) and Sanjay Ghemawat (2) which mention some of the new concepts/technologies/features used in those products.

1: https://ai.google/research/people/jeff 2: https://ai.google/research/people/SanjayGhemawat

You'll have to remember that all of those big companies have their tools and processes customized for their scale.

Example: Instead of branching you would just create a `changelist` (a commit, a set of changes to files) and work on that. You can show it to your colleagues. You can build and test it. You can send the id to anyone to have a look at it, or test it themselves. You can have multiple changelists depending on each other, without being commited.

This might be an interesting read for you: https://paulhammant.com/2014/01/08/googles-vs-facebooks-trun...

Depends on the size of the change. Small changes are preferred in most trunk-based-dev companies.

FYI: There are (multiple) tools in Facebook and Google which are an abstraction on top of their VCS. (e.g. which feels more like git, where you can work on a stream of changes which depend on each other without actually pushing anything to head)

So you can prepare a change for trunk, and share the change with your colleagues to collaborate on.

Don't see why branching should be needed for this.

You don't need branching for this.

If 2+ people are working on the same file which might result into a conflict, you can either: - handle the conflict as soon as you merge your branches somewhen in the future or - handle it when trying to commit your change to head

Only difference is whether you handle the conflict now, or in the future.

There is no real "loot box" system in Black Ops, and all stuff which can be bought is just for "cosmetics".

I enjoyed blind during their early days, now all threads are the same: "HEY, starting at company XYZ at level N, with total comp of YYYY. Is that good" "No, that's not possible you are lying!" "Hell yeah, well done mate" ...

Really like that I can setup to get live reports if one of my accounts appears in a breach.

The majority is actually using a browser based IDE.

"The majority of Google developers are using it now," Chris Capossela, Microsoft's chief marketing officer, said.

I doubt that.

test

The landing page doesn't show me anything about this product, and just forces me to login with 'blockstack'.

Guess I'll close the tab ¯\_(ツ)_/¯

Looks really interesting.

Are there any companies using this in prod already? Or any load experiment numbers? Proving that this actually is a "scalable real-time API"?

>1MB for such a simple website is an absolute dealbreaker :(

The article is literally 3 lines and says:

Search giant Google acquired the Duck.com domain name in 2010 with the acquisition of On2, a video codec company.

Damn - that VSCode theme and color scheme from the screenshot in the article looks really nice.

Does anyone know its name?

1: https://techcrunch.com/wp-content/uploads/2018/12/pasted-ima...

Really amazing how Monzo is informing it's customers who might be affected: https://monzo.com/blog/2018/11/30/marriott-data-breach/

^ this!

I've seen so many jquery libraries used on sites to get a quick fancy animation, but then it used something like: setTimeout(() => { element.height += 2; }, 50)

Which literally brings a 60+fps page to <5fps on a high-end machine.

I think it's too easy to judge without ever living in China. People should always look at both sides, and try to understand the whole situation.

Ofc people in China strive for a service which would be able to compete with their current search engine. And Google in China would probably be way better than the current one.

Of course it's kinda sad that Google would need to censor results, which kinda conflicts with their missions - but apparently it's the law in China, and every company there needs to follow the law.

Google is a business, and it would kinda be not rational to skip the business they could make in China.

Cool that you open-source a book - it looks like it contains a solid amount of information. Well done!

What I'm missing (couldn't find it on the first glance) is a topic about the performance implications of animations. Most devs don't consider which css properties trigger a layout->paint->composite re-render, which has massive influence on browser performance.

There are soooo many shitty animations/transitions in the web, just because people don't know that animations can slow down a whole site.

Imho people should read something like the web dev one pager on animation performance (1), which explains (more or less) how to build high-performance animations.

There is also this free udacity course (2) which explains everything a web developer needs to know. It's not hard nor magic, and you just have to hear it once to remember it for whenever it becomes necessary.

1: https://developers.google.com/web/fundamentals/design-and-ux... 2: https://eu.udacity.com/course/browser-rendering-optimization...

He is referring to https://github.com/dwyl/learn-to-send-email-via-google-scrip...

It would be quite easy to check the rsvp code in appscript. E.g. have a sheet with all the guests, and give a random number (rsvp code) to each guest. Then on each rsvp request you could check whether that rsvp code exists in the code column. If yes: you'll add the answer to that row. If no: return an error.

I also saw people having 10 interviews, and then get rejected :,(

8-15 years ago fb/google had 20+ interviews - and reduced the number based on research that after 4 they can predict it really good.

They mention 4 in the article, but that actually means 4 on-site. Before that a candidate usually has to pass a simple recruiter phone screen and a simple coding phone screen.

https://rework.withgoogle.com/blog/google-rule-of-four/

A negative example would be someone who scored good within the interview process, but then performs bad on the job (bad performance rating). Such examples get discussed internally by the hiring committee (senior people doing the last hiring decision for every candidate).

I think the biggest issue with the current approach among faang interviews is that a lot of really good people get filtered out (false negative) - but faang get so many applications that they are ok with this.

success criteria is the rating the people get during their performance review which happens twice a year.

Unfortunately it's internal. All faang companies spend a lot of time and resources on hiring to make it more fair for everybody and to get signals faster. And nobody internally enjoys doing a lot of coding interviews - it's as frustrating for the interviewer as it is for the candidate.

If there would be an easier way then these companies would definitely use it. A candidate usually has 5-7 interviews (if he is not failing the phone screen), which is 5-7 engineers spending at least 1 hour for the interview + 1 hour for the feedback. I am having 2-5 interviews per week, which means I spend between 4 and 10 hours per week just on hiring. If we could reduce this number we would definitely do it, as it's costing a loooot of money.

To be fair: there is some innovation and traction in those areas, s.t. some candidate s do a coding project at home and then present their solution (to reduce the number of interviews).

Apparently it's still the best indicator for hiring engineers on large scale. It's proven that there is a big correlation between performing good during an coding interview and performing good during your day-to-day job.

Ofc the coding interview is bad, but it's the best of all available (viable) options.

tbh: most people say it's bad because interviewers focus on the optimal solution or something like that. Most of the time that's incorrect as an interview is literally capturing: "Can the candidate solve a difficult problem and transfer his thoughts into code, while being a nice guy to work with"

disclaimer: I'm doing interviews for a faang company.

Google has ten-thousands of people working on tech support, see gTech: https://www.youtube.com/watch?v=HcjR6ZngQcw