
Google foobar - onion2k
https://www.google.com/foobar
======
onion2k
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.

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

~~~
tedmiston
Currently does not work in Safari on OS X either.

------
tedmiston
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.

------
derrikcurran
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 :-(

------
Daviey
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.

------
IanDrake
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.

~~~
eknkc
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?

~~~
onion2k
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.)

~~~
tedmiston
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.

~~~
onion2k
"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.

~~~
tedmiston
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...](https://developers.google.com/web/fundamentals/performance/critical-
rendering-path/analyzing-crp)

------
MatthewWilkes
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.

------
mikro2nd
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.

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

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

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

