Linux Mint Sarah on MacBook Pro


So, I have this 15-inch MacBook Pro with Retina Display early 2013 lying around and am contemplating buying the 2016 one. But, to be honest, I’m not so sure that I will be getting the best bang for my buck.

As such, I am looking to see if moving away from the macOS ecosystem is even possible for me, a person that has been with a version of Mac OS X for years now.

I had a lot of experience with Ubuntu and Fedora before, so, now I wanted to try something different.

I have already tried elementaryOS, and while their effort in prioritizing design and user experience is admirable, it just isn’t the best development OS on the market right now. I might right a follow up post on my experience with the OS later, but for now, I have moved on to Mint, the second one in line that caught my attention.

First Impressions

The first impression I got from the installer was amazing. It supported a hefty 1680×1050 Retina resolution out-of-the-box. My only gripe was with the WiFi driver not working right away.

I could remedy that by going to the “Driver Manager” setting in the System Settings app and enabling the proprietary driver for the WiFi.

While I was at it, I changed the graphics card’s driver to NVIDIA, and the processor microcode firmware to “intel-microcode”.

I guess I could have just waited for the installer to do that for me, but since I wanted to get a sense of the environment without installing first, these were a must for me.

After Installing

So, it turns out that enabling the drivers had nothing to do with the post-install state of the machine. I had to reenable them all. To make matters worse, for some reason, the fully installed version didn’t let me enable the WiFi driver without an Internet connection. Thankfully, getting a connection to the Internet from my my dongle-less MacBook was relatively easy, as I just had to plug in my iPhone to use it as a cellular modem — which to Mint’s credit, was recognized and used right away.

Everything was going smoothly. I installed git, Java, and then proceeded to install IntelliJ IDEA. It was remarkably good, with great performance.

If anything, the resolution of the screen was too much for me. I scaled it down a single level (to what I normally used with OS X) and … it all went bad. The graphics turned to pre-2000 quality with all the pixels visible, and the colors not that great.

This was more than a surprise, as the 1440×900 relation is exactly what I used with the OS X installed on the MacBook Pro. So, I was astounded that the quality got so poor by reverting to a lower resolution.

I looked at the drivers, and there it goes. The driver was not NVIDIA’s original, proprietary driver, and was an open source version from instead. I switched to NVIDIA , it downloaded a number of packages, and it was a blast.

I installed everything I wanted (Dropbox, Wine, etc.). It was working great. Then, I shut it down and put it in my backpack for work.

The next day, I went to work, happy to have found a neat replacement for my macOS Sierra, by the name of Sarah. In it was all free, too. Yay!

Then, I started my computer, and was confronted by a purplish-black screen, instead of the Mint boot page. I went to recovery mode. No luck.

I had to go back to the very beginning and start reinstalling everything, barring the graphics driver. It was working, and all was good. I lived with this system for three days. But somehow, it felt really ugly. Then, I realized that I absolutely loved the graphics of my macOS system, and that my subconscious was protesting at its loudest, and thus ended my adventures in the Mint-land.

I tried Ubuntu, and to my surprise, it had the very same issues with NVIDIA, and wasn’t as great an experience as Mint was.

I reinstalled macOS.

Using Spring in the Modern World

Many of us have integrated our application with the wonderful Spring Framework over the years. This may have happened to you in the form of migrating an existing application to Spring, replacing an IoC container, or even starting a new application with Spring incorporated. The steps involved in each of these different scenarios, while wildly different, share the same common trait: figuring out the exact layout of your application, abstracting the contracts, and relying on the dependency injection container to glue the pieces back together.

During the course of this rethinking process our application shrinks, in terms of the lines of code, since at least instantiation and dependency injection have now been delegated to an automated process that does not require any coding beyond some declarations. Using Spring has become so natural to some of us that we do not even think about it, anymore.

As a software engineer, that is my red alert. Whenever you start reusing a technology without reassessing it, you should second guess yourself. Does the value it brought to table two years ago still stand? Are you still using it right? Do you need a refresher to keep up with the changes the technology (and its periphery) has undergone?

