Google has interns in cities all over the world this summer. Take a look at this list of 11 cities with Google interns to give you a taste of how each of these locations contributes to Google’s multifaceted and unique culture.

11. Sydney, AU

Our Sydney office, the greenest building in Sydney, sits on the waterfront in Pyrmont with views of the Sydney Harbour Bridge, The Rocks, and Darling Harbour. Inside, you’ll find a "living wall" made of plants, a tire swing, a library with a nap pod, and some amazing coffee machines. When interns really need a break, they check out a kayak or one of our electric cars (Mitsubishi I-MiEVs).


10. Dublin, IE

This Google office embraces Dublin’s unique Irish culture with graffiti murals and classic scenes from Irish folklore covering the walls. Interns often like to get a game of Blackball at the billiards table when they need a break. And, of course, Google Dublin couldn’t go without a conference room named “James Joyce.”


9. Los Angeles, CA, USA

Googlers play a large part in the growing technology industry in LA. When interns aren’t working together improving YouTube’s or Google’s search experiences, they might watch a movie at the office’s outdoor movie theatre or spend time at the beach a mere two blocks away from the office.


8. Waterloo, Canada

Located in the historic Lang Tannery Building, Google Waterloo is best known for being the birthplace of Gmail for Mobile and, of course, the site for Canada’s only officially recognized in-office slide. Waterloo is one of Google’s largest offices for fall and winter tech interns.


7. Seattle/Kirkland, WA, USA

With offices on either side of Lake Washington, this Google location encompasses both the urban and the suburban in the Pacific Northwest. With much of Google’s infrastructure developed under our belt here, interns have the opportunity to work on essential products like Google+ Hangouts and Chrome.


6. Pittsburgh, PA, USA

Google Pittsburgh, the former Nabisco Factory, holds over 400 Googlers—not to mention a giant hammock nicknamed “the trapeze net.” The office is located in Bakery Square, just minutes from Carnegie Mellon University and the University of Pittsburgh. Interns in the Pittsburgh office get the opportunity to work on site reliability and products like Mobile and Google Shopping.


5. Paris, FR

Located in a renovated hôtel, our Google Paris office has distinctly Parisian touches. Interns snack on wine and cheese for TGIF meetings, take meetings in a Citroën Deux Chevaux-turned-phone booth, and eat at a cafeteria nicknamed Les Deux Algos (short for algorithms). C’est la vie chez Google! (That’s life at Google!)


4. Singapore

Like the country itself, the Google Singapore office is home to both locals and foreigners. We give a distinct twist to the ways we have fun-lah, from Chinese New Year parties to Hari Raya Puasa, Indian holidays and weekly celebrations themed after countries where we do business. Interns enjoy the newly decked-out micro-kitchens, modeled after traditional street food stalls. Our Singapore office brings together a diverse community of Googlers – fitting, in a country with four official languages (English, Chinese, Malay and Tamil).


3. Zurich, CH

Self-proclaimed as “the real Mountain View.” Not because they are the company’s engineering headquarters for Europe, the Middle East and Africa (EMEA), but because of the views out of the top-floor Sky Lounge’s windows. The Alps may look impressive in Google Earth, but in person, they’re nothing less than spectacular. The Zurich office also hosts Google’s annual EMEA Intern summit, where Google interns from across Europe get an opportunity to meet each other and learn more about what their colleagues are working on at other offices.


2. New York, NY

If you can make it here, you can make it anywhere. We take that to heart at Google New York—constantly reinventing ourselves to strive for the best. With thousands of Googlers working in an office that takes up an entire New York city block, the energy here is undeniable. Interns in New York enjoy five incredible cafes, scooters, and a ladder for when they can’t wait for the elevator.


1. Mountain View, CA

Where it all began. Though the company has grown from Larry and Sergey working out of a garage to the Mountain View campus known as the Googleplex, the mission is still the same: to organize the world’s information and make it universally accessible. Interns enjoy numerous perks, but to name a few: beach volleyball, bowling alleys, 25 cafeterias, and weekly TGIF gatherings where Googlers are encouraged to ask senior management anything and everything. Changing the world one user at a time truly begins here.



Posted by Maggie Hohlfeld and Sean Sweeney, University and Tech Intern Programs Teams

Cross-posted from the Google Testing Blog.
This is the third in a series of articles about our work environment. See the first and second.

I will never forget the awe I felt when running my first load test on my first project at Google. At previous companies I’ve worked, running a substantial load test took quite a bit of resource planning and preparation. At Google, I wrote less than 100 lines of code and was simulating tens of thousands of users after just minutes of prep work. The ease with which I was able to accomplish this is due to the impressive coding, building, and testing tools available at Google. In this article, I will discuss these tools and how they affect our test and development process.

