Google Tech Dev Guide

(Disclaimer: I work at Google). This is going to sound like a humble-brag, but it isn't, I'm trying to give some life advice based on my experience: I have used "CS" algorithmic thinking on multiple projects, I've even used facets of abstract algebra and number theory from my Math degree to further my career and it lifted me out of poverty.

Here's an example. A few years ago, I was researching ways to crunch down the size of GWT (Java-to-JS compiler) output more. Besides obvious compiler theory work on optimizations, I noticed that the code had a lot of common chunks that could possibly be gzipped better. Knowing how bzip2 worked with the BWT transform, I wondered if sorting JS code could improve gzip output, the result was this (http://timepedia.blogspot.com/2009/08/on-reducing-size-of-co...) and writeups like this were one of the ways I got noticed by Google to get an interview. In other words, solving "useless puzzles" landed me a dream job.

The gist of that article is by using edit-distance/levenstein distance to 'cluster' JS code fragments, you can improve the efficiency of GZIP by bringing more code into its 32K window OR optimize the huffman codes it uses. However, edit-distance doesn't know anything about the LZ algorithm's mechanism.

Later on, I ran into the "LZ Distance Metric" in some papers while researching about optimal clustering and wrote an updated post: http://timepedia.blogspot.com/2009/11/traveling-salesman-pro...

It turns out optimally computing the LZ Distance Metric requires efficiently solving the Longest Common Substring problem, which can be solved with a generalized suffix tree in O(N + M) time.

In other words, if my only experience was doing web programming or standard forms + database enterprise apps, I probably would have never been able to even imagine this, because I wouldn't know what I don't know, whereas spending time actually thinking about data structures and algorithms in my past, prepared me for that moment, exposing me to stuff I would recall later when I needed it. Moreover, trying to solve this problems exercises memories you learned in college CS, so you don't forget them, especially the ability to read papers and consume mathematical notation.

Another example: I have long had a love affair with number theory. It's why I love cryptography, error correcting codes, block designs (See one of my own puzzles to see if you can solve it: http://cromwellian.blogspot.com/2006/09/puzzles-you-cant-sol...)

This led me to get into crypto. Early work on crypto during the cypherpunks mailing list days in the 90s, designing anonymous remailers, anonymous internet proxies, and digital cash algorithms, got me noticed, and led to a job at IBM TJ Watson research, my first, real, non-consulting job (before that I mostly wrote 6502/68000 assembly for games, and FastCGI+Perl). From there, I applied HashCash proof-of-work in the mid-90s to anti-fraud in hacked clients in 2-tier systems, patented an early re-CAPTCHA-like algorithm, and ended up getting acqui-hired by a California company. Now, I was born and raised in Baltimore City, grew up pretty poor, and had to start my first 2 college years in a community college. This was a fantastic dream come true for me, and I mostly credit it to serendipity made possible by being exposed to a lot of stuff.

Later, internal to Google, I came up with the idea of applying Broadcast Encryption used in copyright-protection systems (e.g. Blu-Ray AACS) and turning them around for a good purpose: creating a serverless, peer-to-peer group messaging social-network. That design was heavily based off of number theoretical knowledge I had to dust off, and helped facilitate an internal transfer to the team I'm on today.

There's nothing wrong with straightforwardly engineered apps, screens, forms, databases. Most of the world subsists on this. But sometimes, in fields of graphics algorithms, AI, mapping, bioinformatics, AR, VR, you encounter situations that aren't straightforward, and then it becomes valuable to be able to be confronted with a super-frustrating, mind bending puzzle, and bring all the weapons to bear on it. Can't you just Google-search it? Sometimes. I'd argue more often than not, you'll "flesh-based search engine it", by tracking down your local Jeff Dean clone and asking them for hints.

But IMHO there's no harm in being challenged like this anymore than being asked to complete basic training to be in the military, even though you might just be a tech-support soldier. You never know when you'll need those brain muscles, and if you're lucky, like I was, it could be a life altering opportunity. I don't think Google interviewers are interested in you solving the problem and getting the correct answer, they are interested in seeing how you work: how you think, how you communicate and ask questions of the interviewer, in other words, how you'd work as a member of the team. There's no shame in asking the interviewer questions, it's what you'd ask a coworker if you're trying to solve the problem.

It's not the end result, but the process.

This is the reassuring story every interviewer has to tell themselves to feel good about their decisions... and its the story every interview consultant tells the tech firm. But I tend to think its probably a just-so story, most of the time. All this work is done in the tech world to eliminate the subjectivity from interviews - this is how the subjectivity is re-introduced through the back door.

> As long as it eliminates enough false positives, they’ll keep up with it.

So Google is relying on a brute force approach to hiring?

So don't give that sort of interview; give one you wouldn't walk out of where, if it goes well, you'll be able to write a compelling argument about why the candidate should work at Google, and if it doesn't go well you'll be able to write about where the gaps are.

Feel free to ping me on IM (username is in my profile) if you'd like to talk about how to do this in a way that helps hiring committee make informed decisions.

Ya, but everyone is. Too many fakers in this industry.