Since its beginnings, Spring has been an ever-evolving framework; it has always tried to adhere to the latest paradigms and shift with the changes, while not losing its essence. One of the many changes Spring has incorporated has been the ever-so-controversial move from XML-driven configuration to annotation-driven configuration. We are now empowered with the tools provided to us by the platform itself, wherever possible, so as to avoid long startup times tied with XML file parsing and processing. I do have to mention that it is not technically a move from XML config to annotation config, since you can still write XML configuration files and import them in your project. Or even ignore the Java config capabilities altogether. This has become increasingly difficult, though, as the Spring team is now heavily advocating the newer, better supported Java configuration, specially since the advent of Spring Boot. I do not blame them. I, myself, am a fan of doing annotation configuration. I guess you could say that I have never been much of an XML person.

The problem, however, is that many of us have forgotten why Spring came with an XML configuration file in the first place: to separate the framework from the main project. It was so that we could technically go in another direction if we needed, by changing peripheral code, rather than doing code changes in the main project. Spring configuration was exactly that: a configuration file that left no footprint in our application, except the fact that we now designed with IoC in mind.

In this article, I want to examine the problem of migrating from an older Spring-based application to an annotation-configuration Spring application.  Since my discussion here involves practical uses of the framework, I would like to present a couple of sample cases before moving forward. I will then proceed to present the steps involved in making the transition and, finally, conclude by giving a clear recipe for the migration.

Sample: Bean Configuration

One important asset when using XML application configurations is that it helps you understand what happens to a bean during its lifecycle, from its instantiation to the various configurations it undergoes.

Suppose that we want to configure a bean after all of its dependencies have been set. One way to do this is to implement the InitializingBean  interface provided by Spring.

Consider the following scenario:

Do you see the Spring code creeping in your application code? Spring provided the much better alternative in its XML API:

Now you could say that your application was not dependent on Spring, and you would be right: you have zero dependency on Spring to initialize your bean, and your only assumption is that somebody will call that init method sometime after the bean’s properties have been set.

In the post-annotation world, this would be how we write it:

As you can see, we have moved the declaration from the configuration file over to our application class in the form of the @PostConstruct  annotation.

This is bad for multiple reasons:

  1. You have brought configuration to your code, meaning that now there is no source of truth. Not only that, you cannot even know where to begin looking.
  2. You have hard-coded the configuration in your application. This can never be changed externally, as opposed to the XML configuration file which let you reconfigure your application from the configuration file rather than modifying your code.
  3. The workings of your application is now very obscure. You might have tons of beans interacting with each other. You would not be able to see the lifecycle of your beans.

The same, of course, could be said about multiple other annotations, such as @Autowired .

Sample: Bean Instantiation

Another important aspect of the application context configuration XML files is that it let’s you configure how the beans are instantiated. You could look at the configuration and glean valuable insight about the relationship between the beans, as well as which beans were being instantiated and when.

Consider the following:

Do you see that @Component ? That is basically declaring that this bean is now a part of an application context (or two) if such an application context exists and if the component scan is properly defined. Compare the code above with the following:

Can you see how this is not hard-coded into the application, and how you can now visibly understand the scope, availability, and configuration of your beans?


As I said earlier, I am not a particular fan of the XML configuration files. Not for Spring and not for any other framework or tool. For someone not liking it, though, this article seems to be doing a lot of advocating it. That is because we have forgotten that Spring annotation configuration is also a separate configuration for your application which just happens to share the same language as our existing (or new) code base. You have to do your annotation configuration the very same way you were doing your XML configuration files — in a separate, neatly organized place outside of your main code. This has always been the spirit of the Spring framework: Inversion of Control. Manually annotating your properties using annotations is not conceptually any different to manually getting the bean from the context, or manually instantiating it. The only difference is that it is now done with a lot less coding.

