If collaborating with others in a remote office, I begrudgingly make a Google doc and treat it like a whiteboard.

Most of what we do involves enormously complicated systems with lots of nodes and RPC flows between those nodes, different pathways depending on the flavor of the RPC, systems spread out in different metros around the world... it's very difficult to visualize all that complexity in your head if you've never seen it on a cocktail napkin.

For example, just last week I sketched out a diagram inspired by the famous visualization of Napoleon's campaign to Moscow (http://www.aviz.fr/wiki/uploads/Research/minard.jpg), primarily to help me wrap my head around a complicated RPC flow (at the first node, 32% of the RPCs are classified as XYZ. Each of those spawns 3 new RPCs that go here and 1 that goes over there...) When I got stuck, I called over a colleague, and he was able to immediately see, just by looking, where I was going wrong, and with a few strokes of the marker, set me straight.

I later turned it into a spreadsheet so I could use it to explain the model to others. Also, it was nice to be able to use worksheet functions to do the math. But I never would have been able to get that far that fast without starting at the whiteboard.

The interview described is pretty much exactly as I remember them. SRE is actually quite difficult to get into, precisely because you need to have fairly deep knowledge on a wide range of topics. The "ways in which you were asked to solve problems" are actually the best way to determine if an application actually knows about what they will need to know.

"You're a site reliability engineer at Google. Google is offline and you have to fix it, what do you do?"

"I'd Google the answer"

"Try again"

"I'd ... Bing and decide?"

both laugh

Once you move beyond roles which are effectively operations, maintenance or been-done implementation to anything that can be called engineering you'll start to face problems for which there are no canned answers.

>"It's not the 70's any more, people rarely solve problems on whiteboards and paper."

This has nothing to do with era, it's a matter of scope and scale. When you have problem that is big / complex enough that it can't be reasonably solved by a single person a whiteboard is invaluable in laying things out and thinking them through.

>"They solve them on the computer, sometimes through knowledge and their skill-set and other times through luck and Googling."

Where do you think all that helpful information on Google, or anywhere else actually originates? When the folks at Google were in the process of engineering GFS do you think they just Googled "chunk replica placement" and hoped to luck into a StackOverflow post on HDFS from 10 years in the future?

This isn't universally true. Anecdotally, I often find I'm much better able to think through tough problems if I step away from the keyboard and spend some time sketching out ideas on paper or on a whiteboard. I also keep the on-paper results in a notebook, which is occasionally useful to refer back to later in a project.

Sometimes just introducing some distance between you and the problem is enough to give you a key insight. That said, the interview environment is still nothing like this. There, you're under great pressure on the whiteboard, something which is probably not true in your day-to-day.

If something really, truly has never been done before, nor even anything similar enough to be useful to me, then yes, this is the right way to work. But it's more common that someone has actually worked on something at least related (even if not quite the same), and that I could solve the problem more quickly if I looked for what they said about it first. That might take a bit of searching and reading to discover, sometimes even a few hours of it. But usually not as much time overall as re-solving it myself does... especially taking into account re-discovering all the edge cases.

My hypothesis is that many people don't realize this because they never follow up later to check if their solution was really novel, or was just lurking behind a keyword they didn't think to try. If you do that a bit and adapt your habits to miss things less often in the future, you can get better at finding and adapting existing solutions, rather than re-inventing things from scratch. But that's sometimes a bit deflating, because then you realize you weren't inventing so many new things before, either...

[1] I mean this in the sustainable competitive advantage sense

I turned her down because I'd gotten a really bad impression of the whole process. No other company I've interviewed at have managed to be nearly as Kafkaesque in the hiring process, and several of the Google recruiters I've spoken to over the years have vented their frustrations about the process at me when I told them this, while non-Google recruiters have gleefully told me they hear this a lot and consequently see less and less competition from Google for candidates.

I'd consider a request from a Google recruiter for an interview again, but the threshold for me to bother starting down that route again has gotten higher each time - I don't feel Google is worth the hassle unless they were to approach me with something exceptional.

This is not true for everyone. I see it as more of a failure on Google's behalf to create a good selection process. The flawed assumption you're making is that, since they have a noticeable false positive rate (i.e. good people getting rejected), they don't have false negatives (i.e. unqualified candidates getting offers). There is no guaranteed correlation between false negatives and false positives.

To carry this a little further, I would argue that it's very likely that some bad engineers get into Google because, by definition, their selection process is not correctly picking good engineers - just a rough approximation of what they think makes a good engineer.

But you have to look pretty hard to find those engineers...much harder than you do to find quality engineers that have been turned down by Google. And I believe it's intentional...that those false positives are about seeding the rest of the industry with people rejected by Google. I believe they interview more candidates than they need to bring in to fill their open positions in order to feed the perception (not the reality) that Google's engineers are the best of the best. That's the perception they care about, not the perception that their interview process is good at choosing employees.

I'd estimate that no more than 50% of job is spent coding, if that. Solving computer/software/system/architecture problems, yes. Coding, no.

I don't know what you do or where you work, but it's no job I've ever had, nor any office I've ever been in. It's not unusual to end up spending most of a day in rooms with whiteboards and a few colleagues working through problems.

You don't hand a car engineer manufacturing tools on day one of making a car, you need him to produce a design/blueprint first.

Really?

Let's be clear: whiteboards are a fine tool for design, problem analysis, architecture, etc. etc. People take issue with "write me bubble sort up here on this whiteboard."

The implementation part of "software engineer" very often is much easier and sometimes even trivial when compare to the design/architecture of the entire system. Implementation is also very easy to improve upon and refactor out, if you have a good design to begin with.