An Interview with Google

By Chris L Hardin
Sr. Software Architect
Things always seem to work out for the best, especially when it comes to my prospects of working for Google last year.
I managed to get an email from a Google recruiter and after the small preliminary interview, I landed the first technical interview. Keep in mind there are about 3 interviews in the whole process. The last is the Google Office in New York, Boston or California, whatever office that they are interested in putting you. I assumed that the technical interview would go very well, since I was informed it would center on javascript and Web development and a little java.
The Technical interview only lasted 30 minutes on the phone. The interviewer seemed to be in a real big hurry, I guess he had more interviews lined up with 30 minute slots. The questions were simple questions.

1. How would you save state without reloading the page?

Create a XML HttpRequest and push the state data you want to save back to the server and store it in the session or write the data to a cookie locally.
He seemed “ok” with this answer, but kept pushing me like there was a particular response he was wanting to hear, but he moves on to the next question.

2. How do you or have you handled the back button in other Ajax projects?

Most projects I have worked on, ignored the back button or disabled it, but if I must handle it, then you have to keep track of the users actions and when they click back, you have to intercept and roll them back through your own history you manage instead of letting it navigate away from the page.

3. Have you used the Google Web Toolkit before?

No, I looked at the Google Web Toolkit before at the same time I looked at all of the other Ajax frameworks and I determined Ext has the greatest flexibility and richest components with for the projects I have been working on. (this is where I screwed up, but this I’ll tell you about later.)

4. What OO patterns do you use regularly?

MVC Model View Controller, Data Access Objects, Singletons, etc.

I assumed by my answers everything went well, but then here is where it went downhill. The interviewer explained to me that he was the lead on the Google Web Toolkit and had a large hand in creating it and I was to be on his team, I was like, crap, I just rendered a killing blow to his ego earlier when I said I chose Ext over his framework. In hindsight, I probably should have asked what his job was first or at least said I had no knowledge of the Google Web Toolkit.

He explained to me that the google web toolkit was better because it was entirely written in Java and the toolkit was generated and compress into the javascript API.

My reaction, to myself of course, was that I really don’t want to work on a project like that. I love writing Java and I love writing Javascript, but I don’t like one to write the other. He said that this keeps his people strictly in the Java realm and can use the IDE to validate the builds. I have to admit, I just skimmed the iceburg and might have liked it if I saw it in action.

At this point, he was ready to get off the phone. I was being as nice as I could possibly be to repair the damage I did by insulting his project. I asked him a few questions about how the hiring process works and all and then we parted ways.

I received an email a couple weeks later after pressing the Google recruiter and they said they wouldn’t be able to continue interviewing me. I tried to get information on why and how I did in the interview, including the responses the guy was looking for and I was denied.

Well, remember I said things work out for the best? The next month, there was an announcement that Google recruiters were suffering a layoff and the recruiter that I was introduced to was gone. Then another month, the heat of the recession last year, I heard an announcement that a large number of contractors were being let go. I was to be a contractor when I started.

So, it worked out well. I was honored to have been picked to interview and it was an experience. I would hope that one day I could have another opportunity to interview again. Google is still a great company…even though I like Ext better than their silly little toolkit.

2 years with the Ext Framework

By Chris L Hardin
Sr. Software Architect
It will soon be two years since I started developing projects using the Ext framework. When I started Ajax development, I was writing everything from scratch. The frameworks were really young back then, matter of fact, I contributed some code to the Prototype framework. I’ve been doing Javascript for going on 11 years now. I can’t believe it has been around that long. When I started using it is was just for validating your forms and doing other odd tricks. Now, you do not develop without in some form or fashion.