It is important to understand that the annotation API shipped with Spring core comes in two different flavors:

  1. Those that pertain to bean configuration and instantiation via component scan and explicit declaration
  2. Those that serve to replace the XML configuration with a centralized configuration class file

It is the first category that must be avoided, since the proper usage of these requires much more extra work than is worth it, in my opinion (which would be first writing code devoid of any Spring annotation, then extending all required classes and, finally, annotating them with Spring annotations in a separate module and then incorporating them into the proper application context configurations). They were designed to help with migrating from XML files to the newer paradigm with writing a few lines of code that did the magic.

Now, your application is all shiny and works with annotations and you have actually gotten rid of all those XML configuration files. It’s time to take the next step, and clean up your code.

We will now consider such a change step by step.

The Legacy

Before annotations, we used to write XML configuration files and avoid Spring footprint in our application (in an ideal world, anyway). Suppose that our application has one module, main, and that we have the following XML file under main-module/src/main/resources/config.xml:

Where the two classes involved are the following:

We are told that we need to migrate to annotation configuration. This could be for many different reasons, but in my opinion, the main reason for doing that would be because our XML configuration files have turned into monolithic beasts that are now hard to maintain and test and we need to be able to break them into smaller, more granular configurations that are easier to read and understand.

We now need to take the next step.

The Transition

During the transition, we first heavily leverage the component scan facilities provided by Spring. Our XML file now looks like this:

And we need to modify the two original classes:

The first step we took was to transfer all instantiations from the XML configuration file to the actual beans themselves, and then replace setter injection by auto-wiring. This will allow us to empty the XML files while having our applications and beans continue to work the same way as before.

In this step, auto-wiring is a necessity, since we want to migrate from XML to annotation configuration with a minimum number of steps.

For many of us, this is where we stop. And this is where we need to ask ourselves what we have lost. We have lost generality. Our application can now no longer function without Spring. We cannot even see the full composition of our application without the aid of some external tool that lets us view the beans in our context or the dependencies between these beans. Instead of a convenience tool helping us implement the IoC paradigm, it has now become a hard dependency, without which our code will not even compile. That is where we need to step in and clean up the code.

The Cleanup

Spring provides us with the capability to do the same thing without leaving any footprint. We only need to think in parallel with how we did things back during the XML days.

Consider the following configuration class:

We now can happily revert our two classes to the state they were before the transition, and everything will continue to work.

This will also present us with the opportunity to collect bean instantiation configurations in smaller configuration classes. If we had one XML file to begin with, it does not necessarily mean that we should have one configuration class for our beans.

Consider the following project packages:

  • com.domain.project.component.model
  • com.domain.project.component.dataaccess
  • com.domain.project.component.dataaccess.dao
  • com.domain.project.component.dataaccess.connector
  • com.domain.project.component.web

It would make much more sense to create separate configuration classes for each of these packages and configure the beans under those packages separately in each configuration class. Then, we would consolidate all of these under a single, main configuration class that glues the application’s parts together, and bootstraps it for startup.

This main configuration class is really the only place I ever use component scan: to find @Configuration  files that would be otherwise very easy to locate in the same application under each package. My rule of thumb is that if I have to use multiple base packages, there is something wrong. It usually means that the configuration classes are not distributed evenly across the application, which means that to find them, I would have to enlist the help of some automated tool. Bad smell. If you — or the next poor developer trying to read and understand your code — cannot find all the configuration classes following a singular, uniform pattern, your code has just become unmaintainable.

One other important byproduct of writing configuration classes on a per-package basis is that you will now be able to identify any possible cyclic dependencies between your packages. Also, you will be able to see if the right level of encapsulation is in place. In the example above, having some bean from the ~.web  package reference a bean from ~.dataaccess.connector  package is a bad smell and must be investigated.

I also explicitly disable any other annotation being picked up by using the @ComponentScan(useDefaultFilters = false, includeFilters = @Filter(Configuration.class))  component configuration on my main configuration class, which basically says we do not want any of the Spring stereotypes to be picked up except for @Configuration .