Coding and building

The tools and process for coding and building make it very easy to change production and test code. Even though we are a large company, we have managed to remain nimble. In a matter of minutes or hours, you can edit, test, review, and submit code to head. We have achieved this without sacrificing code quality by heavily investing in tools, testing, and infrastructure, and by prioritizing code reviews.

Most production and test code is in a single, company-wide source control repository (open source projects like Chromium and Android have their own). There is a great deal of code sharing in the codebase, and this provides an incredible suite of code to build on. Most code is also in a single branch, so the majority of development is done at head. All code is also navigable, searchable, and editable from the browser. You’ll find code in numerous languages, but Java, C++, Python, Go, and JavaScript are the most common.

Have a strong preference for editor? Engineers are free to choose from many IDEs and editors. The most common are Eclipse, Emacs, Vim, and IntelliJ, but many others are used as well. Engineers that are passionate about their prefered editors have built up and shared some truly impressive editor plugins/tooling over the years.

Code reviews for all submissions are enforced via source control tooling. This also applies to test code, as our test code is held to the same standards as production code. The reviews are done via web-based code review tools that even include automatically generated test results. The process is very streamlined and efficient. Engineers can change and submit code in any part of the repository, but it must get reviewed by owners of the code being changed. This is great, because you can easily change code that your team depends on, rather than merely request a change to code you do not own.

The Google build system is used for building most code, and it is designed to work across many languages and platforms. It is remarkably simple to define and build targets. You won’t be needing that old Makefile book.

Running jobs and tests

We have some pretty amazing machine and job management tools at Google. There is a generally available pool of machines in many data centers around the globe. The job management service makes it very easy to start jobs on arbitrary machines in any of these data centers. Failing machines are automatically removed from the pool, so tests rarely fail due to machine issues. With a little effort, you can also set up monitoring and pager alerting for your important jobs.

From any machine you can spin up a massive number of tests and run them in parallel across many machines in the pool, via a single command. Each of these tests are run in a standard, isolated environment, so we rarely run into the “it works on my machine!” issue.

Before code is submitted, presubmit tests can be run that will find all tests that depend transitively on the change and run them. You can also define presubmit rules that run checks on a code change and verify that tests were run before allowing submission.

Once you’ve submitted test code, the build and test system automatically registers the test, and starts building/testing continuously. If the test starts failing, your team will get notification emails. You can also visit a test dashboard for your team and get details about test runs and test data. Monitoring the build/test status is made even easier with our build orbs designed and built by Googlers. These small devices will glow red if the build starts failing. Many teams have had fun customizing these orbs to various shapes, including a statue of liberty with a glowing torch.

Statue of LORBerty

Running larger integration and end-to-end tests takes a little more work, but we have some excellent tools to help with these tests as well: Integration test runners, hermetic environment creation, virtual machine service, web test frameworks, etc.

The impact

So how do these tools actually affect our productivity? For starters, the code is easy to find, edit, review, and submit. Engineers are free to choose tools that make them most productive. Before and after submission, running small tests is trivial, and running large tests is relatively easy. Since tests are easy to create and run, it’s fairly simple to maintain a green build, which most teams do most of the time. This allows us to spend more time on real problems and less on the things that shouldn’t even be problems. It allows us to focus on creating rigorous tests. It dramatically accelerates the development process that can prototype Gmail in a day and code/test/release service features on a daily schedule. And, of course, it lets us focus on the fun stuff.

Thoughts?

We are interested to hear your thoughts on this topic. Google has the resources to build tools like this, but would small or medium size companies benefit from a similar investment in its infrastructure? Did Google create the infrastructure or did the infrastructure create Google?

Posted by Anthony Vallone

Cross-posted from the Google Testing Blog.
This is the second in a series of articles about our work environment. See the first.

There are few things as frustrating as getting hampered in your work by a bug in a product you depend on. What if it’s a product developed by your company? Do you report/fix the issue or just work around it and hope it’ll go away soon? In this article, I’ll cover how and why Google dogfoods its own products.

Dogfooding

Google makes heavy use of its own products. We have a large ecosystem of development/office tools and use them for nearly everything we do. Because we use them on a daily basis, we can dogfood releases company-wide before launching to the public. These dogfood versions often have features unavailable to the public but may be less stable. Instability is exactly what you want in your tools, right? Or, would you rather that frustration be passed on to your company’s customers? Of course not!