After using Prototype, Dojo, Scriptaculous and Ext, I settled on using Ext for my last project because of the rich GUI-like components. I could create complex grids, forms, controls and all with minmal effort using the API and it integrated seemlessly with JSON data. In most cases, like a grid, you can just give the Ext component your JSON url and the rest is done for you. the only gotcha when using any framework in this manner is that you have to find out what the meta data is and program it into the JSON. For example, the total records in a dataset for a grid.
for years I have developed projects that utilized a page technology like PHP, JSP, JSF, ASP and the problem with all of these APIs is that you have to completely understand them to develop the user interface. This wasn’t a problem for me, but if I wanted to put someone else on the user interface, so I could concentrate on the backen code, the other developer had to be as proficient as me at the page technology, which was a problem since I had been doing it for many more years.
Ajax was the answer to my problem. I architected the application to be completely agnostic of any page technology. The pages were merely HTML pages using Ext and the data was transported back and forth from Ext via JSON. This design made things simpler. The GUI was totally the responsibility of the Javascript developer and the back end was the responsibility of the Java developer, a clear separation of roles. I ran into just one problem, I became the only developer on the project.
I had an advantage that I was the only person working on the project and I didn’t have to worry about stepping on anyone elses toes or slowing down to train anyone. We have the Ext layer which was the HTML and Javascript files, mostly just .js files. We had a controller layer which was Spring MVC. The Spring MVC layer was responsible for converting url requests into business layer requests and taking the data objects returned and converting them into JSON data. The business layer was Spring beans that made calls back to DAO objects that used generics and Hibernate to translate the request into a query and hydrate objects into our domain obects. without a doubt this was the best architecture that I ever created. It had one small drawback.

Later into the project, like when it was almost complete, we finally saw how much data these users wanted to process. They wanted these Ext grid to load thousands of rows of data with an average of 20 columns but they wanted to see thousands of records on a single page in the grid. I don’t care what you do, the browser just can’t handle this. Now that the application as complete and the business analysts finally pulled the “real” requirements from the users, I could see that it would be impossible to give them their cake and eat it too with Ajax. At some point you just have to admit that the browser is not the most efficient at displaying large amounts of data.

If I had this project to do all over again, I would do it in a C# GUI and just have it talk to the Spring beans on the server to get the data either through Web services or some other method. Or I might even just utilize Excel components to load the data for them. It would be easier for a local application to utilize enough memory to handle a thousand records and manipulate them, a lot easier than a browser can since the browser has some limitations. Of course, initial reqirements mentioned nothing about users wanting to edit thousands of rows at one in a grid, but they did mention that the app had to be a web application.

If the users expectations could be managed and they could accept being about to edit 100 rows at a time in a paginated grid, then we might be able to reuse this application, but the chances of that are slim and none, and slim just left town.
After two years of Ext development, I can truely call myself an Ext expert though and it is the perfect choice for “most” web-based applications. It’s flexible, easier to learn when compared to other frameworks, it has very rich gui components and it has plenty of support. The Ext forums helped me a lot when I was developing.

Let’s look at some grid examples using Ext.