Constructor Injection

On a separate note, now that our dependencies are so visible, we can make them even more verbose and make them constructor dependencies. Besides increasing visibility, this will improve lifecycle management: there is no single state in the lifecycle of the bean wherein dependencies are not available. Also, if you are afraid of your constructor requiring too many arguments, then you should really revisit your code. Maybe that is because your class is just doing too many things. Or maybe your dependencies are not being managed well enough.

There can be multiple reasons why you cannot convert a setter injection to a constructor injection:

  1. You have already released your API and cannot change the constructor or the way dependencies are injected.
  2. You are writing code in a legacy system which does not allow you to explicitly define such dependencies and therefore you need autowiring to have your system work.
  3. Your application lifecycle does not allow for the dependency beans to be handed to your dependent beans at construction time.

In the first case, you are pretty much stuck. You cannot change a code that is already released, and that is that. In the second case, you can always write wrappers, proxies, and façades that hide the legacy code and instead allow you to better manage the new code. This is actually what you should really do all the time: isolate legacy code into a manageable corner, and interact with it through a well-maintained interface. In the third case, though, you should really revisit your codebase. Such a case usually indicates a serious case of cyclic dependency in your application, and sooner or later, this will come back to bite you. Maybe not in the form of screwing up your main code, but at least in your tests. This is actually where writing really granular tests and creating configurations for small subsets of your system works to your advantage. You get to spot these eyesores early on.

The Final Step

The final step now is to remove the hard dependency to Spring. Remember how we had a single module with a separate XML configuration file when we started? We had the ability to create a separate module, say, main-spring which had a dependency to our original module, plus Spring. We lost this ability during the transition phase, and tried to rectify it during the cleanup phase. The final step, then, is to introduce the main-spring module and move every Spring related piece of code there. It is important to remember that our application’s components should function without Spring. Also, we should be able to start and run our application by manually doing what Spring would do if we wanted to, even though that might prove cumbersome.

After this final step your application must comply with the following:

  1. There should not be any XML configuration files left.
  2. Your main module must have no dependencies to Spring, either direct or transitive.
  3. Your Spring configuration module must have only dependencies to Spring and your main module.

I would also go so far as say that for each of your components, if you have a separate module, you should have a separate Spring configuration module. Constructor dependencies are not a must, but it is a good practice to fall into.

A Recipe for Migration

If you have not yet made the move to annotation configuration from the original XML configuration files, here is a recipe for doing so. It involves a few easy, deterministic steps that will result in a great experience and very little hitches.

1. Testing, Testing, Testing

Write tests that examine the composition of your components and the presence of dependencies and initializations being performed. Test all the post-processing events that are occurring during your application startup. Writing these tests ensures that the next steps will not break your runtime without breaking your tests first. These tests should be fairly trivial to write and even generate given the original application context configuration files and will easily pass the first time.

Break your context configuration XML files into more granular pieces, possibly one per package so that you can instantiate and run tests more easily.

2. Remove Hard Dependencies

Remove any hard dependencies you might have to Spring contexts. Break your modules into two wherever you have a declared dependency to Spring: one without any dependencies to Spring that contains the logic of your application, and another with a dependency to Spring and your main module, which performs the task of composing and bootstrapping your application. Your XML configuration files should reside in the latter module.

It is important to note that having dependencies to other Spring modules (e.g. Spring Data) is okay, since they are separate projects that do not rely on Spring context being there and can be used and built into your application without ever using Spring context configuration. These should be treated like any other library that your logic depends on, and should therefore stay a part of your original codebase.

3. Change the Bootstrap Context

Change your bootstrap context configuration to Java config. This is the first step towards an annotation-based application. Instead of using ClassPathXmlApplicationContext  use the wonderful AnnotationApplicationContext  and declare a single entry point into your application by creating a main configuration class. Annotate that class with a component scan for the other Configuration classes as shown above, to only scan for @Configuration -annotated files.

Also manually import all your XML configuration files into your main configuration class. These will be replaced during the course of the transition.