Dogfooding is an important part of our test process. Test teams do their best to find problems before dogfooding, but we all know that testing is never perfect. We often get dogfood bug reports for edge and corner cases not initially covered by testing. We also get many comments about overall product quality and usability. This internal feedback has, on many occasions, changed product design.

Not surprisingly, test-focused engineers often have a lot to say during the dogfood phase. I don’t think there is a single public-facing product that I have not reported bugs on. I really appreciate the fact that I can provide feedback on so many products before release.

Interested in helping to test Google products? Many of our products have feedback links built-in. Some also have Beta releases available. For example, you can start using Chrome Beta and help us file bugs.

Office software

From system design documents, to test plans, to discussions about beer brewing techniques, our products are used internally. A company’s choice of office tools can have a big impact on productivity, and it is fortunate for Google that we have such a comprehensive suite. The tools have a consistently simple UI (no manual required), perform very well, encourage collaboration, and auto-save in the cloud. Now that I am used to these tools, I would certainly have a hard time going back to the tools of previous companies I have worked. I’m sure I would forget to click the save buttons for years to come.

Examples of frequently used tools by engineers:

• Google Drive Apps (Docs, Sheets, Slides, etc.) are used for design documents, test plans, project data, data analysis, presentations, and more.
• Gmail and Hangouts are used for email and chat.
• Google Calendar is used to schedule all meetings, reserve conference rooms, and setup video conferencing using Hangouts.
• Google Maps is used to map office floors.
• Google Groups are used for email lists.
• Google Sites are used to host team pages, engineering docs, and more.
• Google App Engine hosts many corporate, development, and test apps.
• Chrome is our primary browser on all platforms.
• Google+ is used for organizing internal communities on topics such as food or C++, and for socializing.

Thoughts?

We are interested to hear your thoughts on this topic. Do you dogfood your company’s products? Do your office tools help or hinder your productivity? What office software and tools do you find invaluable for your job? Could you use Google Docs/Sheets for large test plans?

Posted by Anthony Vallone

Re-shared from the Google Testing Blog.

When conducting interviews, I often get questions about our workspace and engineering environment. What IDEs do you use? What programming languages are most common? What kind of tools do you have for testing? What does the workspace look like?

Google is a company that is constantly pushing to improve itself. Just like software development itself, most environment improvements happen via a bottom-up approach. All engineers are responsible for fine-tuning, experimenting with, and improving our process, with a goal of eliminating barriers to creating products that amaze.

Office space and engineering equipment can have a considerable impact on productivity. I’ll focus on these areas of our work environment in this first article of a series on the topic.

Office layout

Google is a highly collaborative workplace, so the open floor plan suits our engineering process. Project teams composed of Software Engineers (SWEs), Software Engineers in Test (SETs), and Test Engineers (TEs) all sit near each other or in large rooms together. The test-focused engineers are involved in every step of the development process, so it’s critical for them to sit with the product developers. This keeps the lines of communication open.

Google Munich

The office space is far from rigid, and teams often rearrange desks to suit their preferences. The facilities team recently finished renovating a new floor in the New York City office, and after a day of engineering debates on optimal arrangements and white board diagrams, the floor was completely transformed.

Besides the main office areas, there are lounge areas to which Googlers go for a change of scenery or a little peace and quiet. If you are trying to avoid becoming a casualty of The Great Foam Dart War, lounges are a great place to hide.

Google Dublin

Working with remote teams

Google’s worldwide headquarters is in Mountain View, CA, but it’s a very global company, and our project teams are often distributed across multiple sites. To help keep teams well connected, most of our conference rooms have video conferencing equipment. We make frequent use of this equipment for team meetings, presentations, and quick chats.

Google Boston

What’s at your desk?

All engineers get high-end machines and have easy access to data center machines for running large tasks. A new member on my team recently mentioned that his Google machine has 16 times the memory of the machine at his previous company.

Most Google code runs on Linux, so the majority of development is done on Linux workstations. However, those that work on client code for Windows, OS X, or mobile, develop on relevant OSes. For displays, each engineer has a choice of either two 24 inch monitors or one 30 inch monitor. We also get our choice of laptop, picking from various models of Chromebook, MacBook, or Linux. These come in handy when going to meetings, lounges, or working remotely.

Google Zurich

Thoughts?

We are interested to hear your thoughts on this topic. Do you prefer an open-office layout, cubicles, or private offices? Should test teams be embedded with development teams, or should they operate separately? Do the benefits of offering engineers high-end equipment outweigh the costs?

Posted by Anthony Vallone