// create the Data Store for the Grid = new{
// load using script tags for cross domain, if the data in on the same domain as
// this page, an HttpProxy would be better
proxy: new{
url: 'users/users.jspx' //This is a Spring URL redirect

// create reader that reads the Topic records
reader: new{
root: 'users',
totalProperty: 'totalCount',
id: 'id',
fields: ['id','attuid', 'lastName', 'firstName', 'roles', 'status', 'email', 'comments', 'modifyDatetime']

// turn on remote sorting
groupField: 'status',
sortInfo: {field: 'lastName', direction: 'asc'},
remoteSort: false

The JSON data that comes back contains all of the required properties that the ext store expects like totalcount and the root which contains the array of records. Records are indexed by the column names above in the fields property. You can also use a mapping property to map fields to other names, but I avoid that since it can cause some confusion.

Let’s load the store in a Grid. This all looks complicated, but after a few minutes of looking at it, it makes sense. Ext is full of options, so you really have to dig into the API documentation sometimes. The code below will setup the grid and after that it will call load on the store, populating the grid. I will load up the examples to the server and link to them at the end of the article.

// the column model has information about userGrid columns
// dataIndex maps the column to the specific data field in
// the data store
var cm = new Ext.grid.ColumnModel([{
//id: 'user', // id assigned so we can apply custom css (e.g. .x-userGrid-col-topic b { color:#333 })
header: "ATT UID",
dataIndex: 'attuid',
width: 75

//renderer: renderLink
//id: 'user', // id assigned so we can apply custom css (e.g. .x-userGrid-col-topic b { color:#333 })
header: "ID",
dataIndex: 'id',
width: 50,
header: "Last Name",
dataIndex: 'lastName',
width: 75
// align: 'right'
header: "First Name",
dataIndex: 'firstName',
width: 75
//hidden: true
//id: 'email',
//header: "Roles",
//dataIndex: 'roles',
//width: 100
//renderer: renderLast
// },{
//id: 'email',
header: "Status",
dataIndex: 'status',
width: 100
//renderer: renderLast
//id: 'email',
header: "Email",
dataIndex: 'email',
width: 100
//renderer: renderLast


header: "Comments",
dataIndex: 'comments',
width: 150
//renderer: renderLast

header: "Modified Date",
dataIndex: 'modifyDatetime',
width: 110
//renderer: renderLast

//This is how we will select our rows in a userGrid
var sm = new Ext.grid.RowSelectionModel({
singleSelect: true,
listeners: {
rowselect: function(sm, row, rec) {
//alert("Row Selected: " +['id']);

// by default columns are sortable
cm.defaultSortable = true;

//The link used when a new user is created
newUrl = 'Add New User   ' + RMA.util.buildExportLink('users');
//Create the userGrid object and bind to our div
RMA.user.grid = new Ext.grid.GridPanel({
frame: true,
title:'RMA Users',
viewConfig: { forceFit: true },
cm: cm,
sm: sm,
listeners: {
render: function(g) {
// g.getSelectionModel().clearSelections();

delay: 10 // Allow rows to be rendered.

//sm: new Ext.grid.RowSelectionModel({selectRow:Ext.emptyFn}),
//loadMask: true,
view: new Ext.grid.GroupingView(),
plugins: filters,
viewConfig: {
getRowClass : function(record, rowIndex, p, userStore){
//p.body = '

return ‘x-grid3-row-expanded’;

return ‘x-grid3-row-collapsed’;

tbar: [
‘Search: ‘, ‘ ‘,
listeners: {
render: function(c) {
target: c.getEl(),
text: ‘Search by First Name or Last Name’
}), ‘ ‘, newUrl

bbar: new Ext.PagingToolbar({
plugins: filters,
displayInfo: true,
displayMsg: ‘Displaying users {0} – {1} of {2}’,
emptyMsg: “No Results to display”



// render the userGrid

// trigger the data store load to load up the userGrid{params:{start:0,}, callback: RMA.user.showResultMessage});

The grid object gets added into the center panel of an Ext layout. Ext does layout management extremely well. It’s extremely easy when compared to using straight HTML, JSP, Java or C#. It’s just a matter of learning the Ext API.

Voila, you get this

Here is how the entire application looked with the layout an all. Blurred elements are to protect the confidentiality of the company.

In the application, I blended the Ext panels, North, South, West, East and Center to make the application appear like it was a solid page. This was simple. All of the segments have limitless properties, you can open and close them, move them around, slide them up, but I disabled all of the bells and whistles. If you look in the examples zip file I have included, you see that the entire application is loaded from a single index.jsp file. When I created a new section of the site, I just added a new .js file and used the Ext API to build it and then the link in the left nave just called my function to close the old section and open the new.

As I mentioned, Ext is very flexible and has many options, but this is also a drawback. Notice that the grid code takes up a lot of space and appears to be terse at first glance. A lot of the complicity was due to learning the framework 2 years ago. I would do things a little different now, like maybe creating methods that take parameters to return the grid, the store, etc. However, our sections were so vastly different sometimes that even this would have been tedious.

Debugging was a major issue. I couldn’t use Firefox and IE was modified by the company so it didn’t work right most of the time. I plugged in Log4Javascript to help in the area. All in all, I think I could write a very nice chaptered book with respect to Ext, but by the time it came to press, it would be well outdated. Ext 1.1 was vastly different than 1.0. It was almost a rewrite. From Ext 2.0 to Ext 3.0, it was pretty progressive in the updates, but I was always able to upgrade to the next release in just a few hours without any trouble.

If you’d like to look at my examples, there are here.

Java-related Articles

Here are some of the articles that I have done for different outlets over the past few years. Ignore the age of the technology. I wouldn’t do anything the way I did it back then now. There needs to be some kind of relevancy indicator on these articles to indicate how relevant they are to today’s technology standards.

My Author Page on

My Author Page on OnJava