4. Convert Configuration Files

For each XML configuration file, create at least one configuration class. Break the file into multiple classes wherever it makes sense. Try to make your configurations as small as possible. You will be thanking yourself later on when you are trying to run your unit tests and do not have to worry about all the other parts of the application that have to needlessly be configured and started up prior to every test, just because your configuration file included them.

Replace any <beans/>  tag with a configuration class, and in it, for each <bean/>  tag write a @Bean -annotated factory method that returns the same bean instance with the same configuration.

Remember that when you were doing setter or constructor injection in XML files, you were referring to other beans by the <bean ref="..."/>  attribute. This means that when Spring was creating your bean, it relied on those beans being already instantiated. Follow this same paradigm by declaring such dependencies as factory method parameters.

This means that the following XML configuration code:

will be translated into:

Do not auto-wire bean dependencies into the configuration class. The configuration class will be populated with dependencies when its instantiation is complete, which is when all of its declared beans are instantiated and populated first. What this means is when your factory method is being called to fulfill the instantiation of the configuration class, your dependency bean will be still null and you will end up with weird, hard to trace NullPointerExceptions.

Also, do not call to context methods. If you find yourself calling to methods annotated with  @Bean  you should start rethinking your approach: the reason you would need such an invocation is because you would want to get a bean from your context before you set up your own bean. This is a classic hard dependency and you are better off turning this into a parameter for the factory method.

5. Get a Beer

After all of this, you need a beer. You deserve it.


In this post I tried to examine the problem of migrating from an XML-driven world wherein we configured our Spring application via XML files to an annotation-driven world. This is a hurt, because we usually get stuck somewhere in between the two paradigms, bringing something from the old world and patching it with the newer concepts, which results in an ugly amalgamation that is hard to maintain and even harder to read.

I then tried to explore a way to do this in a better way, that is verifiable and adheres to the best practices, while not losing any functionality. I hope you have enjoyed this read. If you disagree with any of this or need more clarification, I would be happy to hear about your comments and further discuss them.

Google Inbox: The Good, the Bad, and the Dreamy

Being among those who have received an invitation to use Google’s Inbox service, I feel obligated to write my own review of its interface. It is basically that, an interface to the existing Gmail, not that I had expected anything different. I am not in the habit of reading long reviews, and as such, will not be writing one.

The Good

First of all, listing what’s great about it.


Google Inbox Menu
It clears away the clutter of your day-to-day mail, and much like Gmail’s not-so-newly introduced tabs, will tuck away emails that belong together. You even have the option to create your own labels, and based on the emails under that label, it will bundle those together for you, too.

The interface gives you a clear overview of the stuff you have in your inbox, allowing you to jump to those that are of more interest to you, more quickly.


Yes. Relaxed. Receiving tons of mail a day, specially when most of them are work-related can be very stressing. Specially considering that I aggregate many different mail boxes under my Gmail account. As such, having the irrelevant stuff put one side and the relevant neatly grouped together would be very relaxing.


The new Inbox is very action-based. It allows you to quickly decide whether or not you have taken action on a given mail, or if you want to create a reminder for it and “snooze it away”.

Ubiquitous Interface

The interface is very ubiquitous. Your inbox looks exactly the same on your Android, your iOS, and on the web. The way you interact with the mails stays the same.

Clean Compose

The compose dialog is very much like it is in Gmail. Except you have the option to directly compose mail to your most-frequent correspondents and also create reminders from the same toggle menu.


You will get overviews of what the email contains. If it is an email of your travel itinerary you will get an overview of it without ever having to open it. Receipts are also the same.

The Bad

I am also going to write about things that I feel are missing from the Inbox application.

Browser Compatibility

The first thing you will notice is that the Inbox can only be opened in Google Chrome via the Web. If you are a Mac user like me, then you most likely do your most routine work on Safari. This has made me move to Chrome or at least leave it open to be able to check my mail regularly.

IMAP Support

