Google – 2015

I got a note from a recruiter at Google. It hadn’t been that long since I interviewed with them (Google – 2014 and War of Attrition – 2014 and Google Again – 2014 detail the last time I had major contact). The recruiter wrote:

Subject: Hello from your new Google contact!

I hope things are well in Austin! I’m with Google Engineering, we haven’t been introduced, but it’s good to e-meet you! I know you were in touch with [somebody else] here at Google, bug wasn’t sure if you two were able to connect last spring. He has transitioned to a new team, so I wanted to reach out to establish myself as your new point of contact in case you want to get in touch with somebody at Google at some point.

I know it may still be too early given your very comfy role at Mozilla (working from home in awesome!), but I’d be happy to keep the commnication lines open in case anything changes on your end 🙂

I’ll plan on reaching back out later this year to check-in, if you don’t mind. Please let me know if you have a preferred timeline for that communication (after/before fall?).

Interesting. I had been studying and working on a side project since my last interview, so maybe I was more ready now. I told her that I was pretty happy at Mozilla. Then I mentioned:

I am rather puzzled by how Google is talking to me at this point. I interviewed in February, 2014, and was turned down on March 7, 2014.

I started on Mozilla on April 22, and [previously mentioned Googler] contacted me the very next day about taling to me about Google(!). What is going on here? I understand that Google is a big place, and that I may have been interviewing for something difference than anything available, but…

That being said, I am not particularly happy with my role. I am much more interested in systems or applications programming that I am in automation, my current role. I am really interested in server-side work, and Mac OS and iOS work. A good role at the right level of pay (which would be difficult at this point) would be very interesting to me. I would also be interested in leading projects or teams.

She responded:

Thanks for getting back to me and my apologies for the confusion on our end. I did a bit of digging and it looks like we had two independent files for you which led to all of this, how embarrassing. We migrated our internal systems’ information and are still working on clean up, I’ll be sure to fix the duplicates on my end. Again, my sincere apologies for the confusion!

She then asked for a chat on the phone, which was basically confirming what I was looking for. A few weeks later, she contacted me to tell me that there were some teams she was matching me to, and wanted to make sure that I would be open to it. I said yes. She then asked me for an updated resume, and a list of other Googlers I knew. I stopped at 50 names…

She also told me to pick a language to interview in. I chose C, because it is the language at the time I was most comfortable in. That probably was not the wisest choice, as it is an “old” engineer’s language. She assured me that they had plenty of C code at Google to work on…

Then came the phone interview. I got a relatively easy string processing question. Of course, in C, it had to be easy because there is so much bloody boilerplate and no library support in C. I thought I had hacked the Google interview process!

They decided to move forward with the interview process, and put me in touch with an interview coordinator. Who promptly informed me that the interview pretty much needed to be in something more modern than C. So, Java it is.

By this time, I was at a Mozilla All-Employee meeting in Whistler, BC, and Google wanted to schedule the travel. The only reason I mention this is that I had to find a place to hide, and I had to pay international roaming on the call. Annoying, that.

Anyway, off to Mountain View. I arranged it where I could fly out in the early morning, interview in the afternoon, and fly the red eye back, only taking one day off of work.

The day of the interview came, and I showed up right on time at the Googleplex. The interviews went well. There was a string processing problem, a binary tree algorithm problem, a basic service architecture problem…

The most interesting session was after lunch. The premise, as near as I can remember it:

Let’s say that Google had put a data center on the Moon with 100 machine installations. Now it was time to update the kernel on those machines. How would you approach it?

I asked if I could assume the kernel update was well-tested. They said that I could not.

And off we went. I had a blast.

I finished mid-afternoon. It was as good a interview as I could possibly do, and I felt really good about it.

I called my friend at Mozilla who started my process of working there, and asked if he wanted to take the afternoon off and have a beer.

Mozilla QA was at a crossroads (Walt Mossberg detailed a lot of Mozilla’s problems in this excellent article), and both of us were being caught in the storm. He was unhappy; I was becoming so. It was good to catch up with him in person!

So I went home and waited.

Surprisingly, I heard back pretty quickly.

It was a no.

I was actually really, really disappointed, because I did not think I could to better. My guess at the time was that I was just not good enough at programming to work there. Put me in a funk for a while.

However, they did want to talk to me about working in the QA organization. I guess my session about upgrading datacenters on the Moon was worth something…

 

Los Angeles Dodgers – 2015

Early in the year, I applied for a position labeled “Senior Developer” for the Dodgers. The job description talked about front-end web work. I applied, although my strength was more in the back end.

And forgot about it.

Several months later, somebody working for the Dodgers analysis contacted me:

My name is *REDACTED* with the Los Angeles Dodgers Research & Development department. I am following up with you regarding your application for the Senior Developer position that we currently have open. We have looked over your application and would like to arrange a preliminary interview via Skype sometime next week.

Could you let me know dates and times of day when it would work for you to schedule this interview, hopefully this week or early next week? Most afternoons are good for me PST; I will follow up with you and confirm slot and Skype details later once we have a set time.

Be prepared to discuss your pertinent technical experience, background in baseball, and what you can bring to the Dodgers front office.

I look forward to speaking with you,

Coming off of my interview process with the Kansas City Royals a few months earlier, I was stoked, although my enthusiasm was tempered by the fact that I would probably have to move my family back to California. So we set something up.

I surrounded my interview area with baseball encyclopedias, Bill James abstracts, and drink cups from my big stadium tour trip of 1994. I was ready to talk.

The interview lasted 10 minutes. I think that they were disappointed by both lack of web front-end technology and lack of work with another baseball team.

Oh, well. I did write a letter back to the person:

Thanks for talking with me yesterday. I just had some thoughts about the position I would like to share with you after thinking about our talk yesterday.

I get the impression right now is that with no developers, there is a lot of data sitting around in different places and different accounts, with no unifying structure, no data normalization, and of course, no front end to access it all. I could be wrong about that, but that certainly seems to be what is happening here. You probably have Game Day, Stat Cast, and Pitch FX data piling up every day, and you almost certainly have proprietary data being generated by your analysts, 3rd parties you have hired, and your scouting staff.

Some of the problems with this kind of system:

  • Matching one player in one system to the same player in another system is non-trivial. Most vendors probably use player IDs from MLB, but not all do.
  • Adding data for new players entering the system (new players drafted/coming up/signed) means coming up with new playerr IDs, bios, etc.
  • Automation for populating such a system does not exist.
  • Any time data in the system needs updating somebody has to go update some data by hand. This could be as crude as editing an Excel spreadsheet.
  • There is no agreed upon standard for how reports should look, or how you search for things
  • There is no way to see data from disparate sources for the same player or set of players.

If I am right, then what you really need is an architect of your entire data system. This person would be in charge of the whole system. They would be responsible for:

  • Develop an automated system for acquiring data real time.
  • Develop a storage system and unified schema for all of the data sources.
  • Develop a front end design for how data is presented and searched.
  • Develop a front end implementation for the design for whatever end-user systems are necessary.

This person would either do the work or hire 2-3 people to help out. I assert that I can be that architect/project lead/software development manager. I think you need that overall strategic person more that you need a front-end developer right now.

I know that this is a strong statement, but I don’t feel that I adequately expressed myself yesterday.

Whatever you decided to do and however you do decide to proceed, I wish you and the Dodgers luck, even if you don’t decide to move forward with me.

Thanks.

No surprise that I never heard back. The Dodgers seem to be doing OK without me; they appeared in five straight post-seasons since this interview so far…