Foobar is a recruitment tool (I think). The link won't work directly as it needs a working session id, but if you search for "headless chrome" you should get a working link in the page above the search results after a few seconds.

Thanks. I did the first challenge. Also it didn't work in Firefox Developer Edition.

Currently does not work in Safari on OS X either.

> if you search for "headless chrome" you should get a working link in the page above the search results after a few seconds.

Is the link still appearing? (I can't login to my google account now to check)

No dice :(

I remember getting an invite at some point late 2014 or early 2015 and doing a few problems but not submitting as I wasn't serious about interviewing. It's nice that you can see if your solutions passed without any requirement to submit your solutions to Google.

By the way — if you go too long without trying one, you get this:

    foobar:~/ tedmiston$ request
    Requesting challenge...
    Your invitation has expired. Search on to try again later.

Edit - Even Google engineers make errors:

    foobar:~/ tedmiston$ status
    Error(400): Bad request.

I submitted feedback on it. Seems like most commands fail with 400 if your invitation is expired.

This appeared while I was searching for something related to Angular a while back. It said something like, "You're speaking our language. Ready for a challenge?" Unfortunately, I was insanely busy at the time and lost the tab. It never came back and I had nothing in my email :-(

This has come up before... you need to get redirected to the site to be able to access it.. it gives you a pythonic shell in the browser to do a recruitment test.

These are very fun puzzles. I was sad when I lost access because I didn't push the recruit me button it kept offering me. Would have liked to do some more of them.

This is a test.

Good luck.

If you logged in after clicking the link on an unnamed app having unknown capabilities, and of unknown provenance, you have failed the test.

Is *.google.com really "of unknown provenance"?

no, but it is suspected of "having unknown capabilities".

who knows what google might do with google's information.

Time travel?

the login is *.withgoogle.com.

It's commonly known that withgoogle.com is a site Google uses for marketing and non-services sites.

Yes. Just because the app is hosted on a google domain tells us nothing about who developed it, what their intent might be, what data it might be gathering as/when you log in,...

It's basically a black box, and any suggestion that it ought to be trusted "because Google" is naive in the extreme.

I wonder what clearances you have to go through at Google to get your project into a toplevel directory or subdomain?

A first round google interview question I was asked: If you have a web page with two images on it, how many web request will need to be made to render the page? (Assume http 1.1)

I had to ask if he wanted the technically correct answer or the one I bet he (the google recruiter) was given by his engineers. Sadly his google engineers had given him the wrong answer.

I don't understand how these interviews work. You can't have a single correct answer to these kind of questions.

- 3 seems to be the obvious answer.

- 1 for keep alive stuff but even with a single connection, there are multiple requests. Also, nobody said the images were on the same server.

- Did I have these images on cache? Maybe 1 then.

- 4 with favicon request (now we are nitpicking)

- Hey maybe each resource is behind 5 http redirects.. So 15 would be correct I guess?

- Base64 encoded images are fun too.

They really have a "set in stone correct answer" and do not discuss these with people?

If the question states "to render the page" then it's very likely the answer is about blocking versus non-blocking calls. Images don't block the browser's renderer because they're loaded asynchronously, so the answer is 1. As soon as the browser has fetched the HTML and parsed the header for blocking scripts and CSS it'll build the DOM and render it. The images will be requested during that time, but they won't stop the rendering from happening. The browser will rerender the page as soon as the images load (or sooner if they're progressive JPEGs). The same is true of favicon.ico. That's loaded in the background after the first render.

(I think that's all still true. Browsers move fast.)

I'm not sure I understand your comment. Either way we still need the requests for the images to return (or fail) before we can call the page rendered.

"rendered" is a slightly tricky term when it comes to browsers. Often when people say "rendered" they mean "the page has loaded, all assets are there, and the whole thing has been drawn on the screen", but when someone from Google says "rendered", especially in a job interview, they probably mean the time to the first paint. That happens after all the blocking assets (synchronously loaded javascript, CSS, etc) have loaded but long before all the other assets (images, async JS, etc) have loaded.

That's fair, but agree it is ambiguous the way it's asked.

This front-end doc [1] from Google with a similar example counts a sample page with (1) html, (2) one external css file, and (3) one external image as "a minimum of 2 roundtrips":

> As a result, this page incurs a minimum of two roundtrips before it can be displayed. Once again, the CSS file may take multiple roundtrips, hence the emphasis on "minimum".

> Notice that our "awesome photo" did not block the domContentLoaded event. Turns out, we can construct the render tree and even paint the page without waiting for each asset on the page: not all resources are critical to deliver the fast first paint. In fact, when we talk about the critical rendering path we are typically talking about the HTML markup, CSS, and JavaScript. Images do not block the initial render of the page—although we should also try to get the images painted as soon as possible.

[1]: Analyzing Critical Rendering Path Performance https://developers.google.com/web/fundamentals/performance/c...

Could also embed the images into the CSS itself (or embed them in JS) and thereby get it down to 1 no matter what. There's so much ambiguity in the question. For instance, what constitutes a request? Are we talking just HTTP requests, or should we count things like DNS lookups. There's also unknowns in play that others have mentioned like caching and redirects.

This is being excessive but... the images could be no requests if they are embedded on the page as Data URIs [1], or if they are SVGs.

I wonder if there is a single "correct" answer.

[1] http://caniuse.com/#feat=datauri

Maybe they are evaluating how do you answer instead of what do you answer. If your answer includes a total underestimation of the recruiter's knowledge, maybe that's an attitude that google is not looking for.

A previous discussion on HN indicated that at least on some levels they are just checking if the answers match those one that have been provided by somebody: https://news.ycombinator.com/item?id=12701272

You can do one request if you embed the picture into the html document: https://en.wikipedia.org/wiki/Data_URI_scheme

Don't really understand why either 1 or 3 would be incorrect answers. But then again... I don't work at Google.

So, which were yours and their answers? I'd say usually 3, but you could do 1.

So 1 would be referring to the underlying connection which would be kept alive? Or is the interpretation that the page has "rendered" even before the images has loaded

1 would be with inline images (either in CSS or directly with data URLs), 2 would be 1 HTML and one image sprite, 3 would be just 2 image tags in 1 HTML page.

You can always inline your images.

I'll bite. Why is "3" the wrong answer?

Because a complete rendering of the page includes fetching /favicon.ico.

If there even is a favicon... and if a .ico file is considered an "image".

If there is no favicon... There'll still be a request, it'll just 404.

Every modern browser I know of automatically tries to fetch favicon.ico.

Good point. I suppose it's presumably async with respect to the render anyway. It looks even more nuanced on pages that have an iframe [1] (though presumably that's not the case here).

[1]: http://stackoverflow.com/a/13416784/149428

On the other hand you only need 2 if you use css image sprites.

Wouldn't this entirely depend on the web browser behavior?

If I'm using lynx, its 1... 1 request.

Am I allowed to Base64 encode the image into the HTML document?