Once you mark an email as done, it will no longer be synced with your IMAP client. I don’t know why. I have all these rules set up in my Mail application under OS X that will move the mail to different IMAP folders, but once I mark the mails as done, they no longer appear in my Mail app. I checked and there is no option to have a “Done” folder be made visible to IMAP clients.

This is a REAL bummer for me, and I might even leave off using Inbox for know because of it.

Send as

When you have different accounts aggregated under Gmail, you would be disappointed to realize that you can no longer choose the account/alias to be used when sending an email under compose, and you will realize that when you reply to an email, it will be sent via your current Gmail address.

This is very bad considering that I would not like my colleagues to mistakenly send emails to my personal inbox. I will have to be notified of the email, and should I decide to actually make a reply, I will have to log in to my actual mail box.

Select All

There is no select all action anywhere. If you want to clear your messages from your Trash, you will have to manually select all of them. If you want to select all updates and move them to a certain folder, you will have to manually select everything.

Mark as Read

There is no “mark as read” action anywhere. You will have to open each email to mark them as read. This is particularly counter-productive considering the whole overview option which lets you scan the contents of the email. Suppose I have a batch of receipts. I already know the contents, because I was given a glimpse of it all, but I will have to open them individually.

Emptying the Trash/Spam Folders

You cannot empty your trash or spam folders. You will have to remove all of the emails manually, or wait the designated 30 days for the emails to be removed automatically. If you remove an email from Spam, it will actually go back to your Inbox.

Invalid Rendering

There have been emails that have been split into multiple mails, even though they look just fine in Gmail. This one is a real bother.

The Dreamy

There are some stuff that would make my life and the lives of many others I know much simpler should them be made available in Google Inbox.

Collective Action

So I am a developer and it would not be too hard for me to write  CSS selector that would select, say, all “Approve Comment” actions in the mails relating to my blog’s comments. If I choose to have them bundled together, wouldn’t it be super great if I could have a button that would run “Approve Comment” on all emails?

Custom Overview Contexts

Again, it wouldn’t be too hard to define custom overview pieces from certain emails, take the comment example from above.

Aggregated Data Overview

If Inbox would do the same thing it does for the inbox folder across all folders, and then I could easily apply ordering and rules to the emails, and have the emails moved to the appropriate folders, while Inbox would show them to me in their proper format, it would be my all time favorite.


I think for now, Inbox cannot be a full-fledged replacement for your Gmail, at least not on the desktop. If you want to use a mail client alongside Inbox, right now it is not the answer. I don’t know if Google is hoping to overtake your use of mail and guide you to its web interface — because ultimately it will be more beneficial to Google — then it should at least offer a wider range of support to the browsers its users are going to use.

Also, some of the points I have mentioned above are entirely too critical at least for a power-user like myself, and I don’t know if I am yet ready to make the full-time switch.

Google: Final Call

I got the final call. I got called about half an hour ago, and the answer was that sadly I wasn’t chosen to be a part of Google’s big picture this time around.

The good news, according to the calling person, was that I did do rather well and was very much close to the hiring bar. The second interviewer, as described previously, didn’t find my code as tidy as he would’ve liked, and therefore had voted against me.

I will definitely be trying this out again, but for now, this concludes the series, Google Interview Process.

The Face to Face

I went in for the face to face.  The people were nice and friendly in the office. I did have a fairly nasty incident the night before, though.

Needless to say, travel costs including taxi fare were all covered by Google, so I hardly spent a penny.

I went out 10 something at night to grab some dinner. It was late and there were few places open. I started eating and then a guy came and sat next to me. Now, as the place was very small and it was one of the only few operational places left open, I did not think much of this, as it was already very cramped. He started talking to me and it soon became clear that he was from Cyprus and was here on business. I told him I’m also on a very short trip.

He ate a lot of food, and then left for the rest room. In the meanwhile I finished my meal and asked for the bill. The guy brought me my bill and I looked at it. 1200 Turkish Lira. My mind was blown away. I checked and realized that it was four times the number of items I had eaten, and mine was just amounted to 70 Liras — in retrospect, the hotel would have charged me somewhere near 100 Lira, with the difference that it would have been brought hot to my room and of a superior quality. Not to get sidetracked, I called the manager, a stocky short guy with a huge mustache. He told me that “my friend” had left and I had now to pay for him. He had three bottles of 250 Lira wine and lots of food. I dug into my pocket and realized that fortunately I didn’t have much money with me. Around 100 Lira just so that I could buy dinner, as that was the purpose for which I had set out in the first place.

I got into an argument and then he called his second, a tall guy, that I thought was going to beat me bloody. We counted my money. 110 Lira and 30 Euros. He suddenly looked at me and said in a heavily accented Persian, “Are you from Iran?” and I looked at him and said yes. He told me that the guy was probably with the manager, and that this was all a ploy. But he cautioned me that things might get ugly, and fast, and I told him that I was a student and this was all my money and that I had come for an exam and that my hotel was Topkapi in Aksaray. Fortunately, I didn’t have any identification or hotel information with me. If they had realized my real hotel was in the best part of the city things might have changed drastically.

He looked at me and then said because you are “Fars” and because I’m a student he will cover my back. He took all my Liras and 10 Euros and gave me back 20 for the ride back home. He went to the manager and signaled me to leave. I left quickly, shaken.

Well, that story left aside, let’s get to the actual interview.

The Interview

There were three separate interviews. Two with senior engineers from Ireland, and one with one engineer in Mountain View, California. I am not at liberty to divulge the names or the particulars of the interview — I think 😀 — but I will talk about the general theme of it, and will now go into as much detail as possible.

First Interview

The first interview opened with some small talk about the position I was going for, and I was asked whether or not I knew anything about it. I was then asked why I was interested in the job anyway, and what did it mean to me?

Then I was asked whether or not I had ever run into a major bug, in if yes, how I dealt with it. I went into as much detail as possible. I think it is always a good idea to give them the general idea of where the bug came from, and then if it is required, hint that you can go into more detail if necessary.

I was then asked about a particular subsystem of Google and how it could be designed from scratch. It was more like a two-person design brainstorming session and I think it was very much helpful in the way I answered it, since it stripped away my nervousness. I was then asked why somebody would want to abuse this product, and how would they go about it? Then I was asked to reverse the roles, and stop the attacks.

I was then given the time and opportunity to ask my own questions.

Second Interview

This one was more along the lines of my previous phone interviews, as it contained data structure and algorithms questions. It cannot be overstated that Google apparently cares a lot about bit manipulation as the topic again came up in this interview. I was also asked to design a game board for a certain, popular game.

Then, I was again asked to design a major feature of the Search product from scratch and describe what sort of data structure and algorithms were necessary for that product to operate in a reasonable fashion.

I was then again given the opportunity to ask my own question. This interview was observed by a younger interviewer-in-waiting and I was given the chance to interact with him as well by asking him questions about the whole company culture at the end of it.

Third Interview

The third interview was conducted with a gentleman working for Google’s PQO at the Mountain View offices. He gave me a general rundown of the whole job description in a minute and asked me to describe a major bug I had faced. I told him that I had already been asked that, and if necessary I could discuss the same thing with him, but if not, I was ready to answer another question.

He thanked me for telling him that, and asked me instead to describe a design challenge I had faced. I did, and he then gave me a somewhat data structure related question about one of Google’s anti-abuse strategies.

He then asked me a question in the same vein as the brainstormer from the first interview, this time about another particular sub product, and I gave him a design rundown. He then asked me to abuse and anti-abuse the product.

It was concluded by a friendly chat about the position and its technical aspects, as well as the whole culture of the company.


All in all, it was a pleasant, surprising, and very difficult process. It took over four hours and I was beaten up by the end of it, and could barely get myself back to my hotel. Hopefully, it will have gone well, and I will be receiving a positive feedback. But if not, I will be buckling my belt for the next round that life will